can we avoid pg_basebackup on planned switches?

Поиск
Список
Период
Сортировка
От Ben Chobot
Тема can we avoid pg_basebackup on planned switches?
Дата
Msg-id 08F5D866-B066-410C-86B0-C78A835C3A50@silentmedia.com
обсуждение исходный текст
Ответы Re: can we avoid pg_basebackup on planned switches?  (Ben Chobot <bench@silentmedia.com>)
Re: can we avoid pg_basebackup on planned switches?  (Fujii Masao <masao.fujii@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: "Ing.Edmundo.Robles.Lopez"
Дата:
Сообщение: REINDEX and COPY is wainting since Jun 21!
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Switching from OSX to Linux, multi-line queries in \copy don't work anymore