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

最新推荐文章于 2025-03-28 10:08:30 发布

原创最新推荐文章于 2025-03-28 10:08:30 发布

· 690 阅读

2 ·

版权

文章标签：

#网络 #分布式 #数据库 #linux #java

本文对比分析了Patroni与Repmgr这两款PostgreSQL高可用软件的特性与优劣，包括它们在网络抖动、服务重启及故障切换方面的表现。Patroni在服务重启和网络稳定性方面表现更佳，而Repmgr则提供了更简便的主从配置。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

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

以上信息展开来看

序号	详细指标	指标对象
1	清理postgresql 进程，系统可被拉起使系统正常	针对高可用 standby对象
2	手动停止postgres 进程，系统被拉起进行工作	针对高可用 standby对象
3	重新启动postgresql, 自动拉起postgresql服务	针对高可用 standby对象
4	关闭patroni 服务或关闭 rpemgrd 服务	针对高可用 standby对象
5	清理postgresql 进程，系统可被拉起使系统正常	针对高可用 master对象
6	手动停止postgres进程	针对高可用 master对象
7	重新启动服务器	针对高可用 master对象
8	停止patroni 进程或停止repmgr 进程	针对高可用进程

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

Patroni	Repmgr
可以	功能不满足
可以	功能不满足
默认重启服务器也强制拉起数据库	不会强制拉起postgresql 数据库服务
相关命令失效，数据库服务不在被监管	基本服务政策，故障切换功能停止
直接拉起服务，写入会有停顿	启动提升从库的策略，从库升为主库，切换中有写入停顿
直接拉起服务，写入会有停顿	启动提升从库的策略，从库升为主库，切换中有写入停顿
主从节点开始切换，重启服务器变为从节点加入到原集群	主从节点开始切换，重启服务器变为从节点加入到原集群
产生双主，产生新主，旧主同时工作	主不能被切换

从以上几点来分析, 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 的一款好用的高可用软件。