Re: Core team statement on replication in PostgreSQL - Mailing list pgsql-hackers

From Dimitri Fontaine
Subject Re: Core team statement on replication in PostgreSQL
Date
Msg-id 200805301029.33274.dfontaine@hi-media.com
Whole thread Raw
In response to Re: Core team statement on replication in PostgreSQL  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Core team statement on replication in PostgreSQL  (Dimitri Fontaine <dfontaine@hi-media.com>)
List pgsql-hackers
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

pgsql-hackers by date:

Previous
From: Simon Riggs
Date:
Subject: Re: Avoiding second heap scan in VACUUM
Next
From: Andreas 'ads' Scherbaum
Date:
Subject: Re: Core team statement on replication in PostgreSQL