On Jun 17, 2011, at 8:17 AM, <[email protected]> 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 _______________________________________________ Pgpool-general mailing list [email protected] http://pgfoundry.org/mailman/listinfo/pgpool-general
