背景
1、产品的问题点
2、问题点背后涉及的技术原理
- 数据库进程被KILL -9、OOM、数据库强制非正常停库、或者操作系统、存储或其他故障导致数据库非正常停库时, 数据库再次启动需要进行恢复.
- 恢复需要用到从上一个完成的检查点的逻辑开始位点处的WAL日志 - 到最新的WAL日志文件之间的所有WAL文件.
- 需要多少个wal文件取决于检查点的长短, 通常内存很大的机器, 会设置较大的shared buffer, 同时设置较长的checkpoint周期来优化数据库写性能.
- 恢复过程中被恢复的数据块包含full page时, 只需要从wal拿对应full page+wal增量record进行恢复, 但是恢复过程中数据块可能从shared buffer挤出, 那么就需要从datafile读取对应块然后+wal record恢复.
3、这个问题将影响哪些行业以及业务场景
4、会导致什么问题?
- IO如果较差的话, 崩溃恢复速度慢.
- 特别是在业务高峰期, 如果出现OOM的话, 崩溃恢复时间长对业务造成的影响巨大
5、业务上应该如何避免这个坑
- 使用standby, 如主库崩溃, 激活从库.
- 不管是数据文件还是wal文件都使用性能好(IOPS 以及 吞吐、RT)的SSD
- 缩短checkpoint周期, 让一个周期内的wal文件尽量的少
6、业务上避免这个坑牺牲了什么, 会引入什么新的问题
- 使用HA架构会增加风险和复杂度, 例如双节点的异步HA, 可能丢数据风险. 三节点的同步HA, 成本高, 复杂度高.
- 使用很好的SSD, 增加了成本
- 提高checkpoint频率, 会损耗写性能. 并且会导致full page增加, 使得产生更多的wal文件
7、数据库未来产品迭代如何修复这个坑
- 并行的恢复, 提高恢复速度. 目前PolarDB支持并行wal回放
- 例如可以支持立即开放只读功能, 恢复过程允许只读操作，自动过滤不一致数据块，或自动使用旧快照