Re: Proposal: Implement failover on libpq connect level. - Mailing list pgsql-hackers

From Amit Kapila
Subject Re: Proposal: Implement failover on libpq connect level.
Date
Msg-id CAA4eK1LvugdRvXbEw_o7OSddVBRH8LD7s8qrwO3Z3gUfcpuG0Q@mail.gmail.com
Whole thread Raw
In response to Re: Proposal: Implement failover on libpq connect level.  (Victor Wagner <vitus@wagner.pp.ru>)
Responses Re: Proposal: Implement failover on libpq connect level.  (Robert Haas <robertmhaas@gmail.com>)
List 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

pgsql-hackers by date:

Previous
From: Tomas Vondra
Date:
Subject: Re: PATCH: use foreign keys to improve join estimates v1
Next
From: Tomas Vondra
Date:
Subject: Re: DBT-3 with SF=20 got failed