Re: Core team statement on replication in PostgreSQL

Le vendredi 30 mai 2008, Tom Lane a écrit :
> No, I think it would be a useless expenditure of energy. Failover
> includes a lot of things that are not within our purview: switching
> IP addresses to point to the new server, some kind of STONITH solution
> to keep the original master from coming back to life, etc. Moreover
> there are already projects/products concerned with those issues.

Well, I forgot that there's in fact no active plan to put pgbouncer features
into core at the moment (I'm sure I've read something about this on the lists
though). If it was the case, the slave could proxy queries to the master, and
stop proxying but serve them if the master tells it it's dying.
This way, no need to switch IP addresses, the clients just connect as usual
and get results back and do not have to know whether the host they're qerying
against is a slave or a master. This level of smartness is into -core.

The STONITH part in case of known failure (fatal) does not seem that hard
either, as the master at fatal time could write somewhere it's now a slave
and use this at next startup time (recovery.conf?). If it can't even do that,
well, we're back to crash situation with no provided automatic failover
solution. Not handled failure cases obviously will continue to exist.

I'm not asking for "all cases managed in -core please", just for "some level
of effort" on the topic. Of course, I'm just the one asking questions and
trying to raise ideas, so I'm perfectly fine with your current answer
(useless expenditure of energy) even if somewhat disagreeing on the useless
part of it :)

As for the integrated pgbouncer daemon part, I'm thinking this would allow the
infamous part 3 of the proposal (read-only slave) to get pretty simple to
setup when ready: the slave knows who its master is, and as soon as an XID is
needed the transaction queries are forwarded/proxied to it. Thanks again
Florian !

> It might be useful to document where to find solutions to that problem,
> but we can't take it on as part of core Postgres.

Even the part when it makes sense (provided it does and I'm not completely off
tracks here)?

Regards,
--
dim