> Huh? The problem case is that the primary server goes down, which would
> certainly mean that a pgbouncer instance on the same machine goes with
> it. So it seems to me that integrating pgbouncer is 100% backwards.
With all due respect, it seems to me you're missing an important piece of the
scheme here: I certainly failed to explain correctly. Of course, I'm not sure
(by and large) that detailing what I have in mind will answer your concerns,
but still...
What I have in mind is having the pgbouncer listening process both at master
and slave sites. So your clients can already connect to slave for normal
operations, and the listener process simply connects them to the master,
transparently.
When we later provider RO slave, some queries could be processed locally
instead of getting sent to the master.
The point being that the client does not have to care itself whether it's
connecting to a master or a slave, -core knows what it can handle for the
client and handles it (proxying the connection).
Now, that does not solve the client side automatic failover per-se, it's
another way to think about it:
- both master & slave accept connection in any mode
- master & slave are able to "speak" to each other (life link)
- when master knows it's crashing (elog(FATAL)), it can say so to the slave
- when said so, slave can switch to master
It obviously only catches some errors on master, the ones we're able to log
about. So it does nothing on its own for allowing HA in case of master crash.
But...
> Failover that actually works is not something we can provide with
> trivial changes to Postgres. It's really a major project in its
> own right: you need heartbeat detection, STONITH capability,
> IP address redirection, etc. I think we should be recommending
> external failover-management project(s) instead of offering a
> half-baked home-grown solution. Searching freshmeat for "failover"
> finds plenty of potential candidates, but not having used any of
> them I'm not sure which are worth closer investigation.
We have worked here with heartbeat, and automating failover is hard. Not for
technical reasons only, also because:
- current PostgreSQL offers no sync replication, switching means trading or
losing the D in ACID,
- you do not want to lose any commited data.
If 8.4 resolve this, failover implementation will be a lot easier.
What I see my proposal fit is the ability to handle a part of the smartness
in -core directly, so the hard part of the STONITH/failover/switchback could
be implemented in cooperation with -core, not playing tricks against it.
For example, switching back when master gets back online would only means for
the master to tell the slave to now redirect the queries to him as soon as
it's ready --- which still is the hard part, sync back data.
Having clients able to blindly connect to master or any slave and having the
current cluster topology smartness into -core would certainly help here, even
if not fullfilling all HA goals.
Of course, in the case of master hard crash, we still have to get sure it
won't restart on its own, and we have to have an external way to get a chosen
slave become the master.
I'm even envisioning than -core could help STONITH projects with having sth
like the recovery.conf file for the master to restart in not-up-to-date slave
mode. Whether we implement resyncing to the new master in -core or from
external scripts is another concern, but certainly -core could help here
(even if not in 8.4, of course).
I'm still thinking that this proposal has a place in the scheme of an
integrated HA solution and offers interresting bits.
Regards,
--
dim
No comments:
Post a Comment