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 по дате отправления: