Re: standby registration (was: is sync rep stalled?)

On Tue, Oct 5, 2010 at 12:40 PM, Simon Riggs <simon@2ndquadrant.com> wrote:
>> Well, you only need to have the file at all on nodes you want to fail
>> over to.  And aren't you going to end up rejiggering the config when
>> you fail over anyway, based on what happened?  I mean, suppose you
>> have three servers and you require sync rep to 2 slaves.  If the
>> master falls over and dies, it seems likely you're going to want to
>> relax that restriction.  Or suppose you have three servers and you
>> require sync rep to 1 slave.  The first time you fail over, you're
>> going to probably want to leave that config as-is, but if you fail
>> over again, you're very likely going to want to change it.
>
> Single failovers are common. Multiple failovers aren't. For me, the key
> question is about what is the common case, not edge cases.

Hmm.  But even in the single failover cases, it's very possible that
you might want to make a change.  If you have two machines replicating
synchronously to each other in wait-forever and one of them goes down,
you're probably going to want to bring the other one up in
don't-wait-forever mode.  Or to take a slightly more complex example,
suppose you have two fast machines and a slow machine.  As long as
both fast machines are up, one will be the master and the other its
synchronous slave; the slow machine will be a reporting server.  But
if one of the fast machines dies, we might then want to make the slow
machine a synchronous slave just to make sure that our data remains
absolutely safe, even though it costs us some performance.

Using quorum_commit as a way to allow failover to happen and things to
keep humming along without configuration changes is a pretty clever
idea, but I think it only works in fairly specific cases.  For
example, the "three equal machines, sync me to one of the other two"
case is pretty slick, at least so long as you don't have more than one
failure.  I really can't improve on your design for that case; I'm not
sure there's any improvement to be had.  But I don't think your design
fits nearly as well in cases where the slaves aren't all equal, which
I actually think will be more common than not.

>> But since
>> that seems impossible to me, I'm arguing for centralizing the
>> configuration file for ease of management.
>
> You can't "centralize" something in 5 different places, at least not in
> my understanding of the word.

Every design we're talking about involves at least some configuration
on every machine in the cluster, AFAICS.  The no registration / quorum
commit solution sets the synchronization level and # of votes for each
standby on that standby, at least AIUI.  The registration solution
sets that stuff (and maybe other things, like a per-standby
wal_keep_segments) on the master, and the standby just provides a
name.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company