Re: Streaming-only Remastering

From: Rob Wultsch <wultsch(at)gmail(dot)com>
To: Joshua Berkus <josh(at)agliodbs(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Streaming-only Remastering
Date: 2012-06-10 19:21:53
Message-ID: CAGdn2ujAfqdtYijj52Bg9o+FMe-USHsUb3kAuvKQT3n=Xz2aFg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sun, Jun 10, 2012 at 11:47 AM, Joshua Berkus <josh(at)agliodbs(dot)com> wrote:
> So currently we have a major limitation in binary replication, where it is not possible to "remaster" your system (that is, designate the most caught-up standby as the new master) based on streaming replication only.  This is a major limitation because the requirement to copy physical logs over scp (or similar methods), manage and expire them more than doubles the administrative overhead of managing replication.  This becomes even more of a problem if you're doing cascading replication.
>
> 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 new record type to the streaming protocol, and then start writing the timeline change to that.  Are there other steps required which 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(at)gmail(dot)com

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Noah Misch 2012-06-10 20:19:53 unlink for DROPs after releasing locks (was Re: Should I implement DROP INDEX CONCURRENTLY?)
Previous Message Bruce Momjian 2012-06-10 19:21:24 Re: Time for pgindent run?