Re: 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 |
Дата | |
Msg-id | 4FC2FBBC.5020009@denninger.net обсуждение исходный текст |
Ответ на | Re: Attempting to do a rolling move to 9.2Beta (as a slave) fails (Jan Nielsen <jan.sture.nielsen@gmail.com>) |
Список | pgsql-general |
On 5/27/2012 11:08 PM, Jan Nielsen wrote:
I'll look at doing a parallel setup but it will more limited in what I can actually validate against in terms of workload than the above was workable...
Then the error message is wrong :-)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.)Okay1. 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.
I ran Slony for quite a while before 9.x showed up; I could put it back into use for a while but I really like the integrated setup that exists now with 9.x.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]
I'll look at doing a parallel setup but it will more limited in what I can actually validate against in terms of workload than the above was workable...
В списке pgsql-general по дате отправления: