Tom Lane wrote:
> Huh? The pgpool is on the server, not on the client side.
Not necessarily. Having pgpool on the client side works just as well.
> There is one really bad consequence of the oversimplified failover
> design that Simon proposes, which is that clients might try to fail over
> for reasons other than a primary server failure.
Why is that? It's just fine for a client to (re)connect to another
server due to a fluky connection to the current server. I had something
pretty similar in mind for Postgres-R. (Except that we should definitely
allow to specify more than just a primary and a secondary server.)
> (Think network partition.)
Uh... well, yeah, of course the servers themselves need to exchange
their state and make sure they only accept clients if they are up and
running (as seen by the cluster). That's what the 'view' of a GCS is all
about. Or STONITH, for that matter.
> You really want any such behavior to be managed centrally,
> IMHO.
Controlling that client behavior reliably would involve using multiple
(at least N+1) connections to different servers, so you can control the
client even if N of the servers fail. That's certainly more complex than
what Simon proposed.
Speaking in terms of orthogonality, client failover is orthogonal to the
(cluster-wide) server state management. Which in turn is orthogonal to
how the nodes replicate data. (Modulo some side effects like nodes
lagging behind for async replication...)
Regards
Markus Wanner
--
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