Received: from maia.hub.org (maia-5.hub.org [200.46.204.29]) by mail.postgresql.org (Postfix) with ESMTP id 64D341337B94 for ; Sat, 1 Jan 2011 19:09:01 -0400 (AST) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.29]) (amavisd-maia, port 10024) with ESMTP id 56409-10; Sat, 1 Jan 2011 23:08:55 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from outmail149043.authsmtp.co.uk (outmail149043.authsmtp.co.uk [62.13.149.43]) by mail.postgresql.org (Postfix) with ESMTP id AD17F1337B8D; Sat, 1 Jan 2011 19:08:53 -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 p01N8jWZ097559; Sat, 1 Jan 2011 23:08:45 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 p01N8h9A050591; Sat, 1 Jan 2011 23:08:44 GMT Subject: Re: Sync Rep Design From: Simon Riggs To: Josh Berkus Cc: Stefan Kaltenbrunner , Heikki Linnakangas , greg@2ndQuadrant.com, Hannu Krosing , Robert Haas , pgsql-hackers@postgresql.org In-Reply-To: <4D1FAD55.1090304@postgresql.org> 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> <1293822959.1892.43164.camel@ebony> <4D1F332A.90306@kaltenbrunner.cc> <4D1FAD55.1090304@postgresql.org> Content-Type: text/plain; charset="UTF-8" Date: Sat, 01 Jan 2011 23:08:42 +0000 Message-ID: <1293923322.1892.65820.camel@ebony> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 7bit X-Server-Quench: 14cb0971-15fc-11e0-ab46-001185d377ca X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCdxZQATClZOTQEd DAteCiN5VAwpPBRK HVkIKg5MJUcNSQVJ NksacRtFaARbZ1hf HGQLWlVEUl57WWt/ bw4fZQRDZ1RPWwN0 U09WR1pVCwUmQRwA eBZGW2hycgVDcX8+ ZENrXnQVXUApJ0Z0 RU9JFGhQNnphaTUf TREKcwVJcANLfxdA PlN4UyBcLwdSbGoL PyYYHB0LBgAXEzVT SUk3IEpabUsQHzE6 L79+ 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/43 X-Sequence-Number: 177880 On Sat, 2011-01-01 at 14:40 -0800, Josh Berkus wrote: > Standby in general deals with the A,D,R triangle (Availability, > Durability, Response time). "Any one" configuration is the A,R > configuration, and the only reason to go out with it for 9.1 is > because it's simpler to implement than the D,R configuration (all > standbys must ack). Nicely put. Not the "only reason" though... As I showed earlier, the AR gives you 99.999% availability and the DR gives you 94% availability, considering a 3 server config. If you add more servers, the availability of the DR option gets much worse, very quickly. The performance of AR is much better also, and stays same or better as cluster size increases. DR choice makes performance degrade as cluster size increases, since it works at the speed of the slowest node. The fact that I can get "5 Nines" with simpler code makes it even sweeter. quorum commit > 1 can improve the durability guarantee of data, but it also seems that many people wouldn't understand its implications and would mis-configure it, to our collective embarrassment. -- Simon Riggs http://www.2ndQuadrant.com/books/ PostgreSQL Development, 24x7 Support, Training and Services