Re: Attempting to do a rolling move to 9.2Beta (as a slave) fails

Поиск
Список
Период
Сортировка
От Jan Nielsen
Тема Re: Attempting to do a rolling move to 9.2Beta (as a slave) fails
Дата
Msg-id CANxH4hGk8=ehR-9Vkpy90au9LbHA-7x=M2Eqt8wjfMc3O05zeg@mail.gmail.com
обсуждение исходный текст
Ответ на Attempting to do a rolling move to 9.2Beta (as a slave) fails  (Karl Denninger <karl@denninger.net>)
Ответы Re: Attempting to do a rolling move to 9.2Beta (as a slave) fails  (Karl Denninger <karl@denninger.net>)
Список pgsql-general
Hi Karl,

On Sun, May 27, 2012 at 9:18 PM, Karl Denninger <karl@denninger.net> wrote:
Here's what I'm trying to do in testing 9.2Beta1.

The current configuration is a master and a hot standby at a diverse location for both hot swap and "online" backup.  Both are archived regularly so if something goes south I can recover (to either as a master.)

Okay
 
1. Build 9.2Beta1; all fine.

2. Run a pg_basebackup from the current master machine (running 9.1) to a new directory on the slave machine, using the 9.2Beta1 pg_basebackup executable.

3. Run a pg_upgrade against that from the new binary directory, producing a 9.2Beta1 data store.

4. Attempt to start the result as a SLAVE against the existing 9.1 master.

Hmm - that's likely a problem: "In general, log shipping between servers running different major PostgreSQL release levels is not possible." [1]
 
Is this caused by the version mismatch?

Probably.
 
Do I need to run a complete parallel environment instead of trying to attach a 9.2Beta1 slave to an existing 9.1 master?  (and if so, why doesn't the code complain about the mismatch instead of the bogus WAL message?)

Slony [2] or PGBouncer+Londiste [3] should allow you to do this in an integrated fashion. [4]

 
Cheers,

Jan

В списке pgsql-general по дате отправления:

Предыдущее
От: Karl Denninger
Дата:
Сообщение: Attempting to do a rolling move to 9.2Beta (as a slave) fails
Следующее
От: Karl Denninger
Дата:
Сообщение: Re: Attempting to do a rolling move to 9.2Beta (as a slave) fails