故障分析 | 崩溃恢复巨慢原因分析

作者：xuty
本文来源：原创投稿
*爱可生开源社区出品，原创内容未经授权不得随意使用，转载请联系小编并注明来源。

一、现象

有个 MySQL 5.7开发库异常挂掉后，奔溃恢复一直处于如下位置，且持续了 2 小时左右才起来。非常疑惑这段时间 MySQL 到底做了什么事情？居然需要这么长时间。
虽说这里虚拟机的 IOPS 并不是很高，但也绝对不需要这么久吧？而且从日志输出来看，这块应该也不是在做真正的数据恢复，那么也可以排除是大事务回滚导致的耗时长，那么原因到底是啥呢？
值得注意的是，这台开发库上面有将近 1500 个库和上万张表，难道 MySQL 崩溃恢复时长 和 表的数量 也存在一定关系嘛？

二、分析栈帧

在 MySQL 崩溃恢复时，用 pstack 打了栈帧，再用 pt-pmp 工具分析栈帧后显示如下：

pread64(libpthread.so.0),os_file_io(os0file.cc:5435),
os_file_pread(os0file.cc:5612),os_file_read_page(os0file.cc:5612),
os_file_read_no_error_handling_func(os0file.cc:6069),
pfs_os_file_read_no_error_handling_func(os0file.ic:341),
Datafile::read_first_page(os0file.ic:341),Datafile::validate_first_page(fsp0file.cc:551),
Datafile::validate_to_dd(fsp0file.cc:404),fil_ibd_open(fil0fil.cc:3969),
dict_check_sys_tables(dict0load.cc:1465),dict_check_tablespaces_and_store_max_id(dict0load.cc:1525),
innobase_start_or_create_for_mysql(srv0start.cc:2329),innobase_init(ha_innodb.cc:4048),
ha_initialize_handlerton(handler.cc:838),plugin_initialize(sql_plugin.cc:1197),
plugin_init(sql_plugin.cc:1538),init_server_components(mysqld.cc:4033),
mysqld_main(mysqld.cc:4673),__libc_start_main(libc.so.6),_start

根据函数名字，感觉像是在 遍历校验每个表空间文件的有效性?，难道 MySQL 崩溃恢复时会额外进行校验操作？貌似和表数量扯上点关系了。

三、GDB 调试

Server version: 5.7.26-log MySQL Community Server (GPL)

直接去分析源码感觉有点找不到切入点，因为不知道正常启动是不是也是这样的函数调用。

为了知道 正常启动 与 崩溃恢复 的区别，先在本地的 MySQL 5.7.26 环境中用 GDB 调试 MySQL 启动过程，看下正常启动和崩溃恢复的函数调用有哪些区别，再针对性的去分析源码比较好。

-- 将之前的栈帧弄成了树状，便于分析
>innobase_init
| >innobase_start_or_create_for_mysql
| | >dict_check_tablespaces_and_store_max_id
| | | >dict_check_sys_tables
| | | | >fil_ibd_open
| | | | | >Datafile::validate_to_dd
| | | | | | >Datafile::validate_first_page
| | | | | | | >Datafile::read_first_page
| | | | | | | | >pfs_os_file_read_no_error_handling_func
| | | | | | | | | >os_file_read_no_error_handling_func
| | | | | | | | | | >os_file_read_page
| | | | | | | | | | | >os_file_pread
| | | | | | | | | | | | >os_file_io

正常启动 GDB 调试结果：

从上到下，每次打一个断点函数，发现到 Datafile::validate_to_dd 这个函数时，MySQL 正常启动就不会执行，看样子是 fil_ibd_open 函数中做了某些判断。

崩溃恢复GDB调试结果：

一边用sysbench压，一边直接kill -9进程就可以模拟崩溃恢复，同样从上到下，依次打断点函数，发现会走到Datafile::validate_to_dd这个函数中，Continue后会一直断点在这个函数上，说明外层包装了一层循环会遍历所有表，如果继续增加断点函数的话，发现绝大部分表会继续走下去，直到os_file_io，而小部分表则不会继续走下去。

四、源码分析

4.1. fil_ibd_open

我们先去 fil_ibd_open 函数中看下，进入 Datafile::validate_to_dd 函数的判断条件，发现主要和一个 validate 参数有关，如果为 false 则可以跳过检测，为 true 则需要进入 Datafile::validate_to_dd 函数。

4.2. innobase_start_or_create_for_mysql

然后我们需要看下 validate 参数的定义，分析崩溃恢复与正常启动的区别。

发现 validate参数 最早是在 innobase_start_or_create_for_mysql 函数中定义的，并且其注释已经解释的非常详细。

正常启动：直接为每张表的创建 space object 即可，不需要打开 ibd 文件的 header page 进行表空间校验。
崩溃恢复：为了数据字典的一致性，需要遍历打开所有 ibd 文件的 header page 进行表空间校验。

validate 这个参数表明当一个表空间被打开时，同时会去读取其ibd文件的头页（header page）来验证数据字典的一致性，而当数据库包含许多ibd文件时，这个过程就会比较久，所以只在崩溃恢复且非强制恢复时执行表空间校验操作！

4.3. recv_needed_recovery & srv_force_recovery

接着我们来看下决定 validate 值的 2 个参数：recv_needed_recovery 与 srv_force_recovery，默认崩溃恢复时，recv_needed_recovery = 1 而 srv_force_recovery = 0 ，所以 validate = true，即需要进行表空间校验。

bool validate = recv_needed_recovery && srv_force_recovery == 0;
//跳过表空间校验
validate = false
//执行表空间校验
validate = true

先看下 recv_needed_recovery 参数，默认为 0。MySQL 在启动时会比对 checkpoint_lsn 与 flush_lsn。如果不相等，就会调用 recv_init_crash_recovery 方法将 recv_needed_recovery 置为 1。只有当 MySQL 正常关闭时，这 2 个 lsn 才会相等。另外一个小发现，MySQL 5.7 中服务起来后，什么操作都不做，checkpoint_lsn 永远会落后 9，所以即使你什么都不做，直接 kill -9 进程，也算是崩溃重启。

LOG
---
Log sequence number 2563079308
Log flushed up to   2563079308
Pages flushed up to 2563079308
Last checkpoint at  2563079299

再来看下 srv_force_recovery 参数，默认值为 0，如果设置了 innodb_force_recovery ，那么 srv_force_recovery 的值就等于 innodb_force_recovery 的值，即只要配置了强制恢复，srv_force_recovery 就会大于 0。

4.4. dict_check_tablespaces_and_store_max_id

最后看下 dict_check_tablespaces_and_store_max_id 函数，根据注释介绍，这个函数会检查所有在数据字典中发现的表空间，先检查每个共享表空间，然后检查每个独立表空间。

在 崩溃恢复 中，部分表空间已经在处理 redolog 时被打开（对应之前 GDB 调试时部分表未继续走下去），而其他没有被打开的表空间，将会通过比较数据字典中的 space_id 与表空间文件是否一致的方式进行验证（也就是之前所说的 表空间校验过程）。

五、测试验证

到这里，原理大概已经知道了，主要就是：MySQL 在崩溃恢复时，会遍历打开所有 ibd 文件的 header page 验证数据字典的准确性，如果 MySQL 中包含了大量表，这个校验过程就会比较耗时。

那么我们可以模拟下这个场景，进一步验证，比如在 测试库 中用 sysbench 建 50W 张空表，然后模拟非正常关闭，对比下崩溃恢复时长。

MySQL实例	表总数	磁盘类型	启动类型	时长
开发库(5.7.20)	57w	HDD	崩溃恢复	2小时左右
测试库(5.7.26)	空库	SSD	崩溃恢复	秒级
测试库(5.7.26)	50w	SSD	正常启动	40秒左右
测试库(5.7.26)	50w	SSD	崩溃恢复	7分钟左右
测试库(8.0.18)	50w	SSD	正常启动	4分钟左右
测试库(8.0.18)	50w	SSD	崩溃恢复	10分钟左右

可以看到 MySQL 下崩溃恢复确实和表数量有关，表总数越大，崩溃恢复时间越长。另外磁盘 IOPS 也会影响崩溃恢复时间，像这里开发库的 HDD IOPS 较低，因此面对大量的表空间，校验速度就非常缓慢。

另外一个发现，MySQL 8 下正常启用时居然也会进行表空间校验，而故障恢复时则会额外再进行一次表空间校验，等于校验了 2 遍。不过 MySQL 8.0 里多了一个特性，即表数量超过 5W 时，会启用多线程扫描，加快表空间校验过程。

MySQL 8.0.21 开始可以通过 innodb_validate_tablespace_paths 参数关闭正常启动时的表空间校验过程。

六、如何跳过校验

MySQL 5.7 下有方法可以跳过崩溃恢复时的表空间校验过程嘛？查阅了资料，方法主要有两种：

配置 innodb_force_recovery

可以使 srv_force_recovery != 0 ，那么 validate = false，即可以跳过表空间校验。实际测试的时候设置 innodb_force_recovery =1 ，也就是强制恢复跳过坏页，就可以跳过校验，然后重启就是正常启动了。通过这种临时方式可以避免崩溃恢复后非常耗时的表空间校验过程，快速启动 MySQL，个人目前暂时未发现有什么隐患。
使用共享表空间替代独立表空间

这样就不需要打开 N 个 ibd 文件了，只需要打开一个 ibdata 文件即可，大大节省了校验时间。自从听了姜老师讲过使用共享表空间替代独立表空间解决 drop 大表时性能抖动的原理后，感觉共享表空间在很多业务环境下，反而更有优势。
```
 bool validate = recv_needed_recovery && srv_force_recovery == 0;
 //跳过表空间校验
 validate = false
 //执行表空间校验
 validate = true
```

临时冒出另外一种解决想法，即用 GDB 调试崩溃恢复，通过临时修改 validate 变量值让 MySQL 跳过表空间验证过程，然后让 MySQL 正常关闭，重新启动就可以正常启动了。

但是实际测试发现，如果以 debug 模式运行，确实可以临时修改 validate 变量，跳过表空间验证过程，但是 debug 模式下代码运行效率大打折扣，反而耗时更长。而以非 debug 模式运行，则无法修改 validate 变量，想法破灭。

附录：

https://dev.mysql.com/worklog/task/?id=7142
http://blog.symedia.pl/2015/11/mysql-56-and-57-crash-recovery.html
https://www.percona.com/community-blog/2019/07/23/impact-of-innodb_file_per_table-option-on-crash-recovery-time/
https://jira.mariadb.org/browse/MDEV-18733