【DB吐槽大】第72期 - PG wal 聯網協定不夠發達

背景

1、産品的問題點

• PG wal 聯網協定不夠發達

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

• 一個PG 叢集有主執行個體、通過wal流複制建立的一個或多個從執行個體、從執行個體還可以集聯形成多級從庫.
• 叢集拓撲是有根節點的樹狀資料流結構.
• 從節點的需要用于replay的WAL資料可以從哪裡索取呢?

• • 配置好的上遊節點, 上遊從pg_wal目錄讀出來, 發送給下遊
  • 自己的pg_wal目錄中查找
  • 使用restore_command擷取已歸檔的檔案, 這個指令配置在自己的節點中, 通過shell指令擷取. 傳入參數中最重要的是所需的wal檔案名.

• 在這個叢集中, 不同的節點可能部署在不同的主機上, 用于存儲WAL的歸檔的裝置, 可能隻能被某些節點通路(通常歸檔由主節點産生, 并copy到歸檔裝置中).

• • 對于已歸檔的wal檔案, 并且是最近一個已完成的檢查點之前的, 并且不在wal_keep_size保護範圍内, 這樣的wal檔案可能被删除. 然而下遊節點可能因為各種原因還沒有及時接收到這樣的WAL檔案. 那下遊節點怎麼辦? 隻能使用restore_command擷取已歸檔的檔案, 但是前面說了, 可能隻有主節點有歸檔目錄的權限, 怎麼辦? 重建從庫?
  • 核心問題是什麼? 上遊節點不能代替下遊節點使用restore_command, 然後再将wal發送給下遊節點.

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

• 主從、流複制從庫通用問題

4、會導緻什麼問題?

• 如果上遊節點wal已被清楚, 而且下遊節點沒有權限擷取歸檔目錄中的wal檔案, 那麼将需要人工介入, 或者重建從庫.

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

• 人工介入, 拷貝已清理的wal檔案
• 共享wal歸檔, 使用restore_command從歸檔檔案中擷取已從pg_wal目錄清理的wal檔案.

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

• 複雜度增加

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

• 希望核心層面可以支援peer 節點之間、上遊與下遊之間能夠通過流複制協定互相發送wal檔案.
• 上遊可以通過restore_command擷取已清理的wal檔案并發送給下遊.
• 如果是叢集拓撲的其他平級節點或分叉節點來發, 可以通過peer限制判定wal檔案的正确性.

• • system_id 相同, 表示這是同一個叢集
  • timeline + LSN 比對, 表示這是我需要的wal内容.

• 擴充訴求: 實際上叢集拓撲的監控等資訊都可以更強的關聯. 實作更有叢集意義的dashboard, 甚至與client driver進行關聯, 實作更無縫的HA, 負載均衡等.