Skip site navigation (1) Skip section navigation (2)

Re: Sync Rep Design

From: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
To: <simon(at)2ndquadrant(dot)com>,<heikki(dot)linnakangas(at)enterprisedb(dot)com>, <robertmhaas(at)gmail(dot)com>
Cc: <greg(at)2ndquadrant(dot)com>,<hannu(at)2ndquadrant(dot)com>, <stefan(at)kaltenbrunner(dot)cc>, <josh(at)postgresql(dot)org>, <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Sync Rep Design
Date: 2011-01-02 14:08:34
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Simon Riggs  wrote:
> On Sat, 2011-01-01 at 23:36 -0500, Robert Haas wrote:
>> On Sat, Jan 1, 2011 at 6:54 AM, Simon Riggs
>>> 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.
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.


pgsql-hackers by date

Next:From: Simon RiggsDate: 2011-01-02 16:24:15
Subject: Re: Sync Rep Design
Previous:From: Peter EisentrautDate: 2011-01-02 14:07:29
Subject: Re: Libpq PGRES_COPY_BOTH - version compatibility

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group