Re: Sync Rep Design
От | Hannu Krosing |
---|---|
Тема | Re: Sync Rep Design |
Дата | |
Msg-id | 4D1E4897.1050400@2ndquadrant.com обсуждение исходный текст |
Ответ на | Re: Sync Rep Design (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>) |
Ответы |
Re: Sync Rep Design
Re: Sync Rep Design |
Список | pgsql-hackers |
On 31.12.2010 13:40, Heikki Linnakangas wrote: > > Sounds good. > > I still don't like the synchronous_standbys='' and > synchronous_replication=on combination, though. IMHO that still > amounts to letting the standby control the behavior on master, and it > makes it impossible to temporarily add an asynchronous standby to the mix. A sync standby _will_have_ the ability to control the master anyway by simply being there or not. What is currently proposed is having dual power lines / dual UPS' and working happily on when one of them fails. Requiring both of them to be present defeats the original purpose of doubling them. So following Simons design of 2 standbys and only one required to ACK to commit you get 2X reliability of single standby. In a design where you have 2 standbys and both are required to ACK to commit you get only 1/2 the reliability of single standby. Having a list of 10 standbys and requiring ACK from all, you get only 10% of the reliability. I agree that there can be scenarios where you may need 10 sync copies before committing on master - usually for non-technical reasons like some accounting law or whatever - these are far rarer than requirement to have reasonable performance and 99.999% system uptime when using only 99.99% reliable hardware. And in such cases where you need multiple copies you will need some out-of-database technology (like signed timestamps) to make the data non-falsifiable as well, so you can't solve this with just configuring sync rep. > I could live with it, you wouldn't be forced to use it that way after > all, but I would still prefer to throw an error on that combination. > Or at least document the pitfalls and recommend always naming the > standbys. > >> My proposal amounts to "lets add synchronous_standbys as a parameter in >> 9.2". If you really think that we need that functionality in this >> release, lets get the basic stuff added now and then fold in those ideas >> on top afterwards. If we do that, I will help. However, my only >> insistence is that we explain the above points very clearly in the docs >> to specifically dissuade people from using those features for typical >> cases. > > Huh, wait, if you leave out synchronous_standbys, that's a completely > different UI again. I think we've finally reached agreement on how > this should be configured, let's stick to that, please. > > (I would be fine with limiting synchronous_standbys to just one server > in this release though.) > >> If you wondered why I ignored your post previously, its because I >> understood that Fujii's post of 15 Oct, one week later, effectively >> accepted my approach, albeit with two additional parameters. That is the >> UI that I had been following. >> http://archives.postgresql.org/pgsql-hackers/2010-10/msg01009.php > > That thread makes no mention of how to specify which standbys are > synchronous and which are not. The simplest way would be to have separate database users for sync and async standbys ? That would allow any standby with right credentials act as a sync user, and those who are not eligible are not accepted even if they try to act as "a synchronity (?) provider". > It's about specifying the timeout and whether to wait for a > disconnected standby. Yeah, Fujii-san's proposal seems reasonable for > configuring that. > -------------------- Hannu Krosing
В списке pgsql-hackers по дате отправления: