Re: Issues with Quorum Commit - Mailing list pgsql-hackers

From Heikki Linnakangas
Subject Re: Issues with Quorum Commit
Date
Msg-id 4CAC38F7.1020406@enterprisedb.com
Whole thread Raw
In response to Re: Issues with Quorum Commit  (Markus Wanner <markus@bluegap.ch>)
Responses Re: Issues with Quorum Commit
List pgsql-hackers
On 06.10.2010 11:39, Markus Wanner wrote:
> On 10/06/2010 10:17 AM, Heikki Linnakangas wrote:
>> On 06.10.2010 11:09, Fujii Masao wrote:
>>> Hmm.. but we can increase availability without any data loss by using
>>> synchronous
>>> replication. Many people have already been using synchronous
>>> replication softwares
>>> such as DRBD for that purpose.
>>
>> Sure, but it's not the synchronous aspect that increases availability.
>> It's the replication aspect, and we already have that.
>
> ..the *asynchronous* replication aspect, yes.
>
> The drdb.conf man page [1] describes parameters of DRDB. It's worth
> noting that even in "Protocol C" (synchronous mode), they sport a
> timeout of only 6 seconds (by default).

Wow, that is really short. Are you sure? I have no first hand experience 
with DRBD, and reading that man page, I get the impression that the 
timeout us just for deciding that the TCP connection is dead. There is 
also the ko-count parameter, which defaults to zero. I would guess that 
ko-count=0 is "wait forever", while ko-count=1 is what you described, 
but I'm not sure.

It's not hard to imagine the master failing in a way that first causes 
the connection to standby to drop, and the disk failing 6 seconds later. 
A fire that destroys the network cable first and then spreads to the 
disk array for example.

> [1]: drdb.conf man page:
> http://www.drbd.org/users-guide/re-drbdconf.html

--   Heikki Linnakangas  EnterpriseDB   http://www.enterprisedb.com


pgsql-hackers by date:

Previous
From: Fujii Masao
Date:
Subject: Re: Issues with Quorum Commit
Next
From: Heikki Linnakangas
Date:
Subject: Re: Issues with Quorum Commit