POSTGRESQL 高可用 Patroni VS Repmgr 到底哪家强（2） 更详细的指标

接上期，上期大致比对了一下基本的指标，本期就的详细的比对一下两个高可用软件的信息的功能了。

以上信息展开来看

以上的8个点分别针对两种高可用方式中的 主节点 和 从节点 以及高可用服务本身。

从以上几点来分析, Patroni 明显在数据库服务停止时，及时的拉起postgres的数据库服务， 这点对比repmgr 明显是有优势的。对于一些由于服务进程本身停止或退出的情况可以立即的进行补救，避免切换的动作。而反观repmgr 本身基于监控postgres主进程的状态，如果进程停止，必然会触发切换的动作。

另从主节点切换后，都提供基于PG_REWIND基础的，节点回归方式，这点是二者相同的。

但Patroni 有一个问题，就是在patroni 服务本身失效的情况下，有可能会产生双主的问题，而更糟糕的是在patroni 在旧主节点再次生效下，一些在双主时期写入旧主的数据会通过pg_rewind 被抹除掉，造成数据丢失。这点是一个硬伤，所以在使用patroni的时候，必须对patroni 服务本身进行严格的监控，同时必须配置一个靠谱的 VIP 服务及时切换，让应用写入新主。这个问题就基本上避免了。

从网络的角度，9和10两点针对网络的抖动和不稳定对于数据库高可用本身也是一种挑战，假设主节点和从节点网络突发出现问题，patroni 和 repmgr 两者本身对网络问题是如何进行应对的。

从最上面的图看，patroni 在面对网络的抖动的方面要强于 repmgr， 这主要也是基于二者的高可用架构的不同，patroni 本身是建立在raft 协议，或者paxos 协议上的一个模板，（具体是raft 还是 paxos 看你使用的分布式存储系统），这就奠定了patroni本身具备网络故障时进行问题粗粒的优势， 反观repmgr 本身是基于类似双机热备，模式，让他对网络的抖动进行快速的处理这在设计中就是劣势，加入monitor wintness 节点后会提高repmgr抵御网络问题的能力。

从第一期到本期，最终我们总结一下二者的优缺点

REPMGR 优点

Regmgr 提供了一套可以直接进行主从配置的程序，在部署repmgr本身就可以制作一套主从复制的节点，并且添加节点也比较容易。

本身安装简单，不使用任何额外的网络端口，通过SSH 本身进行相关的高可用工作支持。

提供用户注册的方式对集群中的节点进行前期的设置，可以方便的设置针对切换的敏感程度。

Patroni 优点

Patroni 启用的是一个端到端的服务支持REST APIS 对于二次开发是友好的，基于DSC 的概念，是一款具有分布式理念的高可用软件。针对网络问题可以较好的处理高可用切换。

REPMGR 问题：

REPMGR 针对postgresql的配置本身不会检测 standby 从库的问题，如果在切换过程中，发现主从库的配置不一，导致切换后出现问题，这需要DBA 本身对工作的细致以及责任。

本身基于服务本身状态提供和发现，不基于分布式协议。

切换后的注册信息，需要手工去处理。

Patroni 问题：

Patroni 本身是不会检测复制连接的状态，当主从的复制不工作的情况下，此节点还是会被展示成一个从库， 同时patroni的安装一直是一个比较复杂的问题，需要选择一款 DCS软件并且对此软件的工作原理和操作有比较深的使用知识。需要设置多个端口来提供相关的服务，并且如果遇到服务器出现性能超负荷的情况下，分布式软件的部署的位置有可能会影响本身Patroni 判断和工作的状态。

总结：两款产品都有自己的特点和优势，也都有自己的问题点，熟悉自己工作环境中的问题点（如主机稳定不高或网络不稳定），针对高可用中的某些服务建立有效监控，调整参数，甚至进行二次开发，降低高可用配置的难度与结构的复杂性，选择好基于postgresql 的一款好用的高可用软件。