Re: Deleting WAL archives and pg_xlog when there is not a shared drive - Mailing list pgsql-general

From Sergey Konoplev
Subject Re: Deleting WAL archives and pg_xlog when there is not a shared drive
Date
Msg-id CAL_0b1sKn7uqSVXra2W5x_8xRzoHj=yaYr9Nuea=uMpU7x=awg@mail.gmail.com
Whole thread Raw
In response to Deleting WAL archives and pg_xlog when there is not a shared drive  ("Eng. AlSamman" <iyamen@live.com>)
Responses Re: Deleting WAL archives and pg_xlog when there is not a shared drive
List pgsql-general
On Tue, Dec 11, 2012 at 9:37 AM, Eng. AlSamman <iyamen@live.com> wrote:
> 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?)?

You can.

> Also, when N1 is started but now it
> must become a standby, I run pg_start_backup() on N2, sync the data
> directories (except pg_xlog) then pg_stop_backup() on N2.

You must not start N1 before you have done a base backup
(pg_start_backup()/pg_stop_backup()).

> Can I safely
> delete everything under pg_xlog in N1 BEFORE starting it since anyways they
> won't be used (what will be used instead is the archive directory on N1
> which is being populated by N2)?

You can delete everything under N1 data directory before making a base backup.

--
Database and Software Architect
http://www.linkedin.com/in/grayhemp

Phones:
USA +1 415 867 9984
Russia, Moscow +7 901 903 0499
Russia, Krasnodar +7 988 888 1979

Skype: gray-hemp
Jabber: gray.ru@gmail.com


pgsql-general by date:

Previous
From: Mihai Popa
Date:
Subject: Re: large database
Next
From: John R Pierce
Date:
Subject: Re: large database