On Fri, 2010-05-14 at 15:15 -0400, Robert Haas wrote:
> On Fri, May 14, 2010 at 9:33 AM, Boszormenyi Zoltan <zb@cybertec.at> wrote:
> > If min_sync_replication_clients == 0, then the replication is async.
> > If min_sync_replication_clients == max_wal_senders then the
> > replication is fully synchronous.
> > If 0 < min_sync_replication_clients < max_wal_senders then
> > the replication is partially synchronous, i.e. the master can wait
> > only for say, 50% of the clients to report back before it's considered
> > synchronous and the relevant transactions get released from the wait.
>
> That's an interesting design and in some ways pretty elegant, but it
> rules out some things that people might easily want to do - for
> example, synchronous replication to the other server in the same data
> center that acts as a backup for the master; and asynchronous
> replication to a reporting server located off-site.
The design above allows the case you mention:
min_sync_replication_clients = 1
max_wal_senders = 2
It works well in failure cases, such as the case where the local backup
server goes down.
It seems exactly what we need to me, though not sure about names.
> One of the things that I think we will probably need/want to change
> eventually is the fact that the master has no real knowledge of who
> the replication slaves are. That might be something we want to change
> in order to be able to support more configurability. Inventing syntax
> out of whole cloth and leaving semantics to the imagination of the
> reader:
>
> CREATE REPLICATION SLAVE reporting_server (mode asynchronous, xid_feedback on);
> CREATE REPLICATION SLAVE failover_server (mode synchronous,
> xid_feedback off, break_synchrep_timeout 30);
I am against labelling servers as synchronous/asynchronous. We've had
this discussion a few times since 2008.
There is significant advantage in having the user specify the level of
robustness, so that it can vary from transaction to transaction, just as
already happens at commit. That way the user gets to say what happens.
Look for threads on "transaction controlled robustness".
As alluded to above, if you label the servers you also need to say what
happens when one or more of them are down. e.g. "synchronous to B AND
async to C, except when B is not available, in which case make C
synchronous". With N servers, you end up needing to specify O(N^2) rules
for what happens, so it only works neatly for 2, maybe 3 servers.
-- Simon Riggs www.2ndQuadrant.com