|
Thanks for the input Jeff. The purpose is primarily automating failover (high-availability). There is no intention of using PITR.
We decided to actually keep the WAL logs in the archive directory (until they start to pose a storage problem) and delete what's under pg_xlog (in the situation I already mentioned in my original message). > Date: Wed, 12 Dec 2012 08:24:21 -0800 > Subject: Re: Deleting WAL archives and pg_xlog when there is not a shared drive > From: jeff.janes@xxxxxxxxx > To: iyamen@xxxxxxxx > CC: pgsql-general@xxxxxxxxxxxxxx > > On Tue, Dec 11, 2012 at 9:37 AM, Eng. AlSamman <iyamen@xxxxxxxx> wrote: > > Hello everyone, > > > > I am trying to implement a high-availability cluster using only two nodes, > > without any shared disk storage. > > > > In my implementation, the primary database has continuous archiving set up > > to a directory residing on the second node, where the standby database is. > > Streaming replication is also established between the two. When failover > > occurs, the standby is promoted to primary, and will start its continuous > > archiving but now on a directory on the other (former primary) node. > > > > Call the primary node N1 and the standby N2. When N1 fails and N2 is > > promoted, can I safely delete the archive logs stored on N2 (which were > > archived by N1 when it was primary?)? > > That depends on your backup policy. Do you try to maintain some kind > of PITR availability window, or are you solely concerned with hardware > issues and not human error? > > In any case, in the middle of an unusual event seems like a poor time > to go around cleaning up only tangentially related things. > > Cheers, > > Jeff |
