【DB吐槽大會】第60期 - PG 隻讀執行個體不支援寫操作

背景

1、産品的問題點

• PG 隻讀執行個體不支援寫操作

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

• PG 通過流複制支援實體的standby節點, standby節點通過接收主庫wal日志, 實時回放block增量, 實作同步.
• 由于PG主庫和從庫實體一緻, 是以這個standby節點是隻讀的, 不支援寫操作. 例如不支援建立臨時表, 不支援寫unlogged table. 不支援寫資料等.

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

• 分析業務場景

4、會導緻什麼問題?

• 分析業務通常計算量和IO的消耗量都很大, 是以一般會把分析邏輯放在standby庫執行, 但是分析邏輯通常比較複雜, 例如把邏輯封裝到函數中, 計算會有中間結果産生, 用中間結果再進行後續計算.
• 因為standby庫不支援寫操作(包括寫臨時表), 使得中間結果沒地方存放, 導緻業務不得不放棄使用standby進行帶中間結果的複雜邏輯分析.

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

• 不将計算邏輯放到函數中, 而是通過業務的SQL調用來完成, 并且将中間結果寫入到主庫, 主庫再同步到隻讀庫, 同步完再進行下一步操作
• 使用數組代替臨時表存儲中間結果.

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

• 中間結果資料寫入主庫, 再同步有幾個問題

• • 浪費主庫存儲資源
  • 浪費了3次傳輸中間結果的網絡資源(讀取、寫入、同步)
  • 同步有延遲, 使得整個分析過程變長

• 使用數組代替臨時表的方案也有問題, 每個數組有1GB上限, 而且邏輯變得更複雜, 不适合新手, 門檻較高.

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

• 希望隻讀執行個體能支援臨時表的定義和寫入, 可以考慮臨時表的定義不放在pg_catalog, 如果要放在pg_catalog也可以(這個可以在主庫操作, 同步到隻讀庫, 中繼資料定義的量還是比較小的, 不過還要考慮統計資訊等, 也會導緻上下不一緻, 可以考慮放棄stat或者使用本地化stat)
• 希望最終統計結果可以寫主庫(也就是說寫入操作自動路由到主庫操作, 不需要通過業務導一次. 例如fdw借口?)
• 《PostgreSQL readonly standby 隻讀庫如何寫資料? - DDL DML 操作透明傳輸到主庫》

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