Re: Proposal: Implement failover on libpq connect level.
Albe Laurenz <laurenz.albe@wien.gv.at>
From: Albe Laurenz <laurenz.albe@wien.gv.at>
To: "'Victor Wagner *EXTERN*'" <vitus@wagner.pp.ru>,
"pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2015-08-18T08:32:28Z
Lists: pgsql-hackers
Victor Wagner wrote: > Rationale > ========= > > Since introduction of the WAL-based replication into the PostgreSQL, it is > possible to create high-availability and load-balancing clusters. > > However, there is no support for failover in the client libraries. So, only > way to provide transparent for client application failover is IP address > migration. This approach has some limitation, i.e. it requires that > master and backup servers reside in the same subnet or may not be > feasible for other reasons. > > Commercial RDBMS, such as Oracle, employ more flexible approach. They > allow to specify multiple servers in the connect string, so if primary > server is not available, client library tries to connect to other ones. > > This approach allows to use geographically distributed failover clusters > and also is a cheap way to implement load-balancing (which is not > possible with IP address migration). I wonder how useful this is at the present time. If the primary goes down and the client gets connected to the standby, it would have read-only access there. Most applications wouldn't cope well with that. Once we have multi-master replication that can be used for fail-over, the picture will change. Then a feature like that would be very useful indeed. > "host=main-server host=standby1 host=standby2 port=5432 dbname=database" It seems a bit arbitrary to require that all servers use the same port. Maybe parameters like host2, port2, host3, port3 etc. might be better. Yours, Laurenz Albe
Commits
-
libpq: Add target_session_attrs parameter.
- 721f7bd3cbcc 10.0 landed
-
Remove superuser checks in pgstattuple
- fd321a1dfd64 10.0 cited
-
Fix unwanted flushing of libpq's input buffer when socket EOF is seen.
- c405918858c0 9.6.0 cited