From: Simon Riggs <simon@2ndQuadrant.com>
To: Stefan Kaltenbrunner <stefan@kaltenbrunner.cc>
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 19:03:30 +0000
Message-ID: <1293908610.1892.62786.camel@ebony> (raw)
In-Reply-To: <4D1F6938.1090101@kaltenbrunner.cc>
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>
<4D1F60B4.1060408@kaltenbrunner.cc>
<1293902960.1892.61053.camel@ebony>
<4D1F6938.1090101@kaltenbrunner.cc>
On Sat, 2011-01-01 at 18:49 +0100, Stefan Kaltenbrunner wrote:
> hmm maybe my "surviving" standbys(the case I'm wondering about is
> whole
> datacenter failures which might take out more than just the master)
> was
> not clear - consider three boxes, one master and two standby and
> semisync replication(ie any one of the standbys is enough to reply).
>
> 1. master fsyncs wal
> 2. standby #1 fsyncs and replies
> 3. master confirms commit
> 4. desaster strikes and destroys master and standby #1 while standby
> m2
> never had time to apply the change(IO/CPU load, latency, whatever)
> 5. now you have a sync standby that is missing something that was
> commited on the master and confirmed to the client and no way to
> verify
> that this thing happened (same problem with more than two standbys -
> as
> long as you lose ONE standby and the master at the same time you will
> never be sure)
This is obvious misconfiguration that anybody with HA experience would
spot immediately. If you have local standbys then you should mark them
as not available for sync rep, as described in the docs I've written.
> what is it that I'm missing here?
The fact that we've discussed this already and agreed to do 9.1 with
quorum_commit = 1. I proposed making this a parameter; other solutions
were also proposed, but it was considered too complex for this release.
This is a trade-off between availability and data guarantees.
MySQL and Oracle "suffer" from exactly this "problem". DB2 supports only
one master and SQLServer doesn't have sync rep at all.
--
Simon Riggs http://www.2ndQuadrant.com/books/
PostgreSQL Development, 24x7 Support, Training and Services
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: simon@2ndQuadrant.com, stefan@kaltenbrunner.cc, robertmhaas@gmail.com, jeff.janes@gmail.com
Subject: Re: Sync Rep Design
In-Reply-To: <1293908610.1892.62786.camel@ebony>
* 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