Re: Support for N synchronous standby servers - take 2

Hello,

The JSON method was used in the patch because it seemed to be the group
consensus.

Requirement:
- Grouping : Specify a list of node names with the required number of
ACK for the group. We could have priority or quorum group. Quorum treats
all the standby in same level and ACK from any k can be considered. In
priority behavior, ACK must be received from the specified k lowest priority
servers for a successful transaction.
- Group names to enable easier status reporting for group. The
topmost group may not be named. It will be assigned a default name. All the
sub groups are to be compulsorily named.
- Not more than 3 groups with 1 level of nesting expected

Behavior in submitted patch:
- The name of the top most group is named ‘Default Group”. All the
other standby_names or groups will have to be listed within this.
- When more than 1 connected standby has the same name then the
highest LSN among them is chosen. Example: 2 priority in (X,Y,Z). If there 2
nodes X connected, even though both X have returned ACK, the server will
wait for ACK from Y.
- There are no “potential” standbys. In quorum behavior, there are
no fixed standbys which are to be in sync, all members are equal. ACK from
any specified n nodes from a set is considered success.

Further:
- improvements to pg_stat_replication to give the node tree and
status?
- Manipulate/Edit conf setting using functions.
- Regression tests

Mini-lang:
[] - to specify prioirty
() - to specify quorum
Format - <name> : <count> [<list>]
Not specifying count defaults to 1.
Ex: s_s_names = '2(cluster1: 1(A,B), cluster2: 2[X,Y,Z], U)'

JSON
It would contain 2 main keys: "sync_info" and "groups"
The "sync_info" would consist of "quorum"/"priority" with the count and
"nodes"/"group" with the group name or node list.
The optional "groups" key would list out all the "group" mentioned within
"sync_info" along with the node list.
Ex: {
"sync_info":
{
"quorum":2,
"nodes":
[
{"quorum":1,"group":"cluster1"},
{"prioirty":2,"group": "cluster2"},
"U"
]
},
"groups":
{
"cluster1":["A","B"],
"cluster2":["X","Y","z"]
}
}

JSON and mini-language:
- JSON is more verbose
- You can define a group and use it multiple times in sync settings
but since no many levels or nesting is expected I am not sure how useful
this will be.
- Though JSON parser is inbuilt, additional code is required to check
for the required format of JSON. For mini-language, new parser will have to
be written.

Despite all, I feel the mini-language is better mainly for its brevity.
Also, it will not require additional GUC parser support (multi line).

-----
Beena Emerson

--
View this message in context: http://postgresql.nabble.com/Support-for-N-synchronous-standby-servers-take-2-tp5849384p5869286.html
Sent from the PostgreSQL - hackers mailing list archive at Nabble.com.