背景
1、产品的问题点
- PG 同步复制不支持自动升降级
2、问题点背后涉及的技术原理
- PG 支持多种事务提交级别 (synchronous_commit):
- 本地wal bufferio完成(异步, 未持久化)
- 本地wal持久化
- wal多副本: 远程wal bufferio完成
- wal多副本: 远程wal持久化
- wal多副本: 远程wal恢复完成
synchronous_commit = local, remote_write, remote_apply, on, off synchronous_standby_names = [FIRST] num_sync ( standby_name [, ...] ) ANY num_sync ( standby_name [, ...] ) standby_name [, ...]
3、这个问题将影响哪些行业以及业务场景
- 使用PG 流复制作为高可用搭建基础, 并且开启了同步复制模式的场景.
4、会导致什么问题?
- 如果用户的事务选择了wal多副本模式, 并且远程节点一直未响应(或者响应的节点数未凑够副本数), commit将在队列中死等, 客户端收不到事务结束信号, 导致事务提交hang的现象.
5、业务上应该如何避免这个坑
- 主动cancel等待, 会收到一个warning, 表示事务在远程可能没有同步
- 管理员修改PG的事务提交模式设置, 同时发信号给等待中的事务, 降级为异步提交
- 《PostgreSQL 如何让心跳永远不死，支持半同步自动同步、异步升降级 - udf 心跳》
- 《PostgreSQL 双节点流复制如何同时保证可用性、可靠性(rpo,rto) - （半同步，自动降级方法实践）》
6、业务上避免这个坑牺牲了什么, 会引入什么新的问题
- 管理更加复杂
- 改成异步模式后, 还需要改回来?
- 人为的介入时间周期长, 响应不及时, 高峰期的抖动及其可能引起业务雪崩.
7、数据库未来产品迭代如何修复这个坑
- 内核层支持同步模式自动升级、降级 (半同步, 自动升级, 自动降级)
- 目前RDS PG支持, 期待polardb pg支持并开源
