Re: Synchronization levels in SR

Simon Riggs <simon(at)2ndQuadrant(dot)com> writes:
> Seems strange. If you have 2 standbys and you say you would like node1
> to be the preferred candidate, then you load it so heavily that a remote
> server with by-definition much larger network delay responds first, then
> I say your preference was wrong.

There's a communication mismatch here I think. The problem with the
dynamic aspect of the system is that the admin wants to plan ahead and
choose in advance the failover server.

Other than that I much prefer the automatic and dynamic quorum idea.

> If you, Jan and Yeb wish to completely exclude standbys from being part
> of any quorum, then I guess we need to have per-standby settings to
> allow that to be defined. I'm in favour of giving people options. That
> needn't be a mandatory per-standby setting, just a non-default option,
> so that we can reduce the complexity of configuration for common
> cases.

+1

> Maximum Performance => quorum = 0
> Maximum Availability => quorum = 1, timeout_action = commit
> Maximum Protection => quorum = 1, timeout_action = shutdown

+1

Being able to say that a given server has not been granted to
participate into the vote allowing to reach the global durability quorum
will allow for choosing the failover candidates.

Now you're able to have this reporting server and know for sure that
your sync replicated transactions are not waiting for it.

To summarize, the current "per-transaction approach" would be :

- transaction level replication synchronous behaviour
- proxy/cascading in core
- quorum setup for deciding any commit is safe
- any server can be excluded from the sync quorum
- timeout can still raises exception or ignore (commit)?

This last point seems to need some more discussion, or I didn't
understand well the current positions and proposals.

Regards,
--
dim