diff --git "a/content/zh/post/shujukujiagouzhimei/openGauss\344\270\255\347\232\204\346\234\200\345\244\247\345\217\257\347\224\250\346\250\241\345\274\217\344\270\272\344\273\200\344\271\210PG\344\270\215\345\201\232.md" "b/content/zh/post/shujukujiagouzhimei/openGauss\344\270\255\347\232\204\346\234\200\345\244\247\345\217\257\347\224\250\346\250\241\345\274\217\344\270\272\344\273\200\344\271\210PG\344\270\215\345\201\232.md" new file mode 100644 index 0000000000000000000000000000000000000000..ba9d965359c6f66cc8ebfac9dfb930430a88958b --- /dev/null +++ "b/content/zh/post/shujukujiagouzhimei/openGauss\344\270\255\347\232\204\346\234\200\345\244\247\345\217\257\347\224\250\346\250\241\345\274\217\344\270\272\344\273\200\344\271\210PG\344\270\215\345\201\232.md" @@ -0,0 +1,34 @@ ++++ + +title = "openGauss中的最大可用模式为什么PG不做" + +date = "2020-11-25" + +tags = ["openGauss与PG对比"] + +archives = "2020-11" + +author = "数据库架构之美" + +summary = "openGauss中的最大可用模式为什么PG不做" + +img = "/zh/post/shujukujiagouzhimei/title/title2.png" + +times = "10:30" + ++++ + +# 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将这个功能尽快实现。 + diff --git a/content/zh/post/shujukujiagouzhimei/title/title2.png b/content/zh/post/shujukujiagouzhimei/title/title2.png new file mode 100644 index 0000000000000000000000000000000000000000..3bcb6926cbb77814822d65867115b851926608e9 Binary files /dev/null and b/content/zh/post/shujukujiagouzhimei/title/title2.png differ