gdb 优化mysql_故障分析 | 崩溃恢复巨慢原因分析

最新推荐文章于 2024-04-26 15:08:18 发布

岳怀之缘小向

最新推荐文章于 2024-04-26 15:08:18 发布

阅读量198

点赞数

文章标签： gdb 优化mysql

本文链接：https://blog.csdn.net/weixin_35719518/article/details/113565993

版权

本文分析了MySQL 5.7在崩溃恢复时耗时较长的现象，发现原因是MySQL在恢复过程中会遍历校验所有表空间文件。通过GDB调试和源码分析，揭示了validate参数在正常启动和崩溃恢复中的不同行为，以及如何通过调整innodb_force_recovery参数或使用共享表空间来避免长时间校验。测试验证表明，表数量和磁盘IOPS都会影响崩溃恢复时间。

摘要由CSDN通过智能技术生成

作者：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 Commu