Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mJdUh-0003hd-J1 for pgsql-admin@arkaria.postgresql.org; Fri, 27 Aug 2021 15:10:11 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1mJdUf-0005aM-GT for pgsql-admin@arkaria.postgresql.org; Fri, 27 Aug 2021 15:10:09 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mJdUe-0005WC-V5 for pgsql-admin@lists.postgresql.org; Fri, 27 Aug 2021 15:10:09 +0000 Received: from mail-wr1-x432.google.com ([2a00:1450:4864:20::432]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1mJdUX-0001OM-PN for pgsql-admin@lists.postgresql.org; Fri, 27 Aug 2021 15:10:07 +0000 Received: by mail-wr1-x432.google.com with SMTP id q11so10913315wrr.9 for ; Fri, 27 Aug 2021 08:10:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cybertec-at.20150623.gappssmtp.com; s=20150623; h=message-id:subject:from:to:date:in-reply-to:references:user-agent :mime-version:content-transfer-encoding; bh=lfXMn+qgTQyDf06vmmMv+yWrsyYoQkm6YVHXYi+jx+w=; b=wveYRyr8X1t/KICqSyNe4bKnp7rLx5nowWy3g2zXsMUYwNr0t9gp0iU4cKmpPOgSMH 0PbkQWxpMwymDE8wsxo4rg4wNTAaa8Mao04MB9fPISwTsusKndg3dmuUpbzvoR1asGlQ Vbqzt+cpgyUOLbqN4GBl5w8x60XYuROxKqwYFEPJUYqKg8Tj2IcCY5qEIw17idVRwblh wdjOgc3sXCYHJLBNxjvrKKPVwg0obhKSrjy3dkWhsfvfjQoCCS5r06INbLyA253t1qUc oEbC+SzW8YwVEjmhJKni6qDteO0stKdq9ZaQV204DvdeocE27/498NfeiQl7ANHq8w2U i3Vg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:subject:from:to:date:in-reply-to :references:user-agent:mime-version:content-transfer-encoding; bh=lfXMn+qgTQyDf06vmmMv+yWrsyYoQkm6YVHXYi+jx+w=; b=Tmz9kxcUkLgP0S1CAKRQsVqb09i95mPuDY8t04RmhtyFtAqV/I3Ee1y0bfNrzIACnv 1i78CxcNZwxq3n7wERpfNb+NLx65MQKruVx0K+hYkSw0lzqIUXukNLtCaY+pSR1SxMkY Z9sVXp6JANsO7YgKDWnW4I01mwbpKXk91VHnYMXfyuesjsPkQ4tW6PmyZ4xpi+uhzfAm ZfxXXwgycxK7TGcCSoZjfRoiW/7u5N+pCpsyc/V1zGUnTpW/ofXs3Tw27HBIG3Y3SnpJ Ju6H6d98drQmhManwvNB30lttfQ374vN5lTXOzMPhLR5cmGgxR04p59jPDKCqpX5PtcN jPkw== X-Gm-Message-State: AOAM530OJE01HqIaRU1PF9J4yXrONT+qfR2u9+F36TlHvHmcW3Rka0Zp yZWj4n7aHgOaM4vTp3nOeKw7cQ== X-Google-Smtp-Source: ABdhPJw6mUlJMWQFWDSdRqXX56cFmDjwYi8Ir+PiYTlF0OD/ZAq+QF4QW9zvZCuY3PFRpKNYZw1TLA== X-Received: by 2002:a05:6000:184a:: with SMTP id c10mr11124789wri.26.1630076999902; Fri, 27 Aug 2021 08:09:59 -0700 (PDT) Received: from localhost.localdomain (dynamic-e41ynjkw44ykta3or-pd01.res.v6.highway.a1.net. [2001:871:5c:e82d:7c71:3f6d:7e60:5e2b]) by smtp.gmail.com with ESMTPSA id x21sm4756951wmi.15.2021.08.27.08.09.59 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 27 Aug 2021 08:09:59 -0700 (PDT) Message-ID: Subject: Re: slave stops replica From: Laurenz Albe To: Pepe TD Vo , Pgsql-admin Date: Fri, 27 Aug 2021 17:09:58 +0200 In-Reply-To: <1948635055.176990.1630061761986@mail.yahoo.com> References: <1415172523.18991.1630012160409.ref@mail.yahoo.com> <1415172523.18991.1630012160409@mail.yahoo.com> <1e79ea171debe2b3ed9c297989f110cfccdf129b.camel@cybertec.at> <1948635055.176990.1630061761986@mail.yahoo.com> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.40.4 (3.40.4-1.fc34) MIME-Version: 1.0 Content-Transfer-Encoding: 8bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Fri, 2021-08-27 at 10:56 +0000, Pepe TD Vo wrote: > > > I had master slave replica and yesterday the slave server's device was full on /var > > > where the archive copy from master.  After trying to figure out why the > > > pg_archivecleanup doesn't work, SA removed all wal files except the  current > > > > > > I tried to create a test table on master and didn't see it pick up from slave. > > > I found out again /var is full.  > > > > If you have deleted WAL that has no yet been applied to the standby, replication > > is broken and you have to build the standby from scratch. > > Can we delete the old WALs? Only the ones you don't need for replication. Of course, if you rebuild replication from scratch, you can delete the WAL archives. > May I know what is the retention to perform tuning on the server like Oracle to > keep only 7 days and why pg_archivecleanup doesn't work? I guess that pg_archivecleanup doesn't delete anything because it is only called once replication has processed a WAL segment and doesn't need it any more. If you are missing a WAL segment because you deleted it, replication gets stuck at that point and will wait indefinitely for that WAL segment. So nothing is processedm and nothing is deleted. A gap in the WAL will stop and break replication, as I said. Yours, Laurenz Albe -- Cybertec | https://www.cybertec-postgresql.com