From: | Sergey Konoplev <gray(dot)ru(at)gmail(dot)com> |
---|---|
To: | "Eng(dot) AlSamman" <iyamen(at)live(dot)com> |
Cc: | pgsql-general <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Deleting WAL archives and pg_xlog when there is not a shared drive |
Date: | 2012-12-11 22:06:32 |
Message-ID: | CAL_0b1sKn7uqSVXra2W5x_8xRzoHj=yaYr9Nuea=uMpU7x=awg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Tue, Dec 11, 2012 at 9:37 AM, Eng. AlSamman <iyamen(at)live(dot)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(dot)ru(at)gmail(dot)com
From | Date | Subject | |
---|---|---|---|
Next Message | John R Pierce | 2012-12-11 22:17:29 | Re: large database |
Previous Message | Mihai Popa | 2012-12-11 22:01:40 | Re: large database |