Re: pg_basebackup from new master's slave then recovery from new master. - Mailing list pgsql-general

From Michael Paquier
Subject Re: pg_basebackup from new master's slave then recovery from new master.
Date
Msg-id CAB7nPqRZS-+U7v4PmfDcYQLRBWFmERgPavb7Dwxyo0vYcTmiXQ@mail.gmail.com
Whole thread Raw
In response to pg_basebackup from new master's slave then recovery from new master.  (Piotr Gasidło <quaker@barbara.eu.org>)
List pgsql-general
(Including the typo mistake mentioned in the 2nd email)

On Sat, Aug 17, 2013 at 8:47 PM, Piotr Gasidło <quaker@barbara.eu.org> wrote:
> All on 9.3beta2. Current setup:
>
> server1 (MASTER) -> server2 (SLAVE) -> server3 (SLAVE)
>
> server2 is hot_standby and gets WALs from server1
> server3 is hot_standby and gets WALs from server2
>
> In every recovery.conf I have:
>
> recovery_target_timeline='latest'
>
> Now i do switchover by touching recovery.conf's trigger_file on server2.
>
> server1 (OLD MASTER)
> server2 (NEW MASTER) -> server3 (SLAVE)
>
> Then, I take down server1 (OLD MASTER), do fresh pg_basebackup data
> from server3 (SLAVE) to server1 (OLD MASTER).
>
> Now:
>
> 1. I edit recovery.conf on server1 to NOT point to server3 (SLAVE) but
> server2 (NEW MASTER) and start server1
> 2. I edit recovery.conf on server3 to NOT point to server2 (NEW
> MASTER) but server1 (OLD MASTER) and restart server3
>
> I get this replication setup:
>
> server2 (NEW MASTER) -> server1 (OLD MASTER, SLAVE) -> server3 (SLAVE)
>
> Are these (1,2) operations safe? I did it on test environment but I
> need to be sure if I won't loose any data doing such things.
As long as the node on server1 is recreated with a new fresh backup
and is not-replugged on cluster as-is (former node on server1 might
have got ahead in term of WAL generation so it cannot reconnect to
server2 directly), there will be no problems of slave resync. In your
case, when you  restructure of your cluster, even if there is a lot of
WAL activity while you perform operation 2, server3 will sync up with
server1 after restarting.
--
Michael


pgsql-general by date:

Previous
From: Tyler Reese
Date:
Subject: Re: Select performance variation based on the different combinations of using where lower(), order by, and limit
Next
From: Robert Sosinski
Date:
Subject: Memory Issue with array_agg?