Re: Configuring synchronous replication

On Thu, Sep 23, 2010 at 3:46 PM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
> Well, its not at all hard to see how that could be configured, because I
> already proposed a simple way of implementing parameters that doesn't
> suffer from those problems. My proposal did not give roles to named
> standbys and is symmetrical, so switchovers won't cause a problem.

I know you proposed a way, but my angst is all around whether it was
actually simple. I found it somewhat difficult to understand, so
possibly other people might have the same problem.

> Earlier you argued that centralizing parameters would make this nice and
> simple. Now you're pointing out that we aren't centralizing this at all,
> and it won't be simple. We'll have to have a standby.conf set up that is
> customised in advance for each standby that might become a master. Plus
> we may even need multiple standby.confs in case that we have multiple
> nodes down. This is exactly what I was seeking to avoid and exactly what
> I meant when I asked for an analysis of the failure modes.

If you're operating on the notion that no reconfiguration will be
necessary when nodes go down, then we have very different notions of
what is realistic. I think that "copy the new standby.conf file in
place" is going to be the least of the fine admin's problems.

>> One thing that's nice about the flat file system is that
>> > you can make the configuration changes on the new master before you
>> > promote it
>>
>> Actually, that's the killer argument in this whole thing.  If the
>> configuration information is in a system catalog, you can't change it
>> without the master being up and running.  Let us suppose for example
>> that you've configured hard synchronous replication such that the master
>> can't commit without slave acks.  Now your slaves are down and you'd
>> like to change that setting.  Guess what.
>
> If we have standby registration and I respect that some people want it,
> a table seems to be the best place for them. In a table the parameters
> are passed through from master to slave automatically without needing to
> synchronize multiple files manually.
>
> They can only be changed on a master, true. But since they only effect
> the behaviour of a master (commits => writes) then that doesn't matter
> at all. As soon as you promote a new master you'll be able to change
> them again, if required. Configuration options that differ on each node,
> depending upon the current state of others nodes are best avoided.

I think maybe you missed Tom's point, or else you just didn't respond
to it. If the master is wedged because it is waiting for a standby,
then you cannot commit transactions on the master. Therefore you
cannot update the system catalog which you must update to unwedge it.
Failing over in that situation is potentially a huge nuisance and
extremely undesirable.

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