> 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.com
PostgreSQL Training, Services and Support
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
No comments:
Post a Comment