Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1XeRQQ-0005m3-IX for pgsql-admin@arkaria.postgresql.org; Wed, 15 Oct 2014 16:27:46 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.80) (envelope-from ) id 1XeRQP-0001fZ-P3 for pgsql-admin@arkaria.postgresql.org; Wed, 15 Oct 2014 16:27:45 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1XeRQO-0001fT-Mw for pgsql-admin@postgresql.org; Wed, 15 Oct 2014 16:27:45 +0000 Received: from mail-qa0-x22b.google.com ([2607:f8b0:400d:c00::22b]) by makus.postgresql.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1XeRQL-0003Ko-HJ for pgsql-admin@postgresql.org; Wed, 15 Oct 2014 16:27:42 +0000 Received: by mail-qa0-f43.google.com with SMTP id s7so1089837qap.16 for ; Wed, 15 Oct 2014 09:27:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=I58C6b5GcPciZQ0SpWZKU4Vg6dgd//DZUItNY1ww0Dg=; b=S/Hj8zmqVgCkeqz+KDYnWJrqdtZ0rDuj0m9abyFzhJjDo5mw8rxMYToRaJ2opsFCsg MTxR4fAD1Mi8dEe2giroJH2jsp4hqkXa9fKZuJptjqojqflJuAfGjsnfnwEs/hHkgcVo 39cgyBCGQmGK4w4QEE+VlnhhroTMuJxw8fwBcwvse7je2nKxKV2QPch/G+f+ih4v7dvJ w3bFplWfrE/XCUbGVZrszJQ/DZMZBCrwOGaQYohqpBHr50P+gDGjAZkeuDYJUerGtXXk Chx+JnPp8BOPBDd6UHB0Pb+sNRy6PIEMXtp+1BDhjAUYncNbaXQWqz0y2d9NGhcRwWdQ j6Pw== X-Received: by 10.140.86.73 with SMTP id o67mr20318325qgd.67.1413390455809; Wed, 15 Oct 2014 09:27:35 -0700 (PDT) Received: from [192.168.254.3] (h77.89.102.166.static.ip.windstream.net. [166.102.89.77]) by mx.google.com with ESMTPSA id 18sm5454242qgl.5.2014.10.15.09.27.34 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 15 Oct 2014 09:27:35 -0700 (PDT) References: <3A8E2AE3D7AFB44F89EA82A873FBE4E6557E2CCA@DC-MBOX1.advisory.com> Mime-Version: 1.0 (1.0) In-Reply-To: <3A8E2AE3D7AFB44F89EA82A873FBE4E6557E2CCA@DC-MBOX1.advisory.com> Content-Type: multipart/alternative; boundary=Apple-Mail-215D4E0F-36B0-49CE-9D82-240207E53BE7 Content-Transfer-Encoding: 7bit Message-Id: <18EBD8DA-B2BE-4962-AC44-3FA7BC273803@gmail.com> Cc: "pgsql-admin@postgresql.org" X-Mailer: iPad Mail (11D257) From: jayknowsunix@gmail.com Subject: Re: WAL Archive Cleanup on Master/Standby Date: Wed, 15 Oct 2014 12:27:35 -0400 To: "Doiron, Daniel" X-Pg-Spam-Score: -2.0 (--) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-admin Precedence: bulk Sender: pgsql-admin-owner@postgresql.org --Apple-Mail-215D4E0F-36B0-49CE-9D82-240207E53BE7 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Daniel,=20 I use a custom script that I developed as we needed a reliable copy to a pai= r a standby servers. That script knows which WAL segment has been successful= ly copied to which server, and when it knows that both copies were successfu= l, it deletes the segment from the master. However, if one of the copies fai= led, the WAL segment is left on the primary where it is tried again the next= time it gets called. So far, it seems fairly reliable and consistent. -- Jay Sent from my iPad > On Oct 15, 2014, at 12:02 PM, "Doiron, Daniel" wrot= e: >=20 > I=E2=80=99m curious how others are cleaning up their WAL archive files and= other miscellany created by the process. > =20 > Here=E2=80=99s my setup: > =20 > Server A: archive_command executes a script that rsync=E2=80=99s the archi= ve file to a local folder and a matching folder on the standby server (does n= ot mirror the folder, just pushes the file twice) > =20 > Server B: recovery.conf archive_cleanup_command uses pg_archivecleanup to c= lean the standby archive folder and sends log output to a cleanup.log file > =20 > What I=E2=80=99m left with: > - WAL archive files on the Master server that only get cleaned up= if I fail over and recover using a new pg_basebackup from Server B to Serve= r A > - .history and .backup files on the standby server > - Entries in the cleanup.log file > =20 > Right now, I=E2=80=99m thinking my cleanup will involve (every 6 months): > - Failing over my cluster (kidding) > - Truncating the cleanup.log file > - ?? with .history and .backup files > =20 > What are you doing? --Apple-Mail-215D4E0F-36B0-49CE-9D82-240207E53BE7 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Daniel, 

I use a custom script that I developed as we needed a reliable copy to a pa= ir a standby servers. That script knows which WAL segment has been successfu= lly copied to which server, and when it knows that both copies were successf= ul, it deletes the segment from the master. However, if one of the copies fa= iled, the WAL segment is left on the primary where it is tried again the nex= t time it gets called. So far, it seems fairly reliable and consistent.
--
Jay

Sent from my iPad

On Oct 15, 201= 4, at 12:02 PM, "Doiron, Daniel" <DoironD@advisory.com> wrote:

=
=

I=E2=80=99m curious how others are cleaning up their W= AL archive files and other miscellany created by the process.

=

 

Here=E2=80=99s my setup:

 

Server A: archive_command executes a script that rsyn= c=E2=80=99s the archive file to a local folder and a matching folder on the s= tandby server (does not mirror the folder, just pushes the file twice)<= /o:p>

 

Server B: recovery.conf archive_cleanup_command uses p= g_archivecleanup to clean the standby archive folder and sends log output to= a cleanup.log file

 

What I=E2=80=99m left with:

-     &n= bsp;    WAL archive files on the Master server that only= get cleaned up if I fail over and recover using a new pg_basebackup from Se= rver B to Server A

-     &n= bsp;    .history and .backup files on the standby server=

-     &n= bsp;    Entries in the cleanup.log file

 

Right now, I=E2=80=99m thinking my cleanup will invol= ve (every 6 months):

-     &n= bsp;    Failing over my cluster (kidding)

=

-     &n= bsp;    Truncating the cleanup.log file

-     &n= bsp;    ?? with .history and .backup files

 

What are you doing?

= --Apple-Mail-215D4E0F-36B0-49CE-9D82-240207E53BE7--