【DB吐槽大會】第3期 - share nothing RO

背景

1、産品的問題點

• 每增加1個從庫或隻讀執行個體就需要增加一份資料拷貝
• 複制時需要傳輸所有主庫産生的WAL或邏輯增量日志

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

• 通過全量的資料檔案拷貝+邏輯或實體的增量複制建立從庫, 每一個從庫都是一份完整的拷貝.

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

• 讀壓力很大, 并且需要超過1個隻讀執行個體才能滿足讀請求訴求的業務. 例如偏重計算(業務邏輯放在資料庫中)的業務. 基于推薦算法的短視訊、社交、内容、電商等C端業務.
• 主庫使用了主從HA架構後, 依舊有隻讀執行個體訴求的場景. 這個幾乎是通用的, 所有業務都被命中.

4、會導緻什麼問題?

• 昂貴的隻讀執行個體, 不僅要計算資源, 還需要同樣的存儲資源.
• 每個隻讀執行個體都需要與主庫建立連接配接複制增量WAL或邏輯日志, 需要消耗主庫的網絡和IO資源, 隻能建立有限的隻讀執行個體個數.
• 隻讀執行個體可能恢複慢, 特别是mysql基于邏輯增量的架構, 事務結束後才能apply日志, 大事務對資料庫延遲影響較大.
• 主庫發生HA後, 如果新主庫的日志量偏少, 隻讀庫将無法成為新主庫的從庫, 需要重建, 導緻新一輪的全量資料拷貝. 影響業務.

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

• 建立很多隻讀執行個體的客戶, 成本問題無解
• 采用級聯模式複制, 減少每個節點的下遊節點個數.
• 邏輯複制慢的問題, 可以考慮PG的實體流複制, 延遲和事務大小無關
• 主庫發生HA後如果隻讀庫不能成為新主庫的從庫, 可以使用pg_rewind來避免需要拷貝全量資料.

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

• 級聯模式增加了管理成本, 跳數增加, 延遲增加. 還有上遊發生問題時, 整個級聯下遊全部受到影響.
• 實體流複制雖然延遲低, 但是apply可能與query本身産生沖突, 需要使用feedback來減少上遊vacuum鏟掉下遊以來的tuple, 但是又會帶來膨脹、vacuum無用功等增加cpu和io消耗的問題.
• pg_rewind增加了管理成本. 普通使用者不會用.

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

• Oracle RAC
• PolarDB

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