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

From Sawada Masahiko
Subject Re: Support for N synchronous standby servers - take 2
Date
Msg-id CAD21AoBMTq+a7+omtSiWPsM2Fwk=6rWdSz-roALd7a4QyG7b8g@mail.gmail.com
Whole thread Raw
In response to Re: Support for N synchronous standby servers - take 2  (Fujii Masao <masao.fujii@gmail.com>)
List pgsql-hackers
On Thu, Jul 2, 2015 at 9:31 PM, Fujii Masao <masao.fujii@gmail.com> wrote:
> On Thu, Jul 2, 2015 at 5:44 PM, Beena Emerson <memissemerson@gmail.com> wrote:
>> Hello,
>> There has been a lot of discussion. It has become a bit confusing.
>> I am summarizing my understanding of the discussion till now.
>> Kindly let me know if I missed anything important.
>>
>> Backward compatibility:
>> We have to provide support for the current format and behavior for
>> synchronous replication (The first running standby from list s_s_names)
>> In case the new format does not include GUC, then a special value to be
>> specified for s_s_names to indicate that.
>>
>> Priority and quorum:
>> Quorum treats all the standby with same priority while in priority behavior,
>> each one has a different priority and ACK must be received from the
>> specified k lowest priority servers.
>> I am not sure how combining both will work out.
>> Mostly we would like to have some standbys from each data center to be in
>> sync. Can it not be achieved by quorum only?
>
> So you're wondering if there is the use case where both quorum and priority are
> used together?
>
> For example, please imagine the case where you have two standby servers
> (say A and B) in local site, and one standby server (say C) in remote disaster
> recovery site. You want to set up sync replication so that the master waits for
> ACK from either A or B, i.e., the setting of 1(A, B). Also only when either A
> or B crashes, you want to make the master wait for ACK from either the
> remaining local standby or C. On the other hand, you don't want to use the
> setting like 1(A, B, C). Because in this setting, C can be sync standby when
> the master craches, and both A and B might be very behind of C. In this case,
> you need to promote the remote standby server C to new master,,, this is what
> you'd like to avoid.
>
> 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.

Regards,

--
Sawada Masahiko



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Repeated pg_upgrade buildfarm failures on binturon
Next
From: David Christensen
Date:
Subject: [PATCH] Add missing \ddp psql command