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

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

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

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

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