From: Stefan Kaltenbrunner <stefan@kaltenbrunner.cc>
To: Simon Riggs <simon@2ndQuadrant.com>
Cc: Robert Haas <robertmhaas@gmail.com>
Cc: Jeff Janes <jeff.janes@gmail.com>
Cc: pgsql-hackers@postgresql.org
Subject: Re: Sync Rep Design
Date: Sat, 01 Jan 2011 18:13:24 +0100
Message-ID: <4D1F60B4.1060408@kaltenbrunner.cc> (raw)
In-Reply-To: <1293900957.1892.60412.camel@ebony>
References: <1293729972.1892.23804.camel@ebony>
<4D1CC47E.7050207@kaltenbrunner.cc>
<1293735853.1892.24886.camel@ebony>
<4D1CEEAF.8050209@kaltenbrunner.cc>
<1293744235.1892.26478.camel@ebony>
<4D1D93F1.80602@kaltenbrunner.cc>
<1293791171.1892.36233.camel@ebony>
<AANLkTinq-Aii-6fG-QGXUGnkVUdy3rYt71kEb2aA9y7B@mail.gmail.com>
<4D1F3437.10503@kaltenbrunner.cc>
<AANLkTi=U6xzMpsrFbZkjQHrSnR_n+M9iGLrx0p8a4n+j@mail.gmail.com>
<4D1F4453.50903@kaltenbrunner.cc>
<1293900957.1892.60412.camel@ebony>
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".
ok
Stefan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: stefan@kaltenbrunner.cc, simon@2ndQuadrant.com, robertmhaas@gmail.com, jeff.janes@gmail.com
Subject: Re: Sync Rep Design
In-Reply-To: <4D1F60B4.1060408@kaltenbrunner.cc>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox