Re: Support for N synchronous standby servers - take 2 - Mailing list pgsql-hackers

From Masahiko Sawada
Subject Re: Support for N synchronous standby servers - take 2
Date
Msg-id CAD21AoDGFmabpZHG1SwkoEVRwA7QOE7MeyviUsP10e8AmU2CwQ@mail.gmail.com
Whole thread Raw
In response to Re: Support for N synchronous standby servers - take 2  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Support for N synchronous standby servers - take 2
List pgsql-hackers
On Sat, Oct 10, 2015 at 4:35 AM, Robert Haas <robertmhaas@gmail.com> wrote:
> On Fri, Oct 9, 2015 at 12:00 AM, Amit Kapila <amit.kapila16@gmail.com> wrote:
>> Sounds like both the approaches have some pros and cons, also there are
>> some people who prefer mini-language and others who prefer JSON.  I think
>> one thing that might help, is to check how other databases support this
>> feature or somewhat similar to this feature (mainly with respect to User
>> Interface), as that can help us in knowing what users are already familiar
>> with.
>
> +1!
>

For example, MySQL 5.7 has similar feature, but it doesn't support
quorum commit, and is simpler than postgresql attempting feature.
There is one configuration parameter in MySQL 5.7 which indicates the
number of sync replication node.
The primary server commit when the primary server receives the
specified number of ACK from standby server regardless name of standby
server.

And IIRC, Oracle database also doesn't support the quorum commit as well.
The settings standby server sync or async is specified per standby
server in configuration parameter in primary node.

I think that the use of JSON format approach and dedicated language
approach are different.
The dedicated language format approach would be useful for simple
configuration such as the one nesting, not using group.
This will allow us to configure replication more simpler and easier.
In contrast, The JSON format approach would be useful for complex configuration.

I thought that this feature for postgresql should be simple at first
implementation.
It would be good even if there are some restriction such as the
nesting level, the group setting.
The another new approach that I came up with is,
* Add new parameter synchronous_replication_method (say s_r_method)
which can have two names: 'priority', 'quorum'
* If s_r_method = 'priority', the value of s_s_names (e.g. 'n1,n2,n3')
is handled using priority. It's same as '[n1,n2,n3]' in dedicated
laguage.
* If s_r_method = 'quorum', the value of s_s_names is handled using
quorum commit, It's same as '(n1,n2,n3)' in dedicated language.
* Setting of synchronous_standby_names is same as today. That is, the
storing the nesting value is not supported.
* If we want to support more complex syntax like what we are
discussing, we can add the new value to s_r_method, for example
'complex', 'json'.

Though?

Regards,

--
Masahiko Sawada



pgsql-hackers by date:

Previous
From: Christopher Browne
Date:
Subject: Re: Database schema diff
Next
From: Josh Berkus
Date:
Subject: Re: Support for N synchronous standby servers - take 2