Re: Standby registration

Поиск
Список
Период
Сортировка
От Aidan Van Dyk
Тема Re: Standby registration
Дата
Msg-id AANLkTinpaDC17GL4a4Jfyo5OnJLzc0st285LCqv+ZQHK@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Standby registration  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
Список 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 по дате отправления:

Предыдущее
От: Hitoshi Harada
Дата:
Сообщение: Re: Documentation, window functions
Следующее
От: Robert Haas
Дата:
Сообщение: Re: Configuring synchronous replication