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

On 10/7/10, Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> wrote:
> On 06.10.2010 19:26, Greg Smith wrote:
>> Now, the more relevant question, what I actually need in order for a
>> Sync Rep feature in 9.1 to be useful to the people who want it most I
>> talk to. That would be a simple to configure setup where I list a subset
>> of "important" nodes, and the appropriate acknowledgement level I want
>> to hear from one of them. And when one of those nodes gives that
>> acknowledgement, commit on the master happens too. That's it. For use
>> cases like the commonly discussed "two local/two remote" situation, the
>> two remote ones would be listed as the important ones.
>
> This feels like the best way forward to me. It gives some flexibility,
> and doesn't need a new config file.
>
> Let me check that I got this right, and add some details to make it more
> concrete: Each standby is given a name. It can be something like
> "boston1" or "testserver". It does *not* have to be unique across all
> standby servers. In the master, you have a list of important,
> synchronous, nodes that must acknowledge each commit before it is
> acknowledged to the client.
>
> The standby name is a GUC in the standby's configuration file:
>
> standby_name='bostonserver'
>
> The list of important nodes is also a GUC, in the master's configuration
> file:
>
> synchronous_standbys='bostonserver, oxfordserver'
>
> To configure for a simple setup with a master and one synchronous
> standby (which is not a very good setup from availability point of view,
> as discussed to death), you give the standby a name, and put the same
> name in synchronous_standbys in the master.
>
> To configure a setup with a master and two standbys, so that a commit is
> acknowledged to client as soon as either one of the standbys acknowledge
> it, you give both standbys the same name, and the same name in
> synchronous_standbys list in the master. This is the configuration that
> gives zero data loss in case one server fails, but also caters for
> availability because you don't need to halt the master if one standby fails.
>
> To configure a setup with a master and two standbys, so that a commit is
> acknowledged to client after *both* standbys acknowledge it, you give
> both standbys a different name, and list both names in
> synchronous_standbys_list in the master.
>
> I believe this will bend to most real life scenarios people have.

+1. I think this would have met any needs of mine in my past life as a
sysadmin/dba.

>
> Now, the other big fight is over "wait forever" vs "timeout".
> Personally, I'm stand firmly in the "wait forever" camp - you're nuts if
> you want a timeout. However, I can see that not everyone agrees :-).
> Fortunately, once we have robust "wait forever" behavior, it shouldn't
> be hard at all to add a timeout option on top of that, for those who
> want it. We should be able to have both options
>

I disagree that you're nuts if you want this feature fwiw. +1 on your
suggested plan though :-)

/D