On Tue, 2010-05-25 at 19:08 +0200, Alastair Turner wrote:
> On Tue, May 25, 2010 at 6:28 PM, Simon Riggs <simon@2ndquadrant.com> wrote:
> .......
> >
> > The best parameter we can specify is the number of servers that we wish
> > to wait for confirmation from. That is a definition that easily manages
> > the complexity of having various servers up/down at any one time. It
> > also survives misconfiguration more easily, as well as providing a
> > workaround if replicating across a bursty network where we can't
> > guarantee response times, even of the typical response time is good.
> >
>
> This may be an incredibly naive question, but what happens to the
> transaction on the master if the number of confirmations is not
> received? Is this intended to create a situation where the master
> effectively becomes unavailable for write operations when its
> synchronous slaves are unavailable?
How we handle degraded mode is important, yes. Whatever parameters we
choose the problem will remain the same.
Should we just ignore degraded mode and respond as if nothing bad had
happened? Most people would say not.
If we specify server1 = synch and server2 = async we then also need to
specify what happens if server1 is down. People might often specifyif (server1 == down) server2 = synch.
So now we have 3 configuration settings, one quite complex.
It's much easier to say you want to wait for N servers to respond, but
don't care which they are. One parameter, simple and flexible.
In both cases, we have to figure what to do if we can't get either
server to respond. In replication there is no such thing as "server
down" just a "server didn't reply in time X". So we need to define
timeouts.
So whatever we do, we need additional parameters to specify timeouts
(including wait-forever as an option) and action-on-timeout: commit or
rollback.
-- Simon Riggs www.2ndQuadrant.com