[Pgpool-general] Can a failed master rejoin as a slave?

Matt Solnit msolnit at soasta.com
Fri Jun 17 16:02:57 UTC 2011


On Jun 17, 2011, at 8:17 AM, <Daniel.Crespo at l-3com.com> wrote:

>> Hi, Matt
>>> pgpool-II immediately attempts to use it as a master again.  This doesn't work, obviously, because it's no longer a master.
>> I dont understand why it doesnt work. 
>> AFAIK node with the youngest id(backendX in pgpool.conf) and status 2(psql -c 'show pool_nodes;') will always become a primary node.
>> 
>> Check this out:
>> The backend which was given the DB node ID of 0 will be called "Master DB". When multiple backends are defined, the service can be continued even if the Master DB is down (not true in some modes). In this case, the youngest DB node ID alive will be the new Master DB.
>> http://pgpool.projects.postgresql.org/pgpool-II/doc/pgpool-en.html 
> 
> The problem Matt points out is precisely when primary DB *is re-attached*. After re-attaching the primary DB (node ID 0), it's "back online", therefore, pgpool treats it as the master again, according to your cited explanation. So I agree with Matt: the just re-attached Node 0 should be slave from now on, since it was technically attached AFTER selecting the new master (which is Node 1 at this point).
> 
> -Daniel

Exactly.  With streaming replication, only the "true" master can accept DML statements (insert/update/delete), so if pgpool-II attempts to send them to the wrong node, you get a "connect execute XYZ in a read-only transaction" error.

This thread seems to cover the same question, but I couldn't really tell what the resolution was:
http://lists.pgfoundry.org/pipermail/pgpool-general/2011-April/003568.html

-- Matt


More information about the Pgpool-general mailing list