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.
> 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.
> 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.
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','...')
$$
...
> 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."
--------------
Hannu
