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

Re: Sync Rep Design

From: Simon Riggs <simon(at)2ndQuadrant(dot)com>
To: Josh Berkus <josh(at)postgresql(dot)org>
Cc: 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-01 23:08:42
Message-ID: 1293923322.1892.65820.camel@ebony (view raw or flat)
Thread:
Lists: pgsql-hackers
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
 


In response to

Responses

pgsql-hackers by date

Next:From: Aidan Van DykDate: 2011-01-02 03:11:10
Subject: Re: Sync Rep Design
Previous:From: Simon RiggsDate: 2011-01-01 22:41:10
Subject: Re: Sync Rep Design

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