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 | CAD21AoCau1kE=oaPoZ=pZ0iPhjgiwAxErPcum5xmOdrO0N0E1w@mail.gmail.com Whole thread Raw |
In response to | Re: Support for N synchronous standby servers - take 2 (Josh Berkus <josh@agliodbs.com>) |
Responses |
Re: Support for N synchronous standby servers - take 2
|
List | pgsql-hackers |
On Wed, Oct 14, 2015 at 3:16 AM, Josh Berkus <josh@agliodbs.com> wrote: > On 10/13/2015 11:02 AM, Masahiko Sawada wrote: >> 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. > > Well, the first question is: can you implement both of these things for > 9.6, realistically? If you can implement them, then we can argue about > configuration format later. It's even possible that the nature of your > implementation will enforce a particular syntax. > Hi, Attached patch is a rough patch which supports multi sync replication by another approach I sent before. The new GUC parameters are: * synchronous_standby_num, which specifies the number of standby servers using sync rep. (default is 0) * synchronous_replication_method, which specifies replication method; priority or quorum. (default is priority) The behaviour of 'priority' and 'quorum' are same as what we've been discussing. But I write overview of these here again here. [Priority Method] The standby server has each different priority, and the active standby servers having the top N priroity are become sync standby server. If synchronous_standby_names = '*', the all active standby server would be sync standby server. If you want to set up standby like 9.5 or before, you can set synchronous_standby_num = 1. [Quorum Method] The standby servers have same priority 1, and the all the active standby servers will be sync standby server. The master server have to wait for ACK from N sync standby servers at least before COMMIT. If synchronous_standby_names = '*', the all active standby server would be sync standby server. [Use case] This patch can handle the main use case where Michael said; There are 2 data centers, first one has the master and a sync standby, and second one has a set of standbys. We need to be sure that the standby in DC1 acknowledges all the time, and we would only need to wait for one or more of them in DC2. In order to handle this use case, you set these standbys and GUC parameter as follows. * synchronous_standby_names = 'DC1, DC2' * synchronous_standby_num = 2 * synchronous_replication_method = quorum * The name of standby server in DC1 is 'DC1', and the names of two standby servers in DC2 are 'DC2'. [Extensible] By setting same application_name to different standbys, we can set up sync replication with grouping standbys. If we want to set up replication more complexly and flexibility, we could add new syntax for s_s_names (e.g., JSON format or dedicated language), and increase kind of values of synhcronous_replication_method, e.g. s_r_method = 'complex', And this patch doesn't need new parser for GUC parameter. Regards, -- Masahiko Sawada
Attachment
pgsql-hackers by date: