【DB吐槽大會】第44期 - PG 同步複制不支援自動升降級

背景

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支援并開源

https://github.com/digoal/blog/blob/master/202109/20210915_04.md#postgresql-%E8%AE%B8%E6%84%BF%E9%93%BE%E6%8E%A5 https://github.com/digoal/blog/issues/76