小心，从库挂了/慢/卡顿也会影响业务！

文中参考文档点击阅读原文打开, 同时推荐2个学习环境: 

1、懒人Docker镜像, 已打包200+插件:《最好的PostgreSQL学习镜像》

2、有web浏览器就能用的云起实验室: 《免费体验PolarDB开源数据库》

3、PolarDB开源数据库内核、最佳实践等学习图谱:  https://www.aliyun.com/database/openpolardb/activity 

关注公众号, 持续发布PostgreSQL、PolarDB、DuckDB等相关文章. 

---

第44期吐槽:PG 同步复制不支持自动升降级

1、产品的问题点

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

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

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

• • off: 本地wal buffer io完成(异步, 未持久化)

• • local: 本地wal持久化

• • write: wal多副本: 远程wal buffer io完成

• • on: wal多副本: 远程wal持久化

• • replay: 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多副本模式(synchronous_commit = remote_write, remote_apply, on), 并且远程节点一直未响应(或者响应的节点数未凑够副本数), commit/rollback将在队列中死等, 客户端收不到事务结束信号, 导致事务commit/rollback时出现hang的现象.

5、业务上应该如何避免这个坑

• • 方法1: 主动cancel等待, 客户端会收到一个warning信息, 表示事务可能没有同步到远程节点

• • 方法2: 管理员修改PG的事务提交模式设置, 同时发信号给等待中的事务, 降级为异步提交. 参考github.com/digoal/blog 如下文章

• • 《PostgreSQL 如何让心跳永远不死，支持半同步自动同步、异步升降级 - udf 心跳》

• • 《PostgreSQL 双节点流复制如何同时保证可用性、可靠性(rpo,rto) - （半同步，自动降级方法实践）》

6、业务上避免这个坑牺牲了什么, 会引入什么新的问题

• • 管理更加复杂

• • 改成异步模式后, 当在丢失的节点再次加入流复制节点之后, 需要再改回同步复制

• • 人为的介入时间周期长, 响应不及时, 高峰期的抖动及其可能引起业务雪崩.

7、数据库未来产品迭代如何修复这个坑

• • 内核层支持同步模式自动升级、降级 (半同步, 自动升级, 自动降级)

• • 目前RDS PG支持, 并且阿里云PolarDB PG基于共享存储的版本已经开源, 规避了数据库流复制多副本机制带来的问题.

往期吐槽文章：

欢迎大家留言或联系我把踩过的坑发过来, 一起鞭策开源和国产数据库: 

16 空缺,因为这一期的吐槽PG社区已经落实了.

本期彩蛋-招商中,有需要的小伙伴可联系嵌入...

文章中的参考文档请点击阅读原文获得. 

---

欢迎关注我的github (https://github.com/digoal/blog) , 学习数据库不迷路.  

近期正在写公开课材料, 未来将通过视频号推出, 欢迎关注视频号: