【DB吐槽大會】第79期 - PG standby不支援配置多個上遊節點

背景

1、産品的問題點

• PG standby不支援配置多個上遊節點

2、問題點背後涉及的技術原理

• PG 實體流複制協定支援将wal資料發送給下遊節點, 實作實體的增量同步.
• 每個下遊節點隻能配置一個上遊節點.
• PG 的一個上遊節點可以配置多個下遊節點, 下遊節點還可以配置集聯的下遊節點.
• 在一個WAL複制的叢集拓撲中, 每個節點的WAL檔案内容是一樣的, 是以理論上可以互相補位複制.

3、這個問題将影響哪些行業以及業務場景

• 通用(使用了實體流複制的場景: 高可用、隻讀執行個體、容災等)

4、會導緻什麼問題?

• 如果上遊節點挂了, 下遊節點就接收不到wal日志, 需要及時改流複制的連接配接配置, 連接配接到活着的節點. 如果改配置不及時可能導緻新的上遊節點WAL已清理, 需要重建或rewind修複下遊.
• 如果上遊節點是HA架構, 一旦發生主從切換, 下遊節點可能和上遊節點的WAL發生分叉, 導緻下遊節點需要重建或rewind修複.

5、業務上應該如何避免這個坑

• 及時發現, 人工處理. 或者有自動化運維工具進行發行和處理.

6、業務上避免這個坑犧牲了什麼, 會引入什麼新的問題

• 門檻高

7、資料庫未來産品疊代如何修複這個坑

• standby 支援多上遊節點, 優先從從庫接收wal, 主從切換不影響下遊的隻讀執行個體. (開源版本有一部分機率上遊節點發生HA切換後可能需要重新搭建隻讀庫)
• 拓撲感覺, 可以在多個從庫之間自動轉發wal, 確定wal平衡後再切換. 可以確定整個叢集在發生故障時可以應用更多的wal、避免出現分叉. 《DB吐槽大會,第72期 - PG wal 聯網協定不夠發達》