From: | Hannu Krosing <hannu(at)krosing(dot)net> |
---|---|
To: | Simon Riggs <simon(at)2ndquadrant(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, 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 08:50:49 |
Message-ID: | 1217926249.12727.7.camel@huvostro |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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(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.
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
From | Date | Subject | |
---|---|---|---|
Next Message | Martin Pihlak | 2008-08-05 08:53:30 | plan invalidation vs stored procedures |
Previous Message | Magnus Hagander | 2008-08-05 08:36:24 | Re: CommitFest July Over |