Re: Support for N synchronous standby servers - take 2

On 07/06/2015 10:03 AM, Sawada Masahiko wrote:
>> > The setting that you need is 1(1[A, C], 1[B, C]) in Michael's proposed grammer.
>> >
> If we set the remote disaster recovery site up as synch replica, we
> would get some big latencies even though we use quorum commit.
> So I think this case Fujii-san suggested is a good configuration, and
> many users would want to use it.
> I tend to agree with combine quorum and prioritization into one GUC
> parameter while keeping backward compatibility.

OK, so here's the arguments pro-JSON and anti-JSON:

pro-JSON:

* standard syntax which is recognizable to sysadmins and devops.
* can use JSON/JSONB functions with ALTER SYSTEM SET to easily make
additions/deletions from the synch rep config.
* can add group labels (see below)

anti-JSON:

* more verbose
* syntax is not backwards-compatible, we'd need a switch
* people will want to use line breaks, which we can't support

Re: group labels: I see a lot of value in being able to add names to
quorum groups.  Think about how this will be represented in system
views; it will be difficult to show sync status of any quorum group in
any meaningful way if the group has no label, and any system-assigned
label would change unpredictably from the user's perspective.

To give a JSON example, let's take the case of needing to sync to two of
the servers in either London or NC:

'{ "remotes" : { "london_servers" : { "quorum" : 2, "servers" : [
"london1", "london2", "london3" ] }, "nc_servers" : { "quorum" : 1,
"servers" [ "nc1", "nc2" ] } }'

This says: as the "remotes" group, synch with a quorum of 2 servers in
london and a quorum of 1 server in NC.  This assumes for
backwards-compatibility reasons that we support a priority list of
groups of quorums, and not some other combination (see below for more on
this).

The advantage of having these labels is that it becomes easy to
represent statuses for them:

sync_group    state        definition
remotes        waiting        { "london_servers" : { "quorum" ...
london_servers    synced        { "quorum" : 2, "servers" : ...
nc_servers    waiting        { "quorum" : 1, "servers" [  ...

Without labels, we force the DBA to track groups by raw definitions,
which would be difficult.  Also, there's the question of what we do on
reload with any statuses of synch groups which are currently in-process,
if we don't have a stable key with which to identify groups.

The other grammar issue has to do with the nesting nature of quorums and
priorities.  A theoretical user could want:

* a priority list of quorum groups
* a quorum group of priority lists
* a quorum group of quorum groups
* a priority list of quorum groups of quorum groups
* a quorum group of quorum groups of priority lists
... etc.

I don't really see any possible end to the possible permutations, which
is why it would be good to establish some real use cases from now in
order to figure out what we really want to support.  Absent that, my
inclination is that we should implement the simplest possible thing
(i.e. no nesting) for 9.5.

-- 
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com