【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开源版本.