在众多postgresql 高可用模式中，主要的参与者有两位， Patroni VS repmgr 基于这二者的功能优点以及缺点相信大部分人都不是太明确，下面将根据两篇翻译的文字合并，来对两个高可用的程序来做一个比较， cons and pros。
1 Repmgr 是一款开源的基于postgres复制基础上的高可用软件，他基于2ndQuadrant 公司开发而来，提供完整的基于从安装到部署，从设置到管理以及监控的一体化的postgresql 高可用方案，并且支持手动的POSTGRESQL 高可用切换和自动切换的方案，支持看门狗的模式。
通过repmgr 程序来对服务在数据库内进行注册，并且通过repmgrd来进行多点的failover监控，可以在切换的过程中完成选主，与损坏节点再次加入到集群中，作为从库的一体化方案。并且提供延迟的方案，以预防网络不稳定带来的误切换的问题。
在集群中的节点数为偶数的情况下repmgr 本身通过witness见证服务器来解决脑裂的问题，见证服务器是一个节点，只考虑多数投票计数。
2 Patroni
Patroni 本身起源于一个Governor 的分支，来自于一个compose 项目，在Zalando 中被改进的原来越好用。https://github.com/zalando/patroni，这是一个python 编写的开源工具组件，通过他来进行POSTGRESQL的集群高可用性的支持，通过分布式存储的方式来完成一致性模型，目前一般配合etcd 基于raft 协议的分布式系统来使用。Patroni确保PostgreSQL HA集群的端到端设置，包括流复制。它支持创建备用节点的各种方式，工作方式类似于模板，可以根据您的需要进行定制。通过patroni 可以自动完成postgresql服务失败自动拉起，以及主从节点的切换和失败节点重新加入等功能。同时基于分布式存储的特性可以直接防止脑裂的发生。并且通过分布式存储来获得leader节点，确保在任意时间只有一个主节点进行对外服务。
通过上面的介绍，可以比对出二者不不同点
1 Patroni 本身是一个开源项目目前在Zalando 手里进行维护和发展
Repmgr 是PG 数据库开发公司2象限的产品，目前开源
2 Patroni 本身通过DCS 来进行数据节点的选主和高可用信息的存储，所以 选择分布式存储对 patroni本身来说是重要的。
Repmgr 是本身并不使用分布式协议，采用的是传统类比传统数据库的方 式来进行高可用的设置，一般对于双机的高可用是支持的
比对 Patrnoi repmgr
两节点支持 不建议，起步三节点 支持
版本持续更新 支持 支持
需要安装分布式 需要 利用POSTGRESQL 存储
存储
支持多种数据节 支持 pg_bacebackup
点添加方式
需要各个节点免密 需要 需要
有管理命令 有 有
手动切换 可以 强
自动切换 可以 启用repmgrd
多次failover 可以 不可以
配置文件修改 一般 灵活
方便灵活
基于上面的一些点我们可以来详细的说一下
1 如果仅仅是想安装类似 ORACLE DG ADG 这样的方式，同时想做一个热机主备的方式，repmgr 是一个好的选择，Patrnoi本身对主机的节点的数量没有要求，但一般安装分布式存储如果使用通用的ETCD 则必须包含ETCD 基于raft 协议，必须是三台起步。
2 需要安装分布式存储，Patrnoi 本身是需要安装 etcd 或其他的分布式存储软件的，repmgr本身的一些日志信息以及节点信息是安装在本地节点PG中的repmgr 数据库里面的，所以不需要其他软件的安装
3 手动切换中，由于repmgr是通过repmgrd 来进行监控并自动进行切换的，所以停止repmgrd 程序本身，通过 repmgr命令直接启动切换步骤即可，patrnoi 在此方面可以通过命令来进行切换
4 对于 如果在系统中由于不稳定导致网络丢包或者主机频繁切换，patroni 是可以支持，基于分布式存储来进行主机的选举，repmgr 本身无法接受此方式，一次切换后，需要重置一些配置后，恢复正常工作
5 参数的配置的灵活性，patrnoi 对于参数的修改本身是有要求的，需要通过程序本身进行参数的修改然后加载或者通过patrnoi本身来进行reload， 对于需要重启的情况不十分灵活，要求多， 对于REPMGR，对参数的修改没有特殊要求。
实际上两者的高可用方式都有可圈可点的地方，本期就先到这里，下期会对两个高可用的软件进行更细致功能对比。
