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

From: Karl Denninger <karl(at)denninger(dot)net>
To: Jan Nielsen <jan(dot)sture(dot)nielsen(at)gmail(dot)com>
Cc: Postgres General <pgsql-general(at)postgresql(dot)org>
Subject: Re: Attempting to do a rolling move to 9.2Beta (as a slave) fails
Date: 2012-05-28 04:14:52
Message-ID: 4FC2FBBC.5020009@denninger.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers

On 5/27/2012 11:08 PM, Jan Nielsen wrote:
> Hi Karl,
>
> On Sun, May 27, 2012 at 9:18 PM, Karl Denninger <karl(at)denninger(dot)net
> <mailto:karl(at)denninger(dot)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.
Then the error message is wrong :-)
>
>
> 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 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.

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...

--
-- Karl Denninger
/The Market Ticker ®/ <http://market-ticker.org>
Cuda Systems LLC

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Catalin M. Boie (ux) 2012-05-28 06:13:36 Re: [GENERAL] Forcefully adding a CHECK constrained
Previous Message Jan Nielsen 2012-05-28 04:08:15 Re: Attempting to do a rolling move to 9.2Beta (as a slave) fails

Browse pgsql-hackers by date

  From Date Subject
Next Message Harshitha S 2012-05-28 04:30:38 Re: proclock table corrupted
Previous Message Jan Nielsen 2012-05-28 04:08:15 Re: Attempting to do a rolling move to 9.2Beta (as a slave) fails