Re: Streaming-only Remastering - Mailing list pgsql-hackers

From Rob Wultsch
Subject Re: Streaming-only Remastering
Date
Msg-id CAGdn2ujAfqdtYijj52Bg9o+FMe-USHsUb3kAuvKQT3n=Xz2aFg@mail.gmail.com
Whole thread Raw
In response to Streaming-only Remastering  (Joshua Berkus <josh@agliodbs.com>)
List pgsql-hackers
On Sun, Jun 10, 2012 at 11:47 AM, Joshua Berkus <josh@agliodbs.com> wrote:
> So currently we have a major limitation in binary replication, where it is not possible to "remaster" your system
(thatis, designate the most caught-up standby as the new master) based on streaming replication only.  This is a major
limitationbecause the requirement to copy physical logs over scp (or similar methods), manage and expire them more than
doublesthe administrative overhead of managing replication.  This becomes even more of a problem if you're doing
cascadingreplication. 
>
> Therefore I think this is a high priority for 9.3.
>
> As far as I can tell, the change required for remastering over streaming is relatively small; we just need to add a
newrecord type to the streaming protocol, and then start writing the timeline change to that.  Are there other steps
requiredwhich I'm not seeing? 
>

Problem that may exist and is likely out of scope:
It is possible for a master with multiple slave servers to have slaves
which have not read all of the logs off of the master. It is annoying
to have to rebuild a replica because it was 1kb behind in reading logs
from the master. If the new master could deliver the last bit of the
old masters logs that would be very nice.

--
Rob Wultsch
wultsch@gmail.com


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: Time for pgindent run?
Next
From: Noah Misch
Date:
Subject: unlink for DROPs after releasing locks (was Re: Should I implement DROP INDEX CONCURRENTLY?)