Received: from maia.hub.org (maia-2.hub.org [200.46.204.251]) by mail.postgresql.org (Postfix) with ESMTP id D6A511337B43 for ; Sun, 2 Jan 2011 21:31:13 -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 42902-07 for ; Mon, 3 Jan 2011 01:31:07 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.8]) by mail.postgresql.org (Postfix) with ESMTP id 59C181337B34 for ; Sun, 2 Jan 2011 21:31:06 -0400 (AST) Received: from [192.168.0.101] ([90.168.220.248]) by mrelayeu.kundenserver.de (node=mrbap2) with ESMTP (Nemesis) id 0M4kN3-1QY16Y2CiL-00zZkX; Mon, 03 Jan 2011 02:31:05 +0100 Message-ID: <4D2126A4.9050203@2ndquadrant.com> Date: Mon, 03 Jan 2011 02:30:12 +0100 From: Hannu Krosing User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: pgsql-hackers@postgresql.org Subject: Re: Sync Rep Design 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> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V02:K0:cN24a1OvbxSTKUflLPtodjVTp0QHLxE38HAX6wTyf0y YiL6S1kAQ+MiO/y9uF6Tw2dcbQILiXfEEMvi6xbMkEhaa5UZJ1 oya47Z4yLZqlIBkJumliQ9Kxk6PH/q7FOMgaJIS8EeFRUmotxE kTlqVezn1ds8sVeltg8JxZ7M+u2kz7pRF9gTtKoNhDGeuLYdeT av7ip+9GixuiQYPACuCWBLRxxrkfbqO8GbZWPpcDic= 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/101 X-Sequence-Number: 177938 On 2.1.2011 5:36, 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. If the master and one standby fail > simultaneously, the other standby is useless, because it may or may > not be caught up with the master. You know that the last transaction > acknowledged as committed by the master is on at least one of the two > standbys, but you don't know which one, and so you can't safely > promote the surviving standby. > (If you are working in an environment where promoting the surviving > standby when it's possibly not caught up is OK, then you don't need > sync rep in the first place: you can just run async rep and get much > better performance.) > So the availability is 98% (you are up when the master is up) + 98%^2 > * 2% (you are up when both slaves are up and the master is down) = > 99.92%. If you had only a single standby, then you could be certain > that any commit acknowledged by the master was on that standby. Thus > your availability would be 98% (up when master is up) + 98% * 2% (you > are up when the master is down and the slave is up) = 99.96%. > OTOH, in the case where you need _all_ the slaves to confirm any failing slave brings the master down, so adding a slave brings down availability by extra 2% The solution to achieving good durability AND availability is requiring N past the post instead of 1 past the post. In this case you can get to 99.9992% availability with master + 3 sync slaves, 2 of which have ACK. --------------------------------------- Hannu Krosing Performance and Infinite Scalability Consultant http://www.2ndQuadrant.com/books/