使用Patroni回调脚本绑定VIP的坑

    我们知道patroni可以通过参数callbacks执行回调脚本， 当patroni触发的特定动作比如启动、关闭或者角色切换时会触发这个脚本，我们可以通过这个脚本绑定VIP、立刻执行一次数据库备份或者启动某个服务等等。

    对于集群VIP配置网上有很多方案，但是最简单的莫过于使用回调脚本绑定VIP，简单又方便，但是简单就会带来问题，下面分享一个关于使用回调脚本绑定VIP遇到的坑。

    我有一个patroni管理的三节点集群（一个主节点、一个同步备节点和一个异步备节点），在一次上线新应用的时候，由于应用同事连接池配置问题导致连接占满（包括复制用到的连接）、负载过高，主备发生了切换，原主节点降备，同步备节点升主，但是由于原主节点负载过高导致VIP没有及时释放，应用仍然对持有VIP的备节点执行大量并发的DML\DDL操作，短暂延迟后新主节点获取VIP同时应用通过VIP在新主节点上执行了大量并发DML\DDL操作，由于连接池配置问题新主节点再次因为连接占满、负载过高发生了主备切换，此时就出现了一个问题，集群所有节点均为只读，主节点错误信息如下：

ERROR:  cannot execute UPDATE in a read-only transaction

官方文档中有两个参数：

    max_standby_streaming_delay默认为-1允许备机一直等到冲突查询结束。

    hot_standby_feedback默认为off，它阻止VACUUM 移除最近死亡的元组并且因此清除冲突不会产生。

    这两个参数都使用了默认值，也就是说当备节点执行一个慢SQL，同时主节点对慢查询SQL进行DDL操作时，首先主备会产生延迟，在延迟发生之后再次发生主备切换就会导致集群异常，所有节点均为只读。

    如果遇到这样的问题我们只要在所有节点找到并停掉慢查询语句就可以。当然还有最简单的方法，把主节点reovery.conf文件（PG12之前）删掉，重启主节点数据库即可，但是同时可能相应的备节点需要重建。v

数据库集群系统使用一般分为几种情况；

• 主节点负责读写，备节点只作为高可用。
• 主节点负责读写，备节点负责读。
• 主节点只负责写，备节点负责读。

如果第一种情况不使用CALLBACKS方式绑定VIP的话倒是无所谓，如果使用，那么上述三种情况为了避免此类问题都应当合理配置三个参数：

• max_standby_streaming_delay
• hot_standby_feedback
• max_standby_archive_delay

其实问题的根本还是连接池配置不合理，作为数据库DBA的我们很难去左右应用的开发和配置，但是我们要做到数据库合理的参数配置、完善的监控以及合理的建议。