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

From Ben Chobot
Subject can we avoid pg_basebackup on planned switches?
Date
Msg-id 08F5D866-B066-410C-86B0-C78A835C3A50@silentmedia.com
Whole thread Raw
Responses Re: can we avoid pg_basebackup on planned switches?
Re: can we avoid pg_basebackup on planned switches?
List pgsql-general
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: "Ing.Edmundo.Robles.Lopez"
Date:
Subject: REINDEX and COPY is wainting since Jun 21!
Next
From: Tom Lane
Date:
Subject: Re: Switching from OSX to Linux, multi-line queries in \copy don't work anymore