Message-ID: <4D1E4897.1050400@2ndquadrant.com>
Date: Fri, 31 Dec 2010 22:18:15 +0100
From: Hannu Krosing <hannu@2ndquadrant.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US;
	rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7
MIME-Version: 1.0
To: Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>
CC: Simon Riggs <simon@2ndQuadrant.com>, greg@2ndQuadrant.com,
	Josh Berkus <josh@postgresql.org>, Robert Haas <robertmhaas@gmail.com>,
	Stefan Kaltenbrunner <stefan@kaltenbrunner.cc>,
	pgsql-hackers@postgresql.org
Subject: Re: Sync Rep Design
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>
In-Reply-To: <4D1DCF5A.7070808@enterprisedb.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

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