Re: Proposal: Implement failover on libpq connect level.
От | Alvaro Herrera |
---|---|
Тема | Re: Proposal: Implement failover on libpq connect level. |
Дата | |
Msg-id | 20150901175010.GP2912@alvherre.pgsql обсуждение исходный текст |
Ответ на | Re: Proposal: Implement failover on libpq connect level. (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: Proposal: Implement failover on libpq connect level.
Re: Proposal: Implement failover on libpq connect level. |
Список | pgsql-hackers |
Robert Haas wrote: > On Wed, Aug 19, 2015 at 9:41 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > > That sort-of ties into what seems to me the main objection to this > > proposal, namely that there is already a way to do this sort of thing: > > DNS-based load balancing. All the clients think they connect to > > db.mycompany.com, but which server they actually get is determined by > > what IP address the DNS server tells them to use. > > But that kinda sucks. I mean, suppose I have three servers, A, B, and > C. I point db.mycompany.com to A, which is the master; then A dies. > Under your proposal, whatever script I use to control failover now has > to change the DNS records to repoint db.mycompany.com to B, my new, > and newly-promoted, new master. It's quite possible that some > machines on the network, or some processes, will have the old IP > address cached, and it may be several minutes before those caches time > out. In the meantime, I'm down: even if I bounce the application > servers, they may just try to reconnect to A. The solution to this part seems to be to lower the TTL, which seems easy enough. -- Álvaro Herrera http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
В списке pgsql-hackers по дате отправления: