Re: Sync Rep Design

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.

> 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.

> 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.

--
Simon Riggs http://www.2ndQuadrant.com/books/
PostgreSQL Development, 24x7 Support, Training and Services