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

Re: Sync Rep Design

From: Simon Riggs <simon(at)2ndQuadrant(dot)com>
To: Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>
Cc: greg(at)2ndquadrant(dot)com, hannu(at)2ndquadrant(dot)com, heikki(dot)linnakangas(at)enterprisedb(dot)com, robertmhaas(at)gmail(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 17:43:02
Message-ID: 1293990182.2090.1914.camel@ebony (view raw or flat)
Thread:
Lists: pgsql-hackers
On Sun, 2011-01-02 at 11:11 -0600, Kevin Grittner wrote:
> Simon Riggs  wrote:
>  
> > Do you agree that requiring response from 2 sync standbys, or
> > locking up, gives us 94% server availability, but 99.9992% data
> > durability?
>  
> I'm not sure how to answer that.  The calculations so far have been
> based around up-time and the probabilities that you have a machine up
> at any moment and whether you can have confidence that if you do, you
> have all committed transactions represented.  There's been an implied
> assumption that the down time is unplanned, but not much else.  The
> above question seems to me to get into too many implied assumptions
> to feel safe throwing out a number without pinning those down a whole
> lot better.  If, for example, that 2% downtime always means the
> machine irretrievably went up in smoke, hitting unavailable means
> things are unrecoverable.  That's probably not the best assumption
> (at least outside of a combat zone), but what is?

Not really relevant. There's no room at all for downtime of any kind in
a situation where all servers must be available.

-- 
 Simon Riggs           http://www.2ndQuadrant.com/books/
 PostgreSQL Development, 24x7 Support, Training and Services
 


In response to

pgsql-hackers by date

Next:From: Dimitri FontaineDate: 2011-01-02 17:53:51
Subject: Re: Base Backup Streaming
Previous:From: Kevin GrittnerDate: 2011-01-02 17:11:33
Subject: Re: Sync Rep Design

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