PostgreSQL 来自欧罗巴Patroni 为什么选择Patroni 系列 1

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的方案也是有的,参见下图, 也是目前另一种更方便的并且适合大批量部署的方式.