Re: Support for N synchronous standby servers - take 2

On Thu, Jul 2, 2015 at 5:44 PM, Beena Emerson <memissemerson(at)gmail(dot)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.

Regards,

--
Fujii Masao