Re: Sync Rep Design
От | Heikki Linnakangas |
---|---|
Тема | Re: Sync Rep Design |
Дата | |
Msg-id | 4D20ADC5.7070804@enterprisedb.com обсуждение исходный текст |
Ответ на | Re: Sync Rep Design (Simon Riggs <simon@2ndQuadrant.com>) |
Ответы |
Re: Sync Rep Design
|
Список | pgsql-hackers |
On 02.01.2011 15:41, Simon Riggs wrote: > On Sat, 2011-01-01 at 23:36 -0500, Robert Haas wrote: >> On Sat, Jan 1, 2011 at 6:54 AM, Simon Riggs<simon@2ndquadrant.com> wrote: >>> Yes, working out the math is a good idea. Things are much clearer if we >>> do that. >>> >>> Let's assume we have 98% availability on any single server. >>> >>> 1. Having one primary and 2 standbys, either of which can acknowledge, >>> and we never lock up if both standbys fail, then we will have 99.9992% >>> server availability. (So PostgreSQL hits "5 Nines", with data >>> guarantees). ("Maximised availability") >> >> I don't agree with this math. ...(snip by Simon)... 99.96%. > > OK, so that is at least 99.96%. Cool. > > The key point here is not (1), but option (4). > > The approach advocated by Heikki and yourself gives us 94% availability. > IMHO that is ridiculous, and I will not accept that as the *only* way > forwards, for that reason, whoever advocates it or for how long they > keep arguing. I do accept that some wish that as an option. No-one is suggesting that to be the only option. The "wait-for-all-to-ack" looks a lot less ridiculous if you also configure a timeout and don't wait for disconnected standbys. I'm not sure what the point of such a timeout in general is, but people have requested that. Also, setting synchronous_standbys="room1, room2" doesn't necessarily mean that you have just two standby servers, room1 and room2 might both represent a group of servers. I believe we all agree that there's different use cases that require different setups. Both "first-past-the-post" and "wait-for-all-to-ack" have their uses. There's no point in arguing over which is better. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: