【DB吐槽大會】第66期 - PG 缺乏更簡單的資料熱插拔能力

背景

1、産品的問題點

• PG 缺乏更簡單的資料熱插拔能力

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

• 當談到遷移資料時, 往往想到的是

• • 停業務, 邏輯的導出、導入
  • 邏輯增量遷移
  • 全量, 流複制遷移

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

• SaaS場景, 租戶級的遷移、rebalance、PITR備份、PITR恢複
• 企業内部, 業務級别的資料遷移、rebalance、PITR備份、PITR恢複
• 使用生産環境快速建構測試環境, 而且一個執行個體包括多個業務時, 采用standby克隆的話不相幹的資料也要被同步

關聯吐槽：

• 《DB吐槽大會,第25期 - PG 不支援實體Partial Standby》
• 《DB吐槽大會,第24期 - PG 不支援Partial PITR》

4、會導緻什麼問題?

• 停業務, 邏輯的導出、導入.

• • 影響業務, 停業務的時間取決于資料量大小.

• • 有前置依賴, 而且有一定的場景無法滿足. 後面提到

• • 不适合partial(表、schema、database級)的備份、遷移.

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

• 為了滿足這些業務場景, 目前可以使用logical replication

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

• 前置依賴: 表必須有PK或UK
• 不支援DDL, sequence變化
• wal_level=logical, 如果要修改的話, 需要重新開機執行個體
• 增加了配置複雜度
• 邏輯的增量同步性能不如實體的拷貝檔案, 并且實時性不如實體流複制(特别是在被同步的表發生了大事務時, 需要等上遊大事務結束才能同步到下遊.)

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

• 希望核心層面實體流複制支援partial的實體流複制、備份、恢複、遷移能力. 熱插拔資料的能力. 可以對标Oracle PDB .

• • 例如: PostgreSQL，每個DB有單獨的REDO，DB支援熱插拔。支援DB級的實體流複制。一個叢集的資料庫可以實體流複制的模式拷貝、增量傳輸到另一個叢集。 另一個叢集能打開這個DB進行隻讀操作, 能夠激活這個DB進行讀寫操作.
  • 支援transfer table、transfer schema特性, 能夠支援實體級别的增量遷移、備份table、schema.

• 在存儲計算分離架構中, 能支援解除安裝、挂載table、schema、database的資料檔案的能力. 一份存儲可以給a執行個體挂載、也可以給b執行個體挂載, 隻要他們不同時挂載, 大幅度提高rebalance、遷移等場景的效率.
• 《PostgreSQL 部分資料庫複制、wal代理、wal過濾器 插件 walbouncer》
• 《PostgreSQL 表傳輸功能 - pg_transport pgtransfer》

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