On Tue, Oct 5, 2010 at 10:46 AM, Simon Riggs <simon@2ndquadrant.com> wrote:
> On Tue, 2010-10-05 at 10:41 -0400, Robert Haas wrote:
>> >>
>> >> When you have one server functioning at each site you'll block until
>> >> you get a third machine back, rather than replicating to both sites
>> >> and remaining functional.
>> >
>> > And that is so important a consideration that you would like to move
>> > from one parameter in one file to a whole set of parameters, set
>> > differently in 5 separate files?
>>
>> I don't accept that this is the trade-off being proposed. You seem
>> convinced that having the config all in one place on the master is
>> going to make things much more complicated, but I can't see why.
>
> But it is not "all in one place" because the file needs to be different
> on 5 separate nodes. Which *does* make it more complicated than the
> alternative is a single parameter, set the same everywhere.
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.
This is really the key question for me. If distributing the
configuration throughout the cluster meant that we could just fail
over and keep on trucking, that would be, well, really neat, and a
very compelling argument for the design you are proposing. But since
that seems impossible to me, I'm arguing for centralizing the
configuration file for ease of management.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company