Received: from maia.hub.org (maia-2.hub.org [200.46.204.251]) by mail.postgresql.org (Postfix) with ESMTP id CBCFB1337B7E for ; Sun, 2 Jan 2011 12:24:49 -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 25208-09; Sun, 2 Jan 2011 16:24:42 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from outmail149078.authsmtp.net (outmail149078.authsmtp.net [62.13.149.78]) by mail.postgresql.org (Postfix) with ESMTP id D0ECC1337B39; Sun, 2 Jan 2011 12:24:41 -0400 (AST) Received: from mail-c194.authsmtp.com (mail-c194.authsmtp.com [62.13.128.121]) by punt8.authsmtp.com (8.14.2/8.14.2/Kp) with ESMTP id p02GOHUm006171; Sun, 2 Jan 2011 16:24:17 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 p02GOGAt093842; Sun, 2 Jan 2011 16:24:16 GMT Subject: Re: Sync Rep Design From: Simon Riggs To: Kevin Grittner Cc: heikki.linnakangas@enterprisedb.com, robertmhaas@gmail.com, greg@2ndquadrant.com, hannu@2ndquadrant.com, stefan@kaltenbrunner.cc, josh@postgresql.org, pgsql-hackers@postgresql.org In-Reply-To: <4D2032840200002500038EC2@gw.wicourts.gov> References: <4D2032840200002500038EC2@gw.wicourts.gov> Content-Type: text/plain; charset="UTF-8" Date: Sun, 02 Jan 2011 16:24:15 +0000 Message-ID: <1293985455.2090.1409.camel@ebony> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 7bit X-Server-Quench: be80e40d-168c-11e0-80b9-0022640b883e X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCdxZQATClZOTQEd DAteCiN5VAwpPBRK HVkIKg5MJUcNSQVJ NksafhtFaAdbZ1hf HGQLWlVEUVt7W2d/ agwfZQRDZ1RPWwN0 U09WR1pVCwUmQRwD cWFpI11yfgZOfHw+ ZE5gVnAVDhFydRN5 QhpJFGsONnphaTUf TUhYJQpJcANIfBlB agJ3XHBYLwdSbGoL PyYYHB0LBgAXEzVT SUk3IEpabUsQHzE6 LwPx X-Authentic-SMTP: 61633235383639.1015: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/77 X-Sequence-Number: 177914 On Sun, 2011-01-02 at 08:08 -0600, Kevin Grittner wrote: > I think you're talking about different metrics, and you're both > right. With two servers configured in sync rep your chance of having > an available (running) server is 99.9992%. The chance that you know > that you have one that is totally up to date, with no lost > transactions is 99.9208%. The chance that you *actually* have > up-to-date data would be higher, but you'd have no way to be sure. > The 99.96% number is your certainty that you have a running server > with up-to-date data if only one machine is sync rep. > > It's a matter of whether your shop needs five nines of availability > or the highest probability of not losing data. You get to choose. Thanks for those calculations. Do you agree that requiring response from 2 sync standbys, or locking up, gives us 94% server availability, but 99.9992% data durability? And that adding additional async servers would not increase the server availability of that cluster? Now lets look at what happens when we first start a standby: we do the base backup, configure the standby, it connects and then we cannot process any new transactions until the standby has caught up, which could well be hours on a big database. So if we don't have a processing mode that allows work to continue, how will we ever enable synchronous replication on a 24/7 database? How will we ever allow standbys to catch up if they drop out for a while? We should factor that into the availability calcs as well. -- Simon Riggs http://www.2ndQuadrant.com/books/ PostgreSQL Development, 24x7 Support, Training and Services