Received: from maia.hub.org (maia-3.hub.org [200.46.204.243]) by mail.postgresql.org (Postfix) with ESMTP id D1DB11337B7E for ; Sun, 2 Jan 2011 09:41:55 -0400 (AST) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.243]) (amavisd-maia, port 10024) with ESMTP id 66912-03; Sun, 2 Jan 2011 13:41:48 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from outmail148099.authsmtp.net (outmail148099.authsmtp.net [62.13.148.99]) by mail.postgresql.org (Postfix) with ESMTP id 2CC261337B34; Sun, 2 Jan 2011 09:41:48 -0400 (AST) Received: from mail-c187.authsmtp.com (mail-c187.authsmtp.com [62.13.128.33]) by punt2.authsmtp.com (8.14.2/8.14.2/Kp) with ESMTP id p02DfbYD053650; Sun, 2 Jan 2011 13:41:37 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 p02DfZZ7073815; Sun, 2 Jan 2011 13:41:35 GMT Subject: Re: Sync Rep Design From: Simon Riggs To: Robert Haas , Heikki Linnakangas Cc: Hannu Krosing , greg@2ndquadrant.com, Josh Berkus , Stefan Kaltenbrunner , pgsql-hackers@postgresql.org In-Reply-To: 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> <1293882875.1892.56143.camel@ebony> Content-Type: text/plain; charset="UTF-8" Date: Sun, 02 Jan 2011 13:41:13 +0000 Message-ID: <1293975673.2090.464.camel@ebony> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 7bit X-Server-Quench: 046a6bdf-1676-11e0-ab46-001185d377ca X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCdxZQATClZOTQEd DAteCiN5VAwpPBRK HVkIKg5MJUcNSQVJ NksacRtFaAdbZ1hf HGQLWlVEUV57XWJ/ aA8fZQRDZ1RPWwN0 U09WR1pVCwUmQRwD ckh0OB5ycAZOeXs+ ZE9iX3kVXEB8JEAv FhhJFGsBY3phaTUf TREKcwVJcANLfxdA PlN4UyBcLwdSbGoL PyYYHB0LBgAXEzVT SUk3IEpabUsQHzE6 L59c 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 X-Spam-Level: X-Archive-Number: 201101/71 X-Sequence-Number: 177908 On Sat, 2011-01-01 at 23:36 -0500, Robert Haas wrote: > On Sat, Jan 1, 2011 at 6:54 AM, Simon Riggs 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. If we are to have a sensible technical debate with an eventual end, you must answer the points placed in front of you, not just sidestep and try to point out problems somewhere else. All analysis must be applied to all options, not just those options advocated by someone else. I've been asking for a failure mode analysis for months and it never comes in full. I'm more than happy to discuss your additional points once we are clear on the 94% because it is pivotal to everything I've been proposing. -- Simon Riggs http://www.2ndQuadrant.com/books/ PostgreSQL Development, 24x7 Support, Training and Services