From: Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>
To: Josh Berkus <josh@postgresql.org>
Cc: Stefan Kaltenbrunner <stefan@kaltenbrunner.cc>
Cc: Simon Riggs <simon@2ndQuadrant.com>
Cc: greg@2ndQuadrant.com, Hannu Krosing <hannu@2ndquadrant.com>
Cc: Robert Haas <robertmhaas@gmail.com>
Cc: pgsql-hackers@postgresql.org
Subject: Re: Sync Rep Design
Date: Sun, 02 Jan 2011 10:35:07 +0200
Message-ID: <4D2038BB.7000504@enterprisedb.com> (raw)
In-Reply-To: <4D1FAD55.1090304@postgresql.org>
References: <1293729972.1892.23804.camel@ebony>
<4D1CC47E.7050207@kaltenbrunner.cc>
<1293735853.1892.24886.camel@ebony>
<AANLkTi=SvN2KQ1Tzh-tRKcXD0i2FyWFBbbR=kXXdepqN@mail.gmail.com>
<4D1D8B2F.5070001@2ndquadrant.com>
<4D1DAB14.5000800@enterprisedb.com>
<1293796137.1892.37313.camel@ebony>
<4D1DCF5A.7070808@enterprisedb.com>
<1293822959.1892.43164.camel@ebony>
<4D1F332A.90306@kaltenbrunner.cc>
<4D1FAD55.1090304@postgresql.org>
On 02.01.2011 00:40, Josh Berkus wrote:
> On 1/1/11 5:59 AM, Stefan Kaltenbrunner wrote:
>> well you keep saying that but to be honest I cannot really even see a
>> usecase for me - what is "only a random one of a set of servers is sync
>> at any time and I don't really know which one".
>> My usecases would al involved 2 sync standbys and 1 or more async ones.
>> but the second sync one would be in a different datacenter and I NEED to
>> protect against a datacenter failure which your proposals says I cannot
>> do :(
>
> As far as I know, *nobody* has written the bookkeeping code to actually
> track which standbys have ack'd. We need to get single-ack synch
> standby merged, tested and working before we add anything as complicated
> as "each standby on this list must ack". That means that it's extremely
> unlikely for 9.1 at this point.
The bookkeeping will presumably consist of an XLogRecPtr in shared
memory for each standby, tracking how far the standby has acknowledged.
At commit, you scan the standby slots in shared memory and check that
the required standbys have acknowledged your commit record. The
bookkeeping required is the same whether or not we support a list of
standbys that must ack or just one.
> Frankly, if Simon hadn't already submitted code, I'd be pushing for
> single-standby-only for 9.1, instead of "any one".
Yes, we are awfully late, but let's not panic.
BTW, there's a bunch of replication related stuff that we should work to
close, that are IMHO more important than synchronous replication. Like
making the standby follow timeline changes, to make failovers smoother,
and the facility to stream a base-backup over the wire. I wish someone
worked on those...
>> Hmm, access control... We haven't yet discussed what privileges a
>> standby needs to become synchronous. Perhaps it needs to be a separate
>> privilege that can be granted, in addition to the replication privilege?
>
> No, I don't think so. An additional priv would just complicate life for
> DBAs without providing any real benefit. You'd be guarding against the
> very narrow hypothetical case where there's a server admin with limited
> privs on the master, and authorization to create async standbies, but
> not the authorization to create s synch standby. How likely is that to
> *ever* happen?
Very likely. A synchronous standby can bring the master to a halt, while
an asynchronous one is rather harmless. If I were a DBA, and the data
wasn't very sensitive, I would liberally hand out async privileges to my
colleagues to set up reporting standbys, test servers etc. But I would
*not* give them synchronous privileges, because sooner or later one
would go "hmm, I wonder what happens if I make this synchronous", or
haphazardly copy the config file from a synchronous standby. That would
either bring down the master, or act as a "fake" standby, acknowledging
commits before they're flushed to the real synchronous standby. Either
one would be bad.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
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: heikki.linnakangas@enterprisedb.com, josh@postgresql.org, stefan@kaltenbrunner.cc, simon@2ndQuadrant.com, hannu@2ndquadrant.com, robertmhaas@gmail.com
Subject: Re: Sync Rep Design
In-Reply-To: <4D2038BB.7000504@enterprisedb.com>
* 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