磨砺技术珠矶，践行数据之道，追求卓越价值
回到上一级页面： PostgreSQL集群方案相关索引页 回到顶级页面：PostgreSQL索引页
在health_check_period 有效的情况下，当 pgpool-II 所连接的节点如果有了故障，
会引发如下几件事：
1 在main.c的主循环中标记出故障的节点不可用(log中会看到：类似set 1 th backend down status)，
2 然后调用 failover()函数，切断所有的连接(kill 所有process：log中会看到：Restart all children)；
3 再然后，重新开始对尚且有效的各节点进行连接
(重新创建一堆子进程：log中会看到：pcp child process received restart request)
设想一下我们正在通过pgpool来执行一个transaction。
如果尚未提交，发生了某节点故障，
那么对剩余的正常节点而言，
failover()会导致向各个节点未提交的内容没有commit的机会，故此各个节点都是数据一致的。
但如果恰恰是在对各个节点提交的时候，发生了某节点故障，导致failover()呢？
那么会发生某个节点已经发送commit命令成功，向某些节点发送commit命令之前，连接被切断。
这样就产生了数据不一致了。 这种事情，虽然发生机会很低，但是已经切实地发生过。
pgpool作为一个第三方的，独立于postgresql 的开源产品，还是有点尴尬的。
它如果不引入 transaction manager来进行 类似于两阶段提交的控制，而是仅仅一行一行地发送客户端的指令给postgresql ，必然会在最坏的情况下，产生出：
由于故障发生退化(failover), 由切断所有连接导致正常节点间出现数据不一致。
又由于failover_if_affected_tuples_mismatch)设定，
导致再次发生退化，进入恶性循环，最坏的情况下，只剩下一个master节点可用。
要想解决这个问题，除非pgpool开发者痛下决心，引入transaction manager，
或者提供高层API，供客户端程序调用。而不再是那种在客户端和数据库节点间处于透明的中介地位。
回到上一级页面： PostgreSQL集群方案相关索引页 回到顶级页面：PostgreSQL索引页
磨砺技术珠矶，践行数据之道，追求卓越价值