From: Simon Riggs <simon@2ndQuadrant.com>
To: Jeff Janes <jeff.janes@gmail.com>
Cc: Stefan Kaltenbrunner <stefan@kaltenbrunner.cc>
Cc: pgsql-hackers@postgresql.org
Subject: Re: Sync Rep Design
Date: Sat, 01 Jan 2011 16:35:59 +0000
Message-ID: <1293899759.1892.60040.camel@ebony> (raw)
In-Reply-To: <AANLkTinq-Aii-6fG-QGXUGnkVUdy3rYt71kEb2aA9y7B@mail.gmail.com>
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>
On Sat, 2011-01-01 at 05:13 -0800, Jeff Janes wrote:
> On 12/31/10, Simon Riggs <simon@2ndquadrant.com> wrote:
> > On Fri, 2010-12-31 at 09:27 +0100, Stefan Kaltenbrunner wrote:
> >
> >> Maybe it has been discussed but I still don't see way it makes any
> >> sense. If I declare a standby a sync standby I better want it sync - not
> >> "maybe sync". consider the case of a 1 master and two identical sync
> >> standbys - one sync standby is in the same datacenter the other is in a
> >> backup location say 15km away.
> >> Given there is a small constant latency to the second box (even if you
> >> have fast networks) the end effect is that the second standby will NEVER
> >> be sync (because the local one will always be faster) and you end up
> >> with an async slave that cannot be used per your business rules?
> >
> > Your picture above is a common misconception. I will add something to
> > the docs to explain this.
> >
> > 1. "sync" is a guarantee about how we respond to the client when we
> > commit. If we wait for more than one response that slows things down,
> > makes the cluster more fragile, complicates the code and doesn't
> > appreciably improve the guarantee.
>
> Whether it is more fragile depends on if you look at up-time fragility
> or durability fragility. I think it can appreciably improve the
> guarantee.
Yes, agreed. That is why I proposed quorum commit earlier in 2010, as a
way to improve the durability guarantee. That was bogged down by the
requirement for named servers, which I see as unnecessary.
> > 2. "sync" does not guarantee that the updates to the standbys are in any
> > way coordinated. You can run a query on one standby and get one answer
> > and at the exact same time run the same query on another standby and get
> > a different answer (slightly ahead/behind). That also means that if the
> > master crashes one of the servers will be ahead or behind. You can use
> > pg_last_xlog_receive_location() to check which one that is.
>
> If at least one of the standbys is in the same smoking crater as the
> primary, then pg_last_xlog_receive_location on it is unlikely to
> respond.
>
> The guarantee goes away precisely when it is needed.
Fairly obviously, I would not be advocating anything that forced you to
use a server in the "same smoking crater". I can't see any guarantee
that goes away precisely when it is needed.
Perhaps you could explain the issue you see, because your comments seem
unrelated to my point above.
--
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, jeff.janes@gmail.com, stefan@kaltenbrunner.cc
Subject: Re: Sync Rep Design
In-Reply-To: <1293899759.1892.60040.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