| From: | Markus Wanner <markus(at)bluegap(dot)ch> |
|---|---|
| To: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
| Cc: | Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, Josh Berkus <josh(at)agliodbs(dot)com>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Issues with Quorum Commit |
| Date: | 2010-10-06 08:39:21 |
| Message-ID: | 4CAC35B9.1030608@bluegap.ch |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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).
After that, the primary node proceeds without any kind of guarantee
(which can be thought of as switching to async replication). Just as
Simon proposes for Postgres as well.
Maybe that really is enough for now. Everybody that needs stricter
durability guarantees needs to wait for Postgres-R ;-)
Regards
Markus Wanner
[1]: drdb.conf man page:
http://www.drbd.org/users-guide/re-drbdconf.html
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Fujii Masao | 2010-10-06 08:49:01 | Re: Issues with Quorum Commit |
| Previous Message | Dean Rasheed | 2010-10-06 08:20:38 | Re: WIP: Triggers on VIEWs |