can we avoid pg_basebackup on planned switches?

From: Ben Chobot <bench(at)silentmedia(dot)com>
To: Postgresql General <pgsql-general(at)postgresql(dot)org>
Subject: can we avoid pg_basebackup on planned switches?
Date: 2012-07-27 17:00:41
Message-ID: 08F5D866-B066-410C-86B0-C78A835C3A50@silentmedia.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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?

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Tom Lane 2012-07-27 17:06:10 Re: Switching from OSX to Linux, multi-line queries in \copy don't work anymore
Previous Message Ing.Edmundo.Robles.Lopez 2012-07-27 16:59:49 REINDEX and COPY is wainting since Jun 21!