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

Re: Sync Rep Design

From: Aidan Van Dyk <aidan(at)highrise(dot)ca>
To: Simon Riggs <simon(at)2ndquadrant(dot)com>
Cc: Josh Berkus <josh(at)postgresql(dot)org>, Stefan Kaltenbrunner <stefan(at)kaltenbrunner(dot)cc>, Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, greg(at)2ndquadrant(dot)com, Hannu Krosing <hannu(at)2ndquadrant(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Sync Rep Design
Date: 2011-01-02 03:11:10
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Sat, Jan 1, 2011 at 6:08 PM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
> 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.

I'm all for getting first-past-post in for 9.1.  Otherwise I fear
we'll get nothing.

Stephen and I will only be able to use 1 sync slave, the "DR-site"
one.  That's fine.  I can live with it, and make my local slave be
async.  Or replicate the FS/block under WAL.  I can monitor the ****
out of it, and unless it goes "down", it should easily be able to keep
up with the remote sync one beind a slower WAN link.

And I think both Stephen and I understand your availability math.
We're not arguing that the 1st past post both gives better query
availabiliyt, and cluster scale performance.

But when the primary datacenter servers are dust in the crater (or
boats in the flood, or ash in the fire), I either keep my job, or I
don't.  And that depends on whether there is a chance I (my database
system) confirmed a transaction that I can't recover.

So sync rep with 1st past post already makes my job easier.  I'll take
it over nothing ;-)


Aidan Van Dyk                                             Create like a god,
aidan(at)highrise(dot)ca                                       command like a king,                                   work like a slave.

In response to


pgsql-hackers by date

Next:From: Robert HaasDate: 2011-01-02 04:36:10
Subject: Re: Sync Rep Design
Previous:From: Simon RiggsDate: 2011-01-01 23:08:42
Subject: Re: Sync Rep Design

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