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

Re: Sync Rep Design

From: Stefan Kaltenbrunner <stefan(at)kaltenbrunner(dot)cc>
To: Simon Riggs <simon(at)2ndQuadrant(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Sync Rep Design
Date: 2011-01-01 17:13:24
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On 01/01/2011 05:55 PM, Simon Riggs wrote:
> On Sat, 2011-01-01 at 16:12 +0100, Stefan Kaltenbrunner wrote:
>> I still would like to get a statement on why simon thinks that
>> the design heikki and others have proposed
> I've explained in huge detail why I think what I think, nor avoided any
> technical issue.
> It appears to me there has been substantial confusion over alternatives,
> because of a misunderstanding about how synchronisation works. Requiring
> confirmation that standbys are in sync is *not* the same thing as them
> actually being in sync. Every single proposal made by anybody here on
> hackers that supports multiple standby servers suffers from the same
> issue: when the primary crashes you need to work out which standby
> server is ahead.

aaah that was exactly what I was after - so the problem is that when you 
have a sync standby it will technically always be "in front" of the 
master (because it needs to fsync/apply/whatever before the master).
In the end the question boils down to what is "the bigger problem" in 
the case of a lost master:

a) a transaction that was confirmed on the master but might not be on 
any of the surviving sync standbys (or you will never know if it is) - 
this is how I understand the proposal so far
b) a transaction that was not yet confirmed on the master but might have 
been applied on the surving standby before the desaster - this is what I 
understand "confirm from all sync standbys" could result in.

Spelled out that more clearly now makes me a bit reconsider on what I 
said before but I still wonder if ultimately we will have to provide 
both modes to satisfy different business requirements (a might provide 
the more accurate answer on average but b might at least provide a way 
to identify the "wild" transaction buy looking at additional data)

>> - The docs should not allege that either setup is preferable to the
>>> other, because there is not now and will never be consensus that this
>>> is in fact true.
> I remain hopeful that people will read what I have read and understand
> it. Having taken the trouble to do that publicly, my conscious is clear
> that I've done the very best to explain things and make it easy for
> users to avoid error. If I am prevented from putting sound advice into
> the docs, I'll not worry too much.
>> well I should think we need to clearly spell out everything that affects
>> reliability and if we only support semi-sync for more than 1 standby we
>> have only that setup :)
> You can use sync rep with 1 or more standby servers.
> At the end of the day, I can't stop anyone from saying "What an idiot,
> he designed something that gave the same durability and availability as
> Oracle and MySQL do, yet with additional performance management
> features".



In response to


pgsql-hackers by date

Next:From: Simon RiggsDate: 2011-01-01 17:17:53
Subject: Re: ALTER TABLE .. SET SCHEMA lock strength
Previous:From: Simon RiggsDate: 2011-01-01 17:03:48
Subject: Re: Sync Rep Design

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