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

Re: Sync Rep Design

From: Simon Riggs <simon(at)2ndQuadrant(dot)com>
To: Stefan Kaltenbrunner <stefan(at)kaltenbrunner(dot)cc>
Cc: Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr>, Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, greg(at)2ndQuadrant(dot)com, Josh Berkus <josh(at)postgresql(dot)org>, 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 17:03:48
Message-ID: 1293901428.1892.60565.camel@ebony (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Sat, 2011-01-01 at 17:37 +0100, Stefan Kaltenbrunner wrote:
> On 01/01/2011 05:28 PM, Dimitri Fontaine wrote:
> > Stefan Kaltenbrunner<stefan(at)kaltenbrunner(dot)cc>  writes:
> >> well you keep saying that but to be honest I cannot really even see a
> >> usecase for me - what is "only a random one of a set of servers is sync at
> >> any time and I don't really know which one".
> >
> > It looks easy enough to get to know which one it is.  Surely the primary
> > knows and could update something visible through a system view for
> > users?  This as been asked for before and I was thinking there was a
> > consensus on this.
> well as jeff janes already said - anything that requires the master to 
> still exist is not useful for a desaster.

Nobody has suggested that the master needs to still exist after a

>  Consider the now often 
> mentioned 2 sync standby scenario with one standby in the same location 
> and one in a secondary location.
> If you have a desaster(fire,water,explosion,admin fail,...) at the 
> primary location and you have no access to either the master or the 
> standby you will never be sure that the standby on the secondary 
> location is actually "in sync" - it could be but you will never know if 
> you lost that 1B$ invoice just commited on the master and the closeby 
> standby and therefor confirmed to the client...

I've never suggested you configure your systems like that. It would of
course be stupid.

This is not a sensible technical discussion. I'll go back to coding.

 Simon Riggs 
 PostgreSQL Development, 24x7 Support, Training and Services

In response to


pgsql-hackers by date

Next:From: Stefan KaltenbrunnerDate: 2011-01-01 17:13:24
Subject: Re: Sync Rep Design
Previous:From: Simon RiggsDate: 2011-01-01 16:55:57
Subject: Re: Sync Rep Design

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