From: | Joshua Tolley <eggyknap(at)gmail(dot)com> |
---|---|
To: | Fujii Masao <masao(dot)fujii(at)gmail(dot)com> |
Cc: | 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-07-27 14:57:03 |
Message-ID: | 4c4ef3d3.0541730a.3195.352d@mx.google.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Jul 27, 2010 at 10:53:45PM +0900, Fujii Masao wrote:
> On Tue, Jul 27, 2010 at 10:12 PM, Joshua Tolley <eggyknap(at)gmail(dot)com> 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.
>
> What about checking the current WAL receive location of each standby by
> using pg_last_xlog_receive_location()? The standby which has the newest
> location should be failed over to.
That makes sense. Thanks.
> > This isn't different from Oracle, where it looks like
> > essentially the "quorum" value is always 1. Your scenario shows that all
> > replicas are not created equal, and that sometimes we'll be interested in WAL
> > getting committed on a specific subset of the available servers. If I had two
> > nearby replicas called X and Y, and one at a remote site called Z, for
> > instance, I'd set quorum to 2, but really I'd want to say "wait for server X
> > and Y before committing, but don't worry about Z".
> >
> > I have no idea how to set up our GUCs to encode a situation like that :)
>
> Yeah, quorum commit alone cannot cover that situation. I think that
> current approach (i.e., quorum commit plus replication mode per standby)
> would cover that. In your example, you can choose "recv", "fsync" or
> "replay" as replication_mode in X and Y, and choose "async" in Z.
Clearly I need to read through the GUCs and docs better. I'll try to keep
quiet until that's finished :)
--
Joshua Tolley / eggyknap
End Point Corporation
http://www.endpoint.com
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2010-07-27 16:07:00 | Re: [COMMITTERS] pgsql: Add restart_after_crash GUC. |
Previous Message | Fujii Masao | 2010-07-27 13:53:45 | Re: Synchronous replication |