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

Re: Sync Rep Design

From: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
To: Simon Riggs <simon(at)2ndQuadrant(dot)com>
Cc: Stefan Kaltenbrunner <stefan(at)kaltenbrunner(dot)cc>, Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr>, 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 19:29:45
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On 01.01.2011 19:03, Simon Riggs wrote:
> 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
> disaster.

Dimitri just did, see above. I agree it's not very useful.

I don't think there's any other solution to knowing which standby is 
ahead than connect to both standbys and ask how far each is. I don't see 
a problem with that, whatever middleware handles the failover and 
STONITH etc. should be able to do that too.

   Heikki Linnakangas

In response to

pgsql-hackers by date

Next:From: Heikki LinnakangasDate: 2011-01-01 19:41:55
Subject: Re: Sync Rep Design
Previous:From: Filip RembiaƂkowskiDate: 2011-01-01 19:22:31
Subject: Re: Problems with autovacuum and vacuum

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