Re: can we avoid pg_basebackup on planned switches? - Mailing list pgsql-general

From Ben Chobot
Subject Re: can we avoid pg_basebackup on planned switches?
Date
Msg-id 38021B1A-89C5-40B6-A51F-2DD06A7622CB@silentmedia.com
Whole thread Raw
In response to can we avoid pg_basebackup on planned switches?  (Ben Chobot <bench@silentmedia.com>)
List pgsql-general
Anybody?

On Jul 27, 2012, at 10:00 AM, Ben Chobot wrote:

We make heavy use of streaming replication on PG 9.1 and it's been great for us. We do have one issue with it, though, and that's when we switch master nodes - currently, the documentation says that you must run pg_basebackup on your old master to turn it into a slave. That makes sense when the old master had crashed, but it seems that in the case of a planned switch, we could do better. Here's what we tried that seemed to work... are we shooting ourselves in the foot?

1. Cleanly shut down the current master.
2. Pick a slave, turn it into the new master.
3. Copy the new pg_xlog history file over to the old master.
4. On any other slaves (many of our clusters are 3 nodes), we already have "recovery_target_timeline=latest" and wal archiving, so they should already be working as slaves of the new master.
5. Set up recovery.conf on the old master to be like the other slaves.
6. Start up the old master.

Have we just avoided running pg_basebackup, or have we just given ourselves data corruption? Because we're using wal archiving, can we simplify and leave out step 3?

pgsql-general by date:

Previous
From: Craig Ringer
Date:
Subject: Re: Installer problem report with interesting solution
Next
From: Menelaos PerdikeasSemantix
Date:
Subject: maximum number of databases and / or schemas in a single database instance