| From: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
|---|---|
| To: | Joshua Tolley <eggyknap(at)gmail(dot)com> |
| Cc: | Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, Yeb Havinga <yebhavinga(at)gmail(dot)com>, 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-08-01 06:11:25 |
| Message-ID: | 4C55100D.5040902@enterprisedb.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 27/07/10 16:12, Joshua Tolley wrote:
> My concern is that in a quorum system, if the quorum number is less than the
> total number of replicas, there's no way to know *which* replicas composed the
> quorum for any given transaction, so we can't know which servers to fail to if
> the master dies.
In fact, it's possible for one standby to sync up to X, then disconnect
and reconnect, and have the master count it second time in the quorum.
Especially if the master doesn't notice that the standby disconnected,
e.g a network problem.
I don't think any of this quorum stuff makes much sense without
explicitly registering standbys in the master.
That would also solve the fuzziness with wal_keep_segments - if the
master knew what standbys exist, it could keep track of how far each
standby has received WAL, and keep just enough WAL for each standby to
catch up.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Heikki Linnakangas | 2010-08-01 09:08:17 | Re: documentation for committing with git |
| Previous Message | Boxuan Zhai | 2010-08-01 05:03:15 | Re: merge command - GSoC progress |