digoal
2021-08-30
PostgreSQL , FPW , Double Write
1、产品的问题点
- 在每一个检查点开始之后, 当PAGE第一次被修改时, 需要将整个PAGE写入WAL日志. 称之为full page write(fpw).
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的原子写, 从而可以安全的关闭fpw而不用担心prital write产生坏块. 某些ssd支持, 例如宝存.
6、业务上避免这个坑牺牲了什么, 会引入什么新的问题
- 拉长checkpoint周期实际上就是让周期内的WAL日志更多, 从而会导致数据库崩溃恢复的时间变长, 发生H A切换、standby重启后、或者发生oom原地恢复、等需要恢复的场景, 影响业务的时间变长.
- 使用copy on write的文件系统, 本质上时将问题转嫁给文件系统了. 并没有彻底解决问题.
- 文件系统对齐IO的较少, 特别是云盘的情况, 还需要同时支持大于或等于data block size的原子写, 管理成本增加(例如有些设备不匹配要求, 那就不能开, 使得HA、部署、扩容都需要考虑这些约束, 管理成本增加. ).
7、数据库未来产品迭代如何修复这个坑
- 数据库内核层支持: DIO, 并且硬件支持IO原子写对齐.
- 或者使用remote recovery技术(恢复时使用远程正常节点(如standby)的datablock代替当前节点的datablock来合并wal日志.). 例如polardb for pg开源版本. 关闭fpw后, 性能提升了30%. 参考文章: 《PolarDB 为什么要解决FPW的性能问题?》
您的愿望将传达给PG kernel hacker、数据库厂商等, 帮助提高数据库产品质量和功能, 说不定下一个PG版本就有您提出的功能点. 针对非常好的提议，奖励限量版PG文化衫、纪念品、贴纸、PG热门书籍等，奖品丰富，快来许愿。开不开森.
