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.