Thread: 9.2 Cascading replication after slave promotion
Looking at the docs (section 25.2.6 paragraph 6) leads one to believe that downstream standbys can continue to receive and process wal merely by reconnecting after the cascading standby is promoted - but this does not seem to be the case (indeed the same paragraph notes that timelines now no longer match). It looks to me like the downstream guys all need to be rebuilt - or am I missing something? Regards mark
Mark, > Looking at the docs (section 25.2.6 paragraph 6) leads one to believe > that downstream standbys can continue to receive and process wal merely > by reconnecting after the cascading standby is promoted - but this does > not seem to be the case (indeed the same paragraph notes that timelines > now no longer match). It looks to me like the downstream guys all need > to be rebuilt - or am I missing something? Per discussion on this list (search for "remastering"), 9.2 still won't allow standbies to point to a new master unless you are doing file-based replication. To date, I seem to be the only one convinced that this is an actual deficiency ... -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com
On 14/08/12 12:32, Josh Berkus wrote: > Mark, > >> Looking at the docs (section 25.2.6 paragraph 6) leads one to believe >> that downstream standbys can continue to receive and process wal merely >> by reconnecting after the cascading standby is promoted - but this does >> not seem to be the case (indeed the same paragraph notes that timelines >> now no longer match). It looks to me like the downstream guys all need >> to be rebuilt - or am I missing something? > Per discussion on this list (search for "remastering"), 9.2 still won't > allow standbies to point to a new master unless you are doing file-based > replication. > > To date, I seem to be the only one convinced that this is an actual > deficiency ... > > Make that 2 of us...
On Mon, Aug 13, 2012 at 5:32 PM, Josh Berkus <josh@agliodbs.com> wrote: > To date, I seem to be the only one convinced that this is an actual > deficiency ... It is an actual deficiency, and I am convinced. -- fdr
* Daniel Farina (daniel@heroku.com) wrote:
> On Mon, Aug 13, 2012 at 5:32 PM, Josh Berkus <josh@agliodbs.com> wrote:
> > To date, I seem to be the only one convinced that this is an actual
> > deficiency ...
>
> It is an actual deficiency, and I am convinced.
Yeah, I think there's more people that agree with this use-case than you
seem to think.. That said, I appreciate that it's not a trivial thing
to support cleanly.
Thanks,
Stephen
> Yeah, I think there's more people that agree with this use-case than you > seem to think.. That said, I appreciate that it's not a trivial thing > to support cleanly. Not trivial, no, but not major either. Really what needs to happen is for the timeline change record to get transmitted over the WAL stream. Hmmm. You know, I bet I could get stream-only remastering working in an unsafe way just by disabling the timeline checks. Time to test ... -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com
On Tue, 14 Aug 2012 10:50:07 -0700 Josh Berkus <josh@agliodbs.com> wrote: > > > Yeah, I think there's more people that agree with this use-case > > than you seem to think.. That said, I appreciate that it's not a > > trivial thing to support cleanly. > > Not trivial, no, but not major either. Really what needs to happen is > for the timeline change record to get transmitted over the WAL stream. > > Hmmm. You know, I bet I could get stream-only remastering working in > an unsafe way just by disabling the timeline checks. Time to test ... > Isn't that, what recovery_target_timeline in the recovery.conf already does? It switches to the next timeline after a master migration. See http://www.postgresql.org/docs/current/static/recovery-target-settings.html for further information.