Re: Sync Rep Design

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