Re: Sync Rep Design

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