【DB吐槽大會】第25期 - PG 不支援實體Partial Standby

背景

1、産品的問題點

• PG 不支援實體Partial Standby

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

• PG 通過全量資料+wal日志增量回放可以建立近乎實時的實體從庫, 但是主庫和從庫的資料檔案必須一緻, 暫時不支援建立隻有部分資料的standby

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

• 集團或中心+子節點的組織架構類業務, 例如全國庫(最大), 省份庫(其次), 地市庫(最小).
• 将單一資料庫拆分成多個資料庫
• 将多個資料庫合并成1個大執行個體

4、會導緻什麼問題?

• 不支援parital standby, 那麼就隻能建立完整的從庫, 可能無法滿足權限訴求, 例如不同的省份應該同步不同的資料.
• 即使隻需要部分資料, 但是也需要建立整個執行個體的從庫, 需要耗費更多的存儲空間.

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

• 使用邏輯複制代替實體複制, 邏輯複制可以做到表甚至tuple級别
• 使用外部插件或軟體walbouncer

• • 不活躍,也沒有驗證過

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

• 邏輯複制有前置依賴, 需要PK或UK.
• 邏輯複制的效率低于實體流複制(由于邏輯複制需要在事務結束後才能解析WAL, 對于大事務延遲更高.)

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

• 期待核心層支援實體standby的partial, 以及單個standby能接收多上遊的wal合并成大庫.

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