建站软件有哪些功能,jquery 显示wordpress,软件架构,网上国网推广多少钱一个户作者#xff1a;xuty本文来源#xff1a;原创投稿*爱可生开源社区出品#xff0c;原创内容未经授权不得随意使用#xff0c;转载请联系小编并注明来源。一、现象有个 MySQL 5.7 开发库异常挂掉后#xff0c;奔溃恢复一直处于如下位置#xff0c;且持续了 2 小时左右才起来…作者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函数中定义的并且其注释已经解释的非常详细。1. 正常启动直接为每张表的创建 space object 即可不需要打开 ibd 文件的 header page 进行表空间校验。2. 崩溃恢复为了数据字典的一致性需要遍历打开所有 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置为。只有当 MySQL 正常关闭时这 2 个 lsn 才会相等。另外一个小发现MySQL 5.7 中服务起来后什么操作都不做checkpoint_lsn 永远会落后 9所以即使你什么都不做直接 kill -9 进程也算是崩溃重启。LOG---Log sequence number 2563079308Log flushed up to 2563079308Pages flushed up to 2563079308Last 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 下崩溃恢复确实和表数量有关表总数越大崩溃恢复时间越长。另外磁盘 IOPS 也会影响崩溃恢复时间像这里开发库的 HDD IOPS 较低因此面对大量的表空间校验速度就非常缓慢。另外一个发现MySQL 8 下正常启用时居然也会进行表空间校验而故障恢复时则会额外再进行一次表空间校验等于校验了 2 遍。不过 MySQL 8.0 里多了一个特性即表数量超过 5W 时会启用多线程扫描加快表空间校验过程。MySQL 8.0.21 开始可以通过innodb_validate_tablespace_paths参数关闭正常启动时的表空间校验过程。六、如何跳过校验MySQL 5.7 下有方法可以跳过崩溃恢复时的表空间校验过程嘛查阅了资料方法主要有两种1. 配置 innodb_force_recovery可以使 srv_force_recovery ! 0 那么 validate false即可以跳过表空间校验。实际测试的时候设置 innodb_force_recovery 1也就是强制恢复跳过坏页就可以跳过校验然后重启就是正常启动了。通过这种临时方式可以避免崩溃恢复后非常耗时的表空间校验过程快速启动 MySQL个人目前暂时未发现有什么隐患。2. 使用共享表空间替代独立表空间这样就不需要打开 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/?id7142http://blog.symedia.pl/2015/11/mysql-56-and-57-crash-recovery.htmlhttps://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
