Re: Automatic Client Failover - Mailing list pgsql-hackers

On Tue, 2008-08-05 at 11:50 +0300, Hannu Krosing wrote:
> On Tue, 2008-08-05 at 07:52 +0100, Simon Riggs wrote:
> > On Mon, 2008-08-04 at 22:56 -0400, Tom Lane wrote:
> > > Josh Berkus <josh@agliodbs.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.
> 
> I guess having the title "Automatic Client Failover" suggest to most
> readers, that you are trying to solve the client side separately from
> server. 

Yes, that's right: separately. Why would anybody presume I meant "and by
the way you can turn off all other HA measures not mentioned here"? Not
mentioning a topic means no change or no impact in that area, at least
on all other hackers threads.

> > 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?
> 
> IIRC pgpool was itself a poor-mans replication solution, so it _is_ the
> point of doing failover.

Agreed. 

> > 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. 
> 
> Probably this should not be an option, but a must.

Perhaps, but some people doing read only queries don't really care which
one they are connected to. 

> maybe session_replication_role should be a DBA-defined function, so that
> the same client failover mechanism can be applied to different
> replication solutions, both server-built-in and external.
> 
> create function session_replication_role() 
> returns enum('master','ro-slave','please-wait-coming-online','...')
> $$
> ...

Maybe, trouble is "please wait coming online" is the message a Hot
Standby would give also. Happy to list out all the states so we can make
this work for everyone.

> > 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.
> 
> The main argument seemed to be, that it can't be "Automatic Client-ONLY
> Failover."

No argument. Never was. It can't be. 

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