PostgreSQL 的 Patroni 是一个系列, 目前已经写到了 4 , 实际我也不知道应该写到多少结束.
2019 PGCONF Asia 中有这么一篇演讲,关于POSTGRESQL 的高可用的问题,其中提到常用的三种Postgresql 的高可用方式, 其中repmgr 之前写过了,当然其实还不完善, 另外一个就是我们今天提到的 Patrnoi , 不大想一开始就是安装, 还是从他的起源和历史来,要不使用了,还不知道他从哪里来, 有可能从哪里去, 也枉然用过他.
一个开源的软件,你首先的知道他的来自于哪里, 要不哪天断供了,怎么办,patrnoi 来自于大欧罗巴的德国, 总公司位于柏林. 这是一家在欧洲知名的电商公司,主营的业务是主营时尚圈的事情, 当然还有表, 技术员工在1700人.
那这个软件的作者是谁 Alexander 和 Oleksii (其实有时候真该反思反思, MYSQL 的MHA 是日本人发明的, Postgresql Patroni 是德国人发明的, 当然还有 挪威人, 俄罗斯人发明的一些类似的东西),并且在世界范围使用.
为什么要使用patroni ,对比目前的常用的高可用的方式存在的问题
1 提升一个复制节点时无响应的情况下,存在脑裂的可能
2 单一的monitor节点对于集群的监控缺陷以及失败节点必须被清理的问题
3 多点监控中的分布一致性的问题
所以patrnoi 的诞生是因为这些问题在其他的方式中并没有被解决, Patrnoi 本身并没有在内部来解决上述问题,而是巧妙的使用了,大部分常用的DCS , Distributed configuration system (DCS), 例如 etcd zookeeper ,consul 等来作为解决上面3个问题的方法.
任何解决方案都有他的Pros 和 Cons , Patrnoi 的 Cons 又是什么, 例如当某个节点并未和主节点连接的情况下,可能Patrnoi 可能无法判断,还是显示从属节点. 另外还需要对于ZOOKEEPER 或者 ETCD 等有相关的知识, 设置上可能不如 repmgr 要简单方便.
当然也有一些不客气的话,对于POSTGRESQL 的其他的HA的方案,例如 DRBD, COROSYNC pacemaker ,repmgr 等方案 用上了 out of date 的词汇.
实际上, repmgr 的变化方式已经在某云使用了, 不知道他们听到如此的词汇作何感想.
实际上到底Patrnoi 有没有一个简单的 introduce
Patroni 是一个有 Zalando 研发的,完整由python 代码的开源产品,通过DCS来对postgresql 各个节点的状态进行判断, 在添加节点方面你需要通过你熟悉的手段来自行添加节点(repmgr在安装中会将节点加入), 同时还能定义类似 MHA 中某些节点一直是standby的角色,不参与mater的竞争, 其中还能定义一些触发行为,例如在 start , stops , failover 等状态下触发后,到底要继续做些什么. 并且也可以类似MHA 的方式手动切换主节点.
那么还有一个问题值得来说,到底 patroni 应该最低是几个几点, 这里建议是3个节点, 这和 MYSQL 的MHA 中建议的三个节点是一个意思, 大多数原则,防止由于网络等问题,造成的一些双数节点出现的不可预测的问题.
另外repmgr 本身是可以通过witeness的技术防止类似问题,但起步也是最少三个节点,但这又给了文字最初英文中,out of date 中提出的单点monitor 于口实. 所以patrnoi 的确在某些方面要比某些高可用的方案 ,严谨.
所以选择patrnoi 作为postgresql 的高可用的方式是有可圈可点. 另外通过docker K8S 部署patroni的方案也是有的,参见下图, 也是目前另一种更方便的并且适合大批量部署的方式.
