Re: how to switch old replication Master to new Standby after promoting old Standby
От | Michael Paquier |
---|---|
Тема | Re: how to switch old replication Master to new Standby after promoting old Standby |
Дата | |
Msg-id | CAB7nPqRX9paYXoMCq7x+cfpxfQ+uiBFO1jFmEVAYjJkE=2yH4w@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: how to switch old replication Master to new Standby after promoting old Standby ("Shulgin, Oleksandr" <oleksandr.shulgin@zalando.de>) |
Список | pgsql-general |
On Mon, Mar 14, 2016 at 6:54 PM, Shulgin, Oleksandr <oleksandr.shulgin@zalando.de> wrote: > On Mon, Mar 14, 2016 at 6:28 PM, John Lumby <johnlumby@hotmail.com> wrote: >> 1. shut down both new Master and intended-to-be-new-Standby >> 2. on intended-to-be-new-Standby, remove the entire content of pg_xlog and >> the global/pg_control >> 3. from new Master , tar + scp the entire content of pg_xlog and the >> global/pg_control to intended-to-be-new-Standby This is not robust and will corrupt your standby. Just take the case of a relation data block modified on the to-be-new standby, and not replayed since the last checkpoint before WAL forked: data will be corrupted. Inconsistent pg_clog will likely break things. > That does seem like a very risky strategy to me. Have you taken a look at > pg_rewind (which is now part of the distribution)? pg_rewind has been designed for that, and ensures that the soon-to-be-standby has a minimum recovery target sufficient. You had better use it. -- Michael
В списке pgsql-general по дате отправления: