From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Thom Brown <thom(at)linux(dot)com> |
Cc: | Dimitri Fontaine <dfontaine(at)hi-media(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, David Fetter <david(at)fetter(dot)org>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Configuring synchronous replication |
Date: | 2010-09-20 22:24:35 |
Message-ID: | AANLkTikMvh8KNXyUCU747T9yuO=FU=hmA323puQZWNHB@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-committers pgsql-hackers |
On Mon, Sep 20, 2010 at 5:42 PM, Thom Brown <thom(at)linux(dot)com> wrote:
> On 20 September 2010 22:14, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>> Well, if you need to talk to "all the other standbys" and see who has
>> the furtherst-advanced xlog pointer, it seems like you have to have a
>> list somewhere of who they all are.
>
> When they connect to the master to get the stream, don't they in
> effect, already talk to the primary with the XLogRecPtr being relayed?
> Can the connection IP, port, XLogRecPtr and request time of the
> standby be stored from this communication to track the states of each
> standby? They would in effect be registering upon WAL stream
> request... and no doubt this is a horrifically naive view of how it
> works.
Sure, but the point is that we can want DISCONNECTED slaves to affect
master behavior in a variety of ways (master retains WAL for when they
reconnect, master waits for them to connect before acking commits,
master shuts down if they're not there, master tries to stream WAL
backwards from them before entering normal running). I just work
here, but it seems to me that such things will be easier if the master
has an explicit notion of what's out there. Can we make it all work
without that? Possibly, but I think it will be harder to understand.
With standby registration, you can DECLARE the behavior you want. You
can tell the master "replicate synchronously to Bob". And that's it.
Without standby registration, what's being proposed is basically that
you can tell the master "replicate synchronously to one server" and
you can tell Bob "you are a server to which the master can replicate
synchronously" and you can tell the other servers "you are not a
server to which Bob can replicate synchronously". That works, but to
me it seems less straightforward.
And that's actually a relatively simple example. Suppose you want to
tell the master "keep enough WAL for Bob to catch up when he
reconnects, but if he gets more than 1GB behind, forget about him".
I'm sure someone can devise a way of making that work without standby
registration, too, but I'm not too sure off the top of my head what it
will be. With standby registration, you can just write something like
this in standbys.conf (syntax invented):
[bob]
wal_keep_segments=64
I feel like that's really nice and simple.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company
From | Date | Subject | |
---|---|---|---|
Next Message | Simon Riggs | 2010-09-21 06:36:12 | Re: Configuring synchronous replication |
Previous Message | Thom Brown | 2010-09-20 21:42:35 | Re: Configuring synchronous replication |
From | Date | Subject | |
---|---|---|---|
Next Message | fazool mein | 2010-09-21 00:48:40 | Shutting down server from a backend process, e.g. walrceiver |
Previous Message | Kevin Grittner | 2010-09-20 21:49:55 | Re: Serializable snapshot isolation error logging |