已经写到了第五期, 最近深感学习一件东西,可以和秋风扫落叶的一样的学习和理解,也可以和冰血暴一样的学习了理解,决定用那种方式学习,主要依靠
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 看门狗触发和主控键过期之间的安全余量秒数。
