On Fri, Jun 26, 2015 at 11:16 AM, Michael Paquier <
michael.paquier@gmail.com> wrote:
>
> On Thu, Jun 25, 2015 at 8:32 PM, Simon Riggs wrote:
> > Let's start with a complex, fully described use case then work out how to
> > specify what we want.
>
> Well, one of the most simple cases where quorum commit and this
> feature would be useful for is that, with 2 data centers:
> - on center 1, master A and standby B
> - on center 2, standby C and standby D
> With the current synchronous_standby_names, what we can do now is
> ensuring that one node has acknowledged the commit of master. For
> example synchronous_standby_names = 'B,C,D'. But you know that :)
> What this feature would allow use to do is for example being able to
> ensure that a node on the data center 2 has acknowledged the commit of
> master, meaning that even if data center 1 completely lost for a
> reason or another we have at least one node on center 2 that has lost
> no data at transaction commit.
>
I think the way to address this could be via SQL Syntax as that
will make users life easier.
Create Replication Setup Master A
Sync_Priority_Standby B Sync_Group_Any_Standby C,D
Sync_Group_Fixed_Standby 2,E,F,G
where
Sync_Priority_Standby - means same as current setting in
synchronous_standby_names
Sync_Group_Any_Standby - means if any one in the group has
acknowledged commit master can proceed
Sync_Group_Fixed_Standby - means fixed number
(that will be first parameter following this option) of standby's from this
group should commit before master can proceed.
The above syntax is just to explain the idea, but I think we can invent
better syntax if required. We can define these as options in syntax
like we do in some other syntaxes to avoid creating more keywords.
We need to ensure that all these option values needs to be persisted.
> Now, regarding the way to express that, we need to use a concept of
> node group for each element of synchronous_standby_names. A group
> contains a set of elements, each element being a group or a single
> node. And for each group we need to know three things when a commit
> needs to be acknowledged:
> - Does my group need to acknowledge the commit?
> - If yes, how many elements in my group need to acknowledge it?
> - Does the order of my elements matter?
>
I think with above kind of syntax we can address all these points
and even if something is remaining it is easily extendable.
> That's where the micro-language idea makes sense to use.
Micro-language idea is good, but I think if we can provide some
syntax or via SQL functions, then it can be convienient for users to
specify the replication topology.