【DB吐槽大會】第11期 - FPW | Double Write

背景

1、産品的問題點

• 檢查點後第一次發生修改的PAGE需要将整個PAGE寫入WAL日志.

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

• 資料檔案以block_size為機關組織存儲, 為了防止資料檔案出現block partial write, 例如一半頁面是舊的内容, 一半頁面是新的内容, 資料庫設計了fpw的功能來恢複異常的資料block.

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

• 更新較為頻繁、覆寫的更新資料分布散落在很廣泛的PAGE内容的業務. 例如活躍使用者較多的2C業務, 需要頻繁更新使用者狀态資訊.

4、會導緻什麼問題?

• wal日志增多, 耗費更多的歸檔存儲空間, 需要更多錢, 恢複時間也可能變長.
• 性能下降.

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

• 可以拉長checkpoint時間周期, 使得在一天内産生的fpw更少. 但是無法避免完全不寫入full page.
• 使用Copy on write的檔案系統, 例如btrfs, zfs, 避免出現data block 出現prital write.
• 檔案系統對齊IO, 同時支援大于或等于data block size的原子寫

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

• 拉長checkpoint周期實際上就是讓周期内的WAL日志更多, 進而會導緻資料庫崩潰恢複的時間變長, 發生H A切換、standby重新開機後、或者發生oom原地恢複、等需要恢複的場景, 影響業務的時間變長.
• 使用copy on write的檔案系統, 本質上時将問題轉嫁給檔案系統了. 并沒有徹底解決問題.
• 檔案系統對齊IO的較少, 特别是雲盤的情況, 還需要同時支援大于或等于data block size的原子寫, 管理成本增加.

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

• 核心層支援: DIO, 并且硬體支援IO原子寫對齊.
• 或者使用remote recovery, 例如polardb for pg開源版本.

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