Sysbench

作者：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 函数中做了某些判断。 ...