PostgreSQL 高可用，银行金融用的那种，怎么搞？ --群友问系列 一定不是patroni repmgr

❝

开头还是介绍一下群，如果感兴趣PolarDB ,MongoDB ,MySQL ,PostgreSQL ,Redis, OceanBase, Sql Server等有问题，有需求都可以加群群内有各大数据库行业大咖，可以解决你的问题。加群请联系 liuaustin3 ，（共3400人左右 1 + 2 + 3 + 4 +5 + 6 + 7 + 8 +9）(1 2 3 4 5 6 7 8群已经爆满  9群 300+，开10群PolarDB专业学习群110+)

在昨天的文章发表后，给我们的同学看完，私信我的，评论区各种的回复，总结。PG很复杂，方案很多，但放到严谨的生产环境都或多或少都有问题。

那么今天我们来说说为什么，某银行是用PG的时候，选择的高可用是pacemaker 配合Corosync 而不是现在的什么 repmgr,Patroni。

是的如果我是银行的数据库负责人，我也不会用这俩高可用的方式，当然更不会用什么，主从复制，加数据库主从强一致的方案，什么原因大家都知道，用了那个方案如同削足适履。

在金融级生产环境中，PostgreSQL 的高可用设计必须面对一个核心矛盾，数据库理论上的高可用与银行所要求的零数据丢失、零不确定性之间存在鸿沟。任何数据库的理论都无法逾越，行业的要求和规范。

Patroni/repmgr 依赖复制状态和节点健康自动判定主库是否替换。银行生产环境中常见的网络抖动、IO hang、CPU 抖动、虚拟化异常，可能导致误判。误判 = 脑裂，错误切主 = 不可逆的数据风险。

银行真正害怕的是“不确定”，银行不能接受任何一笔账错、任何一次不可解释的切主，银行要的是异常必须可预测、可解释、可人为控制。为什么某储银行采用的是Pacemaker + Corosync + PG的方案，这里个人进行简单的解析。

1 方案中并不是单纯的主从复制的方案，方案是建立在shared storage的方案的基础上，这样的模式下，数据只有一份，存放在底层的SAN 存储区域网络上。这个高可用的结构也是分为三层。

计算层： 两台物理服务器，安装同样的LINUX，Corosync,Pacemaker,两台机器的postgresql.conf ,pg_hba.conf 完全一致，且数据库目录指向同一个挂载点。通过网络层，FC SAN 通过光纤交换机，链接服务器与存储，为了防止单点故障，通常会有两条链路，实现冗余。存储层上，对于两台服务器同时可见，但同一个时间只能一台机器挂载。

在此方案中，Pacemaker 管理的不在是数据库同步，而是资源独占，资源通常按一下方式绑定

1 一个虚拟IP，作为外部访问数据库的入口，存储的挂载和数据库服务的执行成为一个整体，Pacemaker确保将这三个资源像一个整体，永远在又给节点启动，磁盘在任意时间只能属于一个节点。

2 在出现故障的情况下，node B 接管VIP ，进行磁盘的挂载，在启动后会判断数据库的状态一致性，并根据日志进行数据库的REDO

3 这个方案的好处，不存在通过网络传输中产生的数据延迟，或者犹豫数据不一致导致的数据丢失的问题，RPO = 0 ， 只要磁盘没有坏，NODE A写入最后一个字节，NODE B 拉起就可以恢复数据库的状态。

4 摒弃了网络的开销，不需要占用网卡去做WAL的同步，数据库的性能只取决磁盘的速度和性能。

同时对于大家说的，磁盘就一套，磁盘坏了就出问题了，华为的hyperMetor就是在底层方两个存储阵列，通过硬件来进行磁盘的同步。

这样的方案才是金融级的PG数据库的高可用方案，通过将软件的复杂性转移到了硬件的昂贵性，让DBA从复杂的PG同步延迟，流复制解脱出来。

产生这样的方案的根因是金融银行业的特性和底线，总结为行为的可预测性，责任的可追述性，事故的可解释性，风险的可审计性，以及数据库负责人的确认和事前的确认甚至是可签字性。

所以，网络上的patrnoi, repmgr等依赖数据库本身的高可用能力的方案是无法进入金融行业的合规的审查，这样的方案提出马上就会被打回。

为什么，因为他们没法在PG强同步中，在数据不丢失和任何风吹草动的从库出现问题中，主库无法工作中，选择一个方案。无论是Patroni 还是 repmgr 都有可能因为网络，主机硬件，或者操作系统，出现问题后导致的数据丢失。

核心原因只有一个，金融领域的风险不可控。Patrnoi,repmgr,或者单纯的主从非强一致的方案，主从强一致方案，本质都是建立在PostgreSQL物理复制之上的。

而只要是物理复制，都逃不开二选一，要么允许在极端情况下，丢失数据。要么允许从库，网络，操作系统，硬件任意出现问题，主库必须停机，现实是银行不会接受二选一，这俩方案都是“不可选，不可行，不接受”。

因为你无法回答

1 切主时wal是否完整落盘 

2 新主是否包含最后一次事务的提交 

3 业务是否已经和感知并获取事务成功或失败

金融机构里面的安全成功和数据库人自己认为的成功，可不是一回事。只要是通过主从复制，无论PG 还是 MYSQL的日志传输模式的高可用，都是有问题的。银行害怕的是不确定，只是网络抖动，只是主机一时的hang 住就切换，那不是银行和金融机构的做派。

MongoDB “升级项目” 大型连续剧(3)-- 自动校对代码与注意事项

MongoDB “升级项目” 大型连续剧(2)-- 到底谁是"der"

MongoDB “升级项目”  大型连续剧(1)-- 可“生”可不升

MongoDB  大俗大雅，上来问分片真三俗 -- 4 分什么分

MongoDB 大俗大雅，高端知识讲“庸俗” --3 奇葩数据更新方法

MongoDB 学习建模与设计思路--统计数据更新案例

MongoDB  大俗大雅，高端的知识讲“通俗” -- 2 嵌套和引用

MongoDB  大俗大雅，高端的知识讲“低俗” -- 1 什么叫多模

MongoDB 合作考试报销活动 贴附属，MongoDB基础知识速通

MongoDB 年底活动，免费考试名额 7个公众号获得

MongoDB 使用网上妙招，直接DOWN机---清理表碎片导致的灾祸 (送书活动结束)

MongoDB 2023年度纽约 MongoDB 年度大会话题 -- MongoDB 数据模式与建模