作者
digoal
日期
2021-09-15
标签
PostgreSQL , 崩溃恢复
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
PostgreSQL 许愿链接
您的愿望将传达给PG kernel hacker、数据库厂商等, 帮助提高数据库产品质量和功能, 说不定下一个PG版本就有您提出的功能点. 针对非常好的提议，奖励限量版PG文化衫、纪念品、贴纸、PG热门书籍等，奖品丰富，快来许愿。开不开森.
9.9元购买3个月阿里云RDS PostgreSQL实例
PostgreSQL 解决方案集合
德哥 / digoal's github - 公益是一辈子的事.
