openGauss 中的最大可用模式为什么 PG 不做 ​

pg 有个一直遭人诟病的地方就是主备同步模式不能自动降级，这样会造成在同步模式下备库故障会影响主库的可用性。其实主流商业数据库如 oracle、mysql 等都支持在同步模式备库异常时自动进行降级，不影响或者短暂影响主库可用性。

至于 pg 为什么不做这个功能我也想了很久，下面是我自己的一点猜测。

pg 是个追求完美主义的数据库，他从架构设计层面就会考虑如何做到完美，比如说他不用主流数据库都在使用的 undo，我猜测这个原因是因为，使用 undo 有一个问题，undo 空间不管是文件系统还是表空间都是有大小限制的，而数据库未提交的事务信息可能是无限大的，这样数据的前镜像总有可能将 undo 空间撑爆掉，这样就需要清理旧的 undo 段，如果需要查询的 undo 前镜像备清理了，数据库就会跑出错误，这就是 oracle 中经典的 snapshot too old 报错。所以 pg 摒弃了这种模式，因为他觉得必须要提供给用户一个需要的数据一定能查到的数据库，而不是本该能查到的数据被无端清理掉了，所以 pg 使用了多数据版本来解决这个问题，将前镜像的真实数据放在数据文件中，真正确保没有事务可能再去访问该数据时才进行清理。当然这样也带来膨胀的问题，这其实也是 pg 最遭人诟病的问题。

再来说说最大可用。pg 为了追求完美，一定要确保在同步模式下切换不丢数据，这个其实保证的是：如果在 pg 里设置成主从同步，那么在主备 failover 或者备库直接 promote 那一刻主备的数据是完全一致的，这个我觉得是 pg 想保证的东西，因为既然说是同步模式，那么不丢数据是基本要求。那么再来看看最大可用有什么问题。最大可用模式的解释是：在主备连接正常情况下，主备之间以同步模式提交数据，当主备之间遭遇异常导致主备连接失败那么会自动切为异步模式，不影响主机可用性。

这里其实有两个问题，第一个是虽然设置了同步模式，但是不能保证切换那一刻主备数据是完全一致的，试想如果某个时间点主备之间网络发生闪断或者波动，这时很短地切为了异步模式，这时候主库依旧在写入数据，备库此时依旧同步不到了，如果这时候发生了切换，备机提升后数据相比主库是少的。这种情况的概率很低，但是有可能发生。所以我猜测 pg 的考虑是将低概率事件也进行消灭，给用户确切的保证，追求完美。另外一点是最大可用需要有超时窗口，这样其实是在给用户一个选择，让用户去决定我有多大事件的可用性容忍度，如果超过这个容忍度，那么我宁愿冒着可能的数据丢失风险也要进行切换保证可用性。这个参数其实是必须的，目前 openGauss 虽然做了最大可用，但是缺乏这个参数，主备降级很快，目前测试应该是 1s 以内完成切换，这个其实不合理，超时参数的需求已经提交给华为。

总体上我觉得最大可用模式还是利大于弊，如果没有最大可用，那么我们需要额外开发监控体系监控备机的可用性，在备机异常时触发降级。这样其实很不友好，还是希望 pg 将这个功能尽快实现。