Re: Automatic Client Failover

From: Simon Riggs <simon(at)2ndquadrant(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: josh(at)agliodbs(dot)com, Dimitri Fontaine <dfontaine(at)hi-media(dot)com>, "Jonah H(dot) Harris" <jonah(dot)harris(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Automatic Client Failover
Date: 2008-08-05 06:52:29
Message-ID: 1217919150.3934.639.camel@ebony.t-mobile.de.
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


On Mon, 2008-08-04 at 22:56 -0400, Tom Lane wrote:
> Josh Berkus <josh(at)agliodbs(dot)com> writes:
> > I think the proposal was for an extremely simple "works 75% of the time"
> > failover solution. While I can see the attraction of that, the
> > consequences of having failover *not* work are pretty severe.
>
> Exactly. The point of failover (or any other HA feature) is to get
> several nines worth of reliability. "It usually works" is simply
> not playing in the right league.

Why would you all presume that I haven't thought about the things you
mention? Where did I say "...and this would be the only feature required
for full and correct HA failover." The post is specifically about Client
Failover, as the title clearly states.

Your comments were illogical anyway, since if it was so bad a technique
then it would not work for pgpool either, since it is also a client. If
pgpool can do this, why can't another client? Why can't *all* clients?

With correctly configured other components the primary will shut down if
it is no longer the boss. The client will then be disconnected. If it
switches to its secondary connection, we can have an option to read
session_replication_role to ensure that this is set to origin. This
covers the case where the client has lost connection with primary,
though it is still up, yet can reach the standby which has not changed
state.

DB2, SQLServer and Oracle all provide this feature, BTW. We don't need
to follow, but we should do that consciously. I'm comfortable with us
deciding not to do it, if that is our considered judgement.

--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Richard Huxton 2008-08-05 07:30:28 Re: Reliability of CURRVAL in a RULE
Previous Message Heikki Linnakangas 2008-08-05 06:37:04 Re: Mini improvement: statement_cost_limit