Re: standby registration (was: is sync rep stalled?) - Mailing list pgsql-hackers
From | Dave Page |
---|---|
Subject | Re: standby registration (was: is sync rep stalled?) |
Date | |
Msg-id | AANLkTimfmCGS7yrkksVKr_104773v8yxTsmPr4K1dG+B@mail.gmail.com Whole thread Raw |
In response to | Re: standby registration (was: is sync rep stalled?) (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>) |
Responses |
Re: standby registration (was: is sync rep stalled?)
|
List | pgsql-hackers |
On 10/7/10, Heikki Linnakangas <heikki.linnakangas@enterprisedb.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
pgsql-hackers by date: