Re: Issues with Quorum Commit
От | Heikki Linnakangas |
---|---|
Тема | Re: Issues with Quorum Commit |
Дата | |
Msg-id | 4CAC38F7.1020406@enterprisedb.com обсуждение исходный текст |
Ответ на | Re: Issues with Quorum Commit (Markus Wanner <markus@bluegap.ch>) |
Ответы |
Re: Issues with Quorum Commit
|
Список | 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 по дате отправления: