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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
