Re: Standby registration - Mailing list pgsql-hackers

From Aidan Van Dyk
Subject Re: Standby registration
Date
Msg-id AANLkTinpaDC17GL4a4Jfyo5OnJLzc0st285LCqv+ZQHK@mail.gmail.com
Whole thread Raw
In response to Re: Standby registration  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
List pgsql-hackers
On Wed, Sep 22, 2010 at 10:19 AM, Heikki Linnakangas
<heikki.linnakangas@enterprisedb.com> wrote:

>>> Should we allow multiple standbys with the same name to connect to
>>> the master?
>>
>> No.  The point of naming them is to uniquely identify them.
>
> Hmm, that situation can arise if there's a network glitch which leads the
> standby to disconnect, but the master still considers the connection as
> alive. When the standby reconnects, the master will see two simultaneous
> connections from the same standby. In that scenario, you clearly want to
> disconnect the old connetion in favor of the new one. Is there a scenario
> where you'd want to keep the old connection instead and refuse the new one?

$Bob turns restores a backup image of the slave to test some new stuff
in a dev environment, and it automatically connects.  Thanks to IPv4
and the NAT often necessary, they both *appear* to the real master as
the same IP address, even though, in the remote campus, they are on to
seperate "networks", all NATed through the 1 IP address...

Now, that's not (likely) to happen in a "sync rep" situation, but for
an async setup, and standby registration automatically being able to
keep WAL, etc, satellite offices with occasional network hickups (and
developper above mentioned developer VMs) make registration (and
centralized monitoring of the slaves) very interesting...

a.


pgsql-hackers by date:

Previous
From: Hitoshi Harada
Date:
Subject: Re: Documentation, window functions
Next
From: Robert Haas
Date:
Subject: Re: Configuring synchronous replication