Re: Proposal: Implement failover on libpq connect level.
Jaime Casanova <jaime.casanova@2ndquadrant.com>
From: Jaime Casanova <jaime.casanova@2ndquadrant.com>
To: Victor Wagner <vitus@wagner.pp.ru>
Cc: pgsql-hackers@postgresql.org
Date: 2015-08-18T16:53:28Z
Lists: pgsql-hackers
On 17 August 2015 at 23:18, Victor Wagner <vitus@wagner.pp.ru> 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. > This is not completely true, you can always use something like pgbouncer or other middleware to change the server to which clients connect. you still need to solve the fact that you will have a read-only server at the other side. something like repmgr + pgbouncer will work fine. i agree that once/if we ever have multimaster included then this could be a good idea -- Jaime Casanova www.2ndQuadrant.com Professional PostgreSQL: Soporte 24x7 y capacitación
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