背景

1、产品的问题点

• PG 同步复制不支持自动升降级

2、问题点背后涉及的技术原理

• PG 支持多种事务提交级别 (synchronous_commit):

• • 本地wal bufferio完成(异步, 未持久化)
  • 本地wal持久化
  • wal多副本: 远程wal bufferio完成
  • wal多副本: 远程wal持久化
  • wal多副本: 远程wal恢复完成

https://www.postgresql.org/docs/14/runtime-config-replication.html#RUNTIME-CONFIG-REPLICATION-PRIMARY

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支持并开源