On Thu, 2010-09-23 at 13:07 -0400, Tom Lane wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
> > Now, admittedly, in more complex topologies, and especially if you're
> > using configuration options that pertain to the behavior of
> > disconnected standbys (e.g. wait for them, or retain WAL for them),
> > you're going to need to adjust the configs. But I think that's likely
> > to be true anyway, even with a catalog. If A is doing sync rep and
> > waiting for B even when B is disconnected, and the machines switch
> > roles, it's hard to see how any configuration isn't going to need some
> > adjustment.
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.
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.
This proposal is a configuration nightmare, no question, and that is not
the right way to go if you want high availability that works when you
need it to.
> 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.
-- Simon Riggs www.2ndQuadrant.comPostgreSQL Development, 24x7 Support, Training and Services