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

[Anton Koldaev]

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

On Fri, Jun 17, 2011 at 8:49 AM, Matt Solnit <msolnit at soasta.com> wrote:

> Hi everyone.  I'm using pgpool-II with PostgreSQL 9.0 in streaming
> replication mode, and I'm able to get failover working correctly -- when the
> primary (master) goes down, the slave is promoted and everything is great.
>  However, when I bring the primary back online using pcp_recovery_node, I
> find that pgpool-II immediately attempts to use it as a master again.  This
> doesn't work, obviously, because it's no longer a master.
>
> Should pgpool-II be able to support this?  Ideally I could fail back and
> forth between the two nodes all day long, and pgpool-II would constantly
> know which is the master and which is the slave.
>
> Any help would be sincerely appreciated.  I can provide configuration
> files, log files, etc. if needed.
>
> -- Matt
>
> P.S.  The specific versions I'm using are pgpool-II 3.0.4 (built from
> source) and PostgreSQL 9.0.2, on 64-bit Linux.
> _______________________________________________
> Pgpool-general mailing list
> Pgpool-general at pgfoundry.org
> http://pgfoundry.org/mailman/listinfo/pgpool-general
>



-- 
Best regards,
Koldaev Anton
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://pgfoundry.org/pipermail/pgpool-general/attachments/20110617/fee541b5/attachment.html>