digoal
2021-08-30
PostgreSQL , 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开源版本.
您的愿望将传达给PG kernel hacker、数据库厂商等, 帮助提高数据库产品质量和功能, 说不定下一个PG版本就有您提出的功能点. 针对非常好的提议，奖励限量版PG文化衫、纪念品、贴纸、PG热门书籍等，奖品丰富，快来许愿。开不开森.
