Received: from maia.hub.org (maia-2.hub.org [200.46.204.251]) by mail.postgresql.org (Postfix) with ESMTP id 676BE1337B34 for ; Sat, 1 Jan 2011 07:54:59 -0400 (AST) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.251]) (amavisd-maia, port 10024) with ESMTP id 47458-06; Sat, 1 Jan 2011 11:54:52 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from outmail148112.authsmtp.co.uk (outmail148112.authsmtp.co.uk [62.13.148.112]) by mail.postgresql.org (Postfix) with ESMTP id 937471337999; Sat, 1 Jan 2011 07:54:51 -0400 (AST) Received: from mail-c187.authsmtp.com (mail-c187.authsmtp.com [62.13.128.33]) by punt9.authsmtp.com (8.14.2/8.14.2/Kp) with ESMTP id p01Bscpj024500; Sat, 1 Jan 2011 11:54:38 GMT Received: from [192.168.0.2] ([81.5.146.37]) (authenticated bits=0) by mail.authsmtp.com (8.14.2/8.14.2) with ESMTP id p01BsaRK087030; Sat, 1 Jan 2011 11:54:36 GMT Subject: Re: Sync Rep Design From: Simon Riggs To: Hannu Krosing Cc: Heikki Linnakangas , greg@2ndQuadrant.com, Josh Berkus , Robert Haas , Stefan Kaltenbrunner , pgsql-hackers@postgresql.org In-Reply-To: <4D1E4897.1050400@2ndquadrant.com> References: <1293729972.1892.23804.camel@ebony> <4D1CC47E.7050207@kaltenbrunner.cc> <1293735853.1892.24886.camel@ebony> <4D1D8B2F.5070001@2ndquadrant.com> <4D1DAB14.5000800@enterprisedb.com> <1293796137.1892.37313.camel@ebony> <4D1DCF5A.7070808@enterprisedb.com> <4D1E4897.1050400@2ndquadrant.com> Content-Type: text/plain; charset="UTF-8" Date: Sat, 01 Jan 2011 11:54:35 +0000 Message-ID: <1293882875.1892.56143.camel@ebony> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 7bit X-Server-Quench: e8619488-159d-11e0-ab46-001185d377ca X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCdxZQATClZOTQEd DAteCiN5VAwpPBRK HVkIKg5MJUcNSQVJ NksacRtFaARbZ1hf HGQLWlVEUVx7XGd/ aA0fZQRDZ1RPWwN0 U09WR1pVCwUmQRwA dF1PMGJyfwJGe34+ Z0RiXXYVCUx8dE95 SkZJFGgPMXphaTUf TREKcwVJcANLfxdA PlN4UyBcLwdSbGoL PyYYHB0LBgAXEzVT SUk3IEpabUsQHzE6 L59Y X-Authentic-SMTP: 61633235383639.1000:706 X-AuthFastPath: 0 (Was 255) X-AuthVirus-Status: No virus detected - but ensure you scan with your own anti-virus system. X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-1.9 tagged_above=-5 required=5 tests=BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001 X-Spam-Level: X-Archive-Number: 201101/4 X-Sequence-Number: 177841 On Fri, 2010-12-31 at 22:18 +0100, Hannu Krosing wrote: > 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. ... 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") 2. Having one primary and 2 standbys, either of which can acknowledge, and we lock up if both standbys fail to protect the data, then we will have 99.996% availability. Slightly less availability, but we don't put data at risk at any time, since any commit is always covered by at least 2 servers. ("Maximised protection") 3. If we have a primary and a single standby which must acknowledge, and we choose to lock up if the standby fails, then we will have only 96.04% availability. 4. If we have a primary and two standbys (named or otherwise), both of which must acknowledge or we lock up the master, then we have an awesome 94.12% availability. On the last two, there is also an increased likelihood of administrative cock-ups because of more specific and complex config requirements. -- Simon Riggs http://www.2ndQuadrant.com/books/ PostgreSQL Development, 24x7 Support, Training and Services