Skip site navigation (1) Skip section navigation (2)

Re: Synchronous replication

From: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>
To: Yeb Havinga <yebhavinga(at)gmail(dot)com>
Cc: Aidan Van Dyk <aidan(at)highrise(dot)ca>, Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Synchronous replication
Date: 2010-07-26 06:56:40
Message-ID: AANLkTikUxoA+OTq1TAq-MaGc53iZc4jxTbPOzdSK2DO1@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On Thu, Jul 22, 2010 at 5:37 PM, Yeb Havinga <yebhavinga(at)gmail(dot)com> wrote:
> Fujii Masao wrote:
>>
>> How should the synchronous replication behave when the number of connected
>> standby servers is less than quorum?
>>
>> 1. Ignore quorum. The current patch adopts this. If the ACKs from all
>>   connected standbys have arrived, transaction commit is successful
>>   even if the number of standbys is less than quorum. If there is no
>>   connected standby, transaction commit always is successful without
>>   regard to quorum.
>>
>> 2. Observe quorum. Aidan wants this. Until the number of connected
>>   standbys has become more than or equal to quorum, transaction commit
>>   waits.
>>
>> Which is the right behavior of quorum commit? Or we should add new
>> parameter specifying the behavior of quorum commit?
>>
>
> Initially I also expected the quorum to behave like described by
> Aidan/option 2.

OK. But some people (including me) would like to prevent the master
from halting when the standby fails, so I think that 1. also should
be supported. So I'm inclined to add new parameter specifying the
behavior of quorum commit when the number of synchronous standbys
becomes less than quorum.

> Also, IMHO the name "quorom" is a bit short, like having
> "maximum" but not saying a max_something.
>
> quorum_min_sync_standbys
> quorum_max_sync_standbys

What about quorum_standbys?

> The question remains what are the sync standbys? Does it mean not-async?

It's the standby which sets replication_mode to "recv", "fsync", or "replay".

> Intuitively by looking at the enumeration of replication_mode I'd think that
> the sync standbys are all standby's that operate in a not async mode. That
> would be clearer with a boolean sync (or not) and for sync standbys the
> replication_mode specified.

You mean that something like synchronous_replication as the recovery.conf
parameter should be added in addition to replication_mode? Since increasing
the number of similar parameters would confuse users, I don't like do that.

Regards,

-- 
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center

In response to

Responses

pgsql-hackers by date

Next:From: KaiGai KoheiDate: 2010-07-26 07:02:17
Subject: Re: security label support, part.2
Previous:From: Markus WannerDate: 2010-07-26 06:48:03
Subject: Re: bg worker: overview

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group