On 12/30/2010 10:23 PM, Simon Riggs wrote:
On Thu, 2010-12-30 at 21:42 +0100, Stefan Kaltenbrunner wrote:
Synchronous replication offers the ability to guarantee that all changes
made by a transaction have been transferred to at least one remote
standby server. This is an extension to the standard level of durability
offered by a transaction commit. This is referred to as semi-synchronous
replication.
When synchronous replication is requested, the commit of a write
transaction will wait until confirmation that the commit record has been
transferred successfully to at least one standby server. Waiting for
confirmation increases the user's confidence that the changes will not
be lost in the event of server crashes but it also necessarily increases
the response time for the requesting transaction. The minimum wait time
is the roundtrip time from primary to standby.
hmm this is one of the main problems I see with the proposed "master is
sometimes aware of the standby"(as in the feedback mode) concept this
proposal has. If it waits for only one of the standbys there is some
issue with the terminology. As a DBA I would expect the master to only
return if ALL of the "sync replication" declared nodes replied ok.
Well, as a DBA, I expect it to work with just one. That's how MySQL and
Oracle work at least. If ALL standbys reply, it takes longer, makes the
code harder, how do you determine what "all" is robustly etc.. Plus its
been discussed already.
Maybe it has been discussed but I still don't see way it makes any
sense. If I declare a standby a sync standby I better want it sync - not
"maybe sync". consider the case of a 1 master and two identical sync
standbys - one sync standby is in the same datacenter the other is in a
backup location say 15km away.
Given there is a small constant latency to the second box (even if you
have fast networks) the end effect is that the second standby will NEVER
be sync (because the local one will always be faster) and you end up
with an async slave that cannot be used per your business rules?
What I'm really missing with that proposal is how people expect that
solution to be managed -
What aspect do you wish to monitor? I'm happy to consider your
suggestions.
given there is only sometimes a feedback
channel into the master you can't do the monitoring.
Not sure what you mean. Please explain more.
well hot_standby_feedback(not sure I like the name but I can't think of
anything better either) - provides feedback to the master(like sync rep)
and the master is actually acting on that feedback. so in effect we have
stuff affecting the master that we need to be able to monitor clearly.
But to make that information useful it would help to see what standby
provided what kind of feedback so we are back to having the master being
aware of what standbys are connected and what standbys are supposed to
be there - which is the issue sync rep got stalled before...
Even if you could (which we really need!) there is nothing in the
proposal yet that will help to determine on what the most recent standby
(in the case of more>1 sync standby) might be.
Functions to determine that already exist.
- but it would require a real standby
registration or at least standby management possibility on the master
not a halfway done one - so do we really need hot_standby_feedback as
part of the inital sync-rep patch?
It is a Hot Standby feature, but so tightly integrated with this code
that it isn't possible for me to submit as two separate patches.
well you are the developer of that feature but if it is already a know
that can be turned on and off it seems not to hard to submit as a
seperate feature...
Stefan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
