Re: [HACKERS] Quorum commit for multiple synchronous replication. - Mailing list pgsql-hackers

At Tue, 25 Apr 2017 01:13:12 +0900, Fujii Masao <masao.fujii@gmail.com> wrote in
<CAHGQGwFZHQXfu04d+FwOOgFzvXdRoRvPrU6jFQJRF2BPLkADsQ@mail.gmail.com>
> On Mon, Apr 24, 2017 at 2:55 PM, Masahiko Sawada <sawada.mshk@gmail.com> wrote:
> > On Thu, Apr 20, 2017 at 9:31 AM, Kyotaro HORIGUCHI
> > <horiguchi.kyotaro@lab.ntt.co.jp> wrote:
> >> Ok, I got the point.
> >>
> >> At Wed, 19 Apr 2017 17:39:01 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>
wrotein <20170419.173901.16598616.horiguchi.kyotaro@lab.ntt.co.jp>
 
> >>> > >> |    <para>
> >>> > >> |     Quorum-based synchronous replication is basically more
> >>> > >> |     efficient than priority-based one when you specify multiple
> >>> > >> |     standbys in <varname>synchronous_standby_names</> and want
> >>> > >> |     to synchronously replicate transactions to two or more of
> >>> > >> |     them.
> >>
> >> "Some" means "not all".
> >>
> >>> > >> |     In the priority-based case, the replication master
> >>> > >> |     must wait for a reply from the slowest standby in the
> >>> > >> |     required number of standbys in priority order, which may
> >>> > >> |     slower than the rest.
> >>
> >>
> >> Quorum-based synchronous replication is expected to be more
> >> efficient than priority-based one when your master doesn't need
> >> to be in sync with all of the nominated standbys by
> >> <varname>synchronous_standby_names</>.
> 
> This description may be invalid in the case where the requested number
> of sync standbys is smaller than the number of "nominated" standbys by
> s_s_names. For example, please imagine the case where there are five
> standbys nominated by s_s_name, the requested number of sync standbys
> is 2, and only two sync standbys are running. In this case, the master
> needs to wait for those two standbys whatever the sync rep method is.

Hmm. The 'nominated' standbys are standbys that their names are
listed in the s_s_names. "your master doesn't need to be in sync
with all of" means "number of sync standbys is smaller than the
number of.." So it seems to be the same... for me.

> I think that we should rewrite that to something like "quorum-based
> synchronous replication is more effecient when the requested number
> of synchronous standbys is smaller than the number of potential
> synchronous standbys running".

Against this phrase, "potential sync standbys" is "nominated
standbys".


> >  While quorum-based
> >> replication master waits only for a specified number of fastest
> >> standbys, priority-based replicatoin master must wait for
> >> standbys at the top of the list, which may be slower than the
> >> rest.
> 
> > This description looks good to me. I've updated the patch based on
> > this description and attached it.
> 
> But I still think that the original description that I used in my patch is
> better than this....

I'm not good at composition, so I cannot insist on my
proposal. For the convenience of others, here is the proposal
from Fujii-san.

+     A quorum-based synchronous replication is basically more efficient than
+     a priority-based one when you specify multiple standbys in
+     <varname>synchronous_standby_names</> and want to replicate
+     the transactions to some of them synchronously. In this case,
+     the transactions in a priority-based synchronous replication must wait for
+     reply from the slowest standby in synchronous standbys chosen based on
+     their priorities, and which may increase the transaction latencies.
+     On the other hand, using a quorum-based synchronous replication may
+     improve those latencies because it makes the transactions wait only for
+     replies from the requested number of faster standbys in all the listed
+     standbys, i.e., such slow standby doesn't block the transactions.


-- 
Kyotaro Horiguchi
NTT Open Source Software Center