Windows Server 2019环境下PostgreSQL见证服务器配置的repmgr变通方案

核心前提澄清：PostgreSQL高可用集群中的见证服务器，本质是用于参与故障仲裁、规避脑裂风险的独立节点，并非必须绑定repmgr组件才能实现。结合Windows Server 2019的环境约束，完全存在可落地的技术变通路径。

可落地的实现路径 #

1. 完全绕开repmgr的原生PG架构实现 #

该路径不需要依赖任何repmgr组件，完全基于PostgreSQL原生能力和兼容Windows的高可用组件完成见证配置：

• 在Windows Server 2019上安装与业务节点完全同版本的PostgreSQL 9.6.6实例，确保版本小版本完全对齐，避免流复制协议不兼容
• 配置该实例作为主库的异步流复制节点，通过专属复制槽只同步集群元数据，不承载任何业务表写入，磁盘资源占用可控制在极低水平
• 替换原repmgr的仲裁投票能力，选择支持Windows运行的高可用管理组件（如适配Windows构建版的Patroni、自定义集群检测脚本），将该Windows节点纳入集群仲裁组：故障发生时，节点基于自身记录的最新复制位点、网络连通状态参与多数派投票，即可发挥见证服务器的核心作用
• 该方案完全规避了repmgr不支持Windows的兼容问题，且所有运行组件均可原生适配Windows Server环境，无额外适配层带来的性能损耗。

2. 基于WSL兼容层的repmgr原生能力复用方案 #

如果希望直接复用repmgr成熟的集群管理逻辑，不需要自定义仲裁规则，可以通过Windows内置的WSL组件实现变通：

• 在Windows Server 2019上启用WSL功能，安装适配的Linux发行版
• 在Linux子系统环境内，按照repmgr官方要求安装适配PostgreSQL 9.6的对应版本repmgr，将该节点配置为repmgr集群的见证服务器
• 注意需做好网络透传配置，确保WSL内运行的repmgr进程、PostgreSQL端口可与集群内其他节点正常通信；数据库文件不要存放在Windows挂载路径下，避免文件锁冲突与IO性能下降
• 该方案本质是在repmgr官方支持的Linux环境下运行组件，没有修改repmgr本身代码，不存在非官方构建带来的兼容风险。

3. 轻量化脚本实现的极简见证方案 #

针对小规模Web应用的简单高可用场景，不需要引入复杂管理组件：

• 在Windows上部署同版本PG实例，建立与主库的流复制连接，不加载任何业务数据
• 编写轻量PowerShell检测脚本，定时检测主库连通性、自身复制延迟，当集群主备节点出现网络分区时，脚本按照预定义的投票规则输出仲裁结果，通知对应节点执行切换流程即可。

配置时需要规避的风险 #

• 不要尝试安装非官方渠道编译的Windows版repmgr：这类第三方构建往往存在进程稳定性缺陷，容易出现repmgrd异常退出、节点通信中断的问题，反而会引发集群仲裁失效
• 提前配置Windows防火墙规则，放行5432（PostgreSQL）、对应高可用组件的通信端口，避免网络拦截导致见证节点无法参与投票
• 严格对齐所有节点的PG版本号：Windows侧见证节点的9.6.6小版本必须和业务主、从节点完全一致，否则会出现流复制握手失败的问题。

内容的提问来源于stack exchange，提问作者Raky