From: Hannu Krosing <hannu@2ndquadrant.com>
To: Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>
Cc: Simon Riggs <simon@2ndQuadrant.com>
Cc: greg@2ndQuadrant.com, Josh Berkus <josh@postgresql.org>
Cc: Robert Haas <robertmhaas@gmail.com>
Cc: Stefan Kaltenbrunner <stefan@kaltenbrunner.cc>
Cc: pgsql-hackers@postgresql.org
Subject: Re: Sync Rep Design
Date: Fri, 31 Dec 2010 22:18:15 +0100
Message-ID: <4D1E4897.1050400@2ndquadrant.com> (raw)
In-Reply-To: <4D1DCF5A.7070808@enterprisedb.com>
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>
On 31.12.2010 13:40, Heikki Linnakangas wrote:
>
> Sounds good.
>
> I still don't like the synchronous_standbys='' and
> synchronous_replication=on combination, though. IMHO that still
> amounts to letting the standby control the behavior on master, and it
> makes it impossible to temporarily add an asynchronous standby to the mix.
A sync standby _will_have_ the ability to control the master anyway by
simply being there or not.
What is currently proposed is having dual power lines / dual UPS' and
working happily on when one of them fails.
Requiring both of them to be present defeats the original purpose of
doubling them.
So following Simons design of 2 standbys and only one required to ACK to
commit you get 2X reliability of single standby.
In a design where you have 2 standbys and both are required to ACK to
commit you get only 1/2 the reliability of single standby.
Having a list of 10 standbys and requiring ACK from all, you get only
10% of the reliability.
I agree that there can be scenarios where you may need 10 sync copies
before committing on master - usually for non-technical reasons like
some accounting law or whatever - these are far rarer than requirement
to have reasonable performance and 99.999% system uptime when using only
99.99% reliable hardware. And in such cases where you need multiple
copies you will need some out-of-database technology (like signed
timestamps) to make the data non-falsifiable as well, so you can't solve
this with just configuring sync rep.
> I could live with it, you wouldn't be forced to use it that way after
> all, but I would still prefer to throw an error on that combination.
> Or at least document the pitfalls and recommend always naming the
> standbys.
>
>> My proposal amounts to "lets add synchronous_standbys as a parameter in
>> 9.2". If you really think that we need that functionality in this
>> release, lets get the basic stuff added now and then fold in those ideas
>> on top afterwards. If we do that, I will help. However, my only
>> insistence is that we explain the above points very clearly in the docs
>> to specifically dissuade people from using those features for typical
>> cases.
>
> Huh, wait, if you leave out synchronous_standbys, that's a completely
> different UI again. I think we've finally reached agreement on how
> this should be configured, let's stick to that, please.
>
> (I would be fine with limiting synchronous_standbys to just one server
> in this release though.)
>
>> If you wondered why I ignored your post previously, its because I
>> understood that Fujii's post of 15 Oct, one week later, effectively
>> accepted my approach, albeit with two additional parameters. That is the
>> UI that I had been following.
>> http://archives.postgresql.org/pgsql-hackers/2010-10/msg01009.php
>
> That thread makes no mention of how to specify which standbys are
> synchronous and which are not.
The simplest way would be to have separate database users for sync and
async standbys ?
That would allow any standby with right credentials act as a sync user,
and those who are not eligible are not accepted even if they try to act
as "a synchronity (?) provider".
> It's about specifying the timeout and whether to wait for a
> disconnected standby. Yeah, Fujii-san's proposal seems reasonable for
> configuring that.
>
--------------------
Hannu Krosing
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: hannu@2ndquadrant.com, heikki.linnakangas@enterprisedb.com, simon@2ndQuadrant.com, josh@postgresql.org, robertmhaas@gmail.com, stefan@kaltenbrunner.cc
Subject: Re: Sync Rep Design
In-Reply-To: <4D1E4897.1050400@2ndquadrant.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