【DB吐槽大會】第47期 - PG 崩潰恢複能快點嗎

背景

1、産品的問題點

• PG 崩潰恢複能快點嗎

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

• 資料庫程序被KILL -9、OOM、資料庫強制非正常停庫、或者作業系統、存儲或其他故障導緻資料庫非正常停庫時, 資料庫再次啟動需要進行恢複.
• 恢複需要用到從上一個完成的檢查點的邏輯開始位點處的WAL日志 - 到最新的WAL日志檔案之間的所有WAL檔案.

• • 需要多少個wal檔案取決于檢查點的長短, 通常記憶體很大的機器, 會設定較大的shared buffer, 同時設定較長的checkpoint周期來優化資料庫寫性能.

• 恢複過程中被恢複的資料塊包含full page時, 隻需要從wal拿對應full page+wal增量record進行恢複, 但是恢複過程中資料塊可能從shared buffer擠出, 那麼就需要從datafile讀取對應塊然後+wal record恢複.

• • 這可能是非常耗費IO的操作

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

• 所有行業, 特别是規格大的執行個體

4、會導緻什麼問題?

• IO如果較差的話, 崩潰恢複速度慢.
• 特别是在業務高峰期, 如果出現OOM的話, 崩潰恢複時間長對業務造成的影響巨大

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

• 使用standby, 如主庫崩潰, 激活從庫.
• 不管是資料檔案還是wal檔案都使用性能好(IOPS 以及 吞吐、RT)的SSD
• 縮短checkpoint周期, 讓一個周期内的wal檔案盡量的少

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

• 使用HA架構會增加風險和複雜度, 例如雙節點的異步HA, 可能丢資料風險. 三節點的同步HA, 成本高, 複雜度高.
• 使用很好的SSD, 增加了成本
• 提高checkpoint頻率, 會損耗寫性能. 并且會導緻full page增加, 使得産生更多的wal檔案

• • 《PolarDB 為什麼要解決FPW的性能問題?》
  • 《DB吐槽大會,第11期 - FPW | Double Write》

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

• 希望核心層面支援更友好的恢複功能

• • 并行的恢複, 提高恢複速度. 目前PolarDB支援并行wal回放
  • 例如可以支援立即開放隻讀功能, 恢複過程允許隻讀操作，自動過濾不一緻資料塊，或自動使用舊快照

• • • polardb pg共享存儲版本支援lazy恢複模式, 幾乎可以毫秒級恢複.
    • https://github.com/alibaba/PolarDB-for-PostgreSQL