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

Re: Sync Rep Design

From: Jeff Janes <jeff(dot)janes(at)gmail(dot)com>
To: Simon Riggs <simon(at)2ndquadrant(dot)com>
Cc: Stefan Kaltenbrunner <stefan(at)kaltenbrunner(dot)cc>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Sync Rep Design
Date: 2011-01-01 13:13:07
Message-ID: AANLkTinq-Aii-6fG-QGXUGnkVUdy3rYt71kEb2aA9y7B@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On 12/31/10, Simon Riggs <simon(at)2ndquadrant(dot)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.

>
> 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.

Cheers,

Jeff

In response to

Responses

pgsql-hackers by date

Next:From: Stefan KaltenbrunnerDate: 2011-01-01 13:59:06
Subject: Re: Sync Rep Design
Previous:From: Peter EisentrautDate: 2011-01-01 12:50:28
Subject: Re: pl/python refactoring

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