Re: Proposal: Implement failover on libpq connect level.
Amit Kapila <amit.kapila16@gmail.com>
From: Amit Kapila <amit.kapila16@gmail.com>
To: Victor Wagner <vitus@wagner.pp.ru>
Cc: pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2015-08-20T03:06:31Z
Lists: pgsql-hackers
On Wed, Aug 19, 2015 at 1:23 PM, Victor Wagner <vitus@wagner.pp.ru> wrote: > > On 2015.08.19 at 12:55:15 +0530, Amit Kapila wrote: > > > > I think that failover procedure should begin before first connection is > > > ever established. > > > > > > > As far as I understand, failover gets initiated once the master server goes > > down or is not accessible due to some reason, so for such cases if you > > have the connection to both the servers then it might not work. > > Master server might go down when client is not started yet. > And when client starts up, it has to find out which server to connect > now. > Always try with the first server specified in connection string and if that is not available try with second and so on. I think for the case of failover, the design shouldn't be much complicated and it is a standard thing provided by most of the client-side drivers in other databases. Considering what currently PostgreSQL offers in terms of high-availability functionality, for load-balancing, we need to be careful of many more things like redirecting read-queries to standby's, write statements should be executed via connection to master. With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com
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