已经写到了第五期, 最近深感学习一件东西,可以和秋风扫落叶的一样的学习和理解,也可以和冰血暴一样的学习了理解,决定用那种方式学习,主要依靠

1  这门技术是临时使用还是基础性的常识

2  这么技术是处于整体知识的什么层次,是基础层还是上层

3  如果这么技术在使用中出现问题,则会造成多大的风险,当时在去弥补是否能快速降低损失.

所以 patroni 占用了不短的一个时间, 对比proxysql也是一样,那个系列也会持续.

首先先说为什么要有watchdog  , 见上图, 如果我们的系统在运行是出现问题,节点PG1 失效了,无论是网络的问题,还是主机本身的问题,此时都是要进行重新选举,此时问题就产生在 3 开始选举leader

上期说配置文件的时候

• loop_wait: the number of seconds the loop will sleep. Default value: 10

• ttl: the TTL to acquire the leader lock (in seconds). Think of it as the length of time before initiation of the automatic failover process. Default value: 30

• retry_timeout: timeout for DCS and PostgreSQL operation retries (in seconds). DCS or network issues shorter than this will not cause Patroni to demote the leader. Default value: 10

还的祭出这三条, 1 loop_wait, 2 ttl  3 retry_timeout

已默认值来说一个节点的切换 10+ 30 + 10 是最大的时间, 但实际上会有另一个问题,在选举中,此时所有节点包含失效的节点,都会出现一个问题,此时没有节点是leader, 在此时数据写入的需求是怎么处理的问题.

未了避免脑裂,Patroni 需要确认postgresql 不能在leader 键值在DCS过期后继续接受事务的commit, 在patroni 无法进行 leader lock后,则patroni 将开始试图停止postgresql的方式来保证此期间的不会有脑裂的问题.

watchdog 的主要产生的原因是,如果patroni 无法在此刻关闭postgresql 怎么办? 因为patroni 也不是"孙悟空",也是人肉一枚, 如果由于各种原因导致patroni本身无法工作,watch dog 将尝试从新启动系统,如果工作后,无论怎样patroni还是无法正常工作,则watchdog模式如果设置成required 则这个所在的问题节点是不能成为leader的.当整体选举leader成功后, patroni 将会让watchdog进入休眠的状态.

但在设计watchdog 时会有一个问题,因为设计时差的问题,导致watch dog 本身无法获得patroni 发送的信息,最终在这个工作周期,无法激活 watch dog.  这个时间的设定较 safety margin. 官方给出的建议并不明确,只提到了 watchdog timeout 调整到ttl的一半的时间, 确保watchdog能受到信息,从对loop_wait 和  retry_timeout入手.

默认使用patroni 的数据库机器需要执行

modprobe softdog

chown postgres /dev/watchdog

这里大部分使用的是 LINUX 本身的watch dog

关于watch dog有三个设置

watchdog:

mode:  Allowed values: off, automatic, required

mode的值有三个  1  off 不运行watch dog  2  automatic 根据设置的情况,默认使用watch dog ,但如果配置出现问题,watch dog 出现问题,则不使用watch dog ,required  必须使用watch dog 否则无法选择leader

device: /dev/watchdog   watch dog 设备本身

safety_margin: 5  看门狗触发和主控键过期之间的安全余量秒数。