故障趋势分析,系统故障怎么恢复

作者：xuty
本文来源：原创投稿
*爱可生开源社区出品，原创内容未经授权不得随意使用，转载请联系小编并注明来源。一、现象有个 MySQL 5.7 开发库异常挂掉后，奔溃恢复一直处于如下位置，且持续了 2 小时左右才起来。非常疑惑这段时间 MySQL 到底做了什么事情？居然需要这么长时间。
虽说这里虚拟机的 IOPS 并不是很高，但也绝对不需要这么久吧？而且从日志输出来看，这块应该也不是在做真正的数据恢复，那么也可以排除是大事务回滚导致的耗时长，那么原因到底是啥呢？

作者：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 置为 1。只有当 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/?id=7142http://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

浏览器一直崩溃，无响应，无法打开是什么原因？

浏览器页面崩溃的原因和解决方法：
1、右键IE浏览器图标，选择“以管理员身份运行”;
2、运行之后找到右上角的“工具”点击“Internet选项”;
3、进入“Internet属性”切到“高级”，下拉至“启动内存保护帮助减少联机攻击”，前面的小框框不要打勾;在拉至“启用自动崩溃恢复”，同样取消打勾;点击确定即可。
补充：浏览器常见问题分析
1.IE浏览器首次开机响应速度慢，需要数秒。搞定办法：IE下选择工具-internet选项-连接-局域网设置-取消自动检测。
2. IE9图片显示不正常或干脆不显示，尤其是QQ空间搞定办法：工具-internet选项-高级-加速图形-运用软件而非GPU 选择。
3. 打开网页显示 【Internet Explorer 已不再尝试还原此网站。该网站看上去仍有问题。 您可以执行以下操作:转到首页】搞定方案：工具-internet选项-高级中关闭 【启用崩溃自动恢复】 重新启动ie后即开。
4. 下载完所需安全控件也无法运用各种网银，付款时识别不出u盾搞定方案：据提示下载银行安全控件并安装。插上u盾，拿建行为例：在开始菜单里-所有程序-中国建设银行E路护航网银安全组件-网银盾管理工具 打开后点击你的u盾并注册。然后重新启动浏览器一定要完全退出再进 进入付款网页 上方会显示 是否允许加载项，选择 在所有站点允许。这时候可能还需要再次重新启动浏览器进入付款页面 这时候你期待的u盾密码输入框会出现。 这样就ok了
5. 打开网页一直刷新-失败-刷新，无限循环搞定办法：工具-internet选项-高级-禁用脚本调试。
6. IE 习惯性停止工作或崩溃。搞定办法：工具-管理加载项，一一禁用排除以找到某个插件的问题。由于情况多种多样，有些时候找不到具体原因，我们可以通过重置来搞定工具-internet选项-高级。

电脑系统总是崩溃

1．机箱电源功率不足、直流输出不纯、动态反应迟钝。
用户或装机商往往不重视电源，采用价格便宜的电源，因此是引起系统自动重启的最大嫌疑之一。
①电源输出功率不足，当运行大型的3D游戏等占用CPU资源较大的软件时，CPU需要大功率供电时，电源功率不够而超载引起电源保护，停止输出。电源停止输出后，负载减轻，此时电源再次启动。由于保护/恢复的时间很短，所以给我们的表现就是主机自动重启。
②电源直流输出不纯，数字电路要求纯直流供电，当电源的直流输出中谐波含量过大，就会导致数字电路工作出错，表现是经常性的死机或重启。
③CPU的工作负载是动态的，对电流的要求也是动态的，而且要求动态反应速度迅速。有些品质差的电源动态反应时间长，也会导致经常性的死机或重启。
④更新设备（高端显卡/大硬盘/视频卡），增加设备（刻录机/硬盘）后，功率超出原配电源的额定输出功率，就会导致经常性的死机或重启。
解决方法：现换高质量大功率计算机电源。
2．内存热稳定性不良、芯片损坏或者设置错误
内存出现问题导致系统重启致系统重启的几率相对较大。
①内存热稳定性不良，开机可以正常工作，当内存温度升高到一定温度，就不能正常工作，导致死机或重启。
②内存芯片轻微损坏时，开机可以通过自检（设置快速启动不全面检测内存），也可以进入正常的桌面进行正常操作，当运行一些I/O吞吐量大的软件（媒体播放、游戏、平面/3D绘图）时就会重启或死机。
解决办法：更换内存。
③把内存的CAS值设置得太小也会导致内存不稳定，造成系统自动重启。一般最好采用BIOS的缺省设置，不要自己改动。
3．CPU的温度过高或者缓存损坏
①CPU温度过高常常会引起保护性自动重启。温度过高的原因基本是由于机箱、CPU散热不良，CPU散热不良的原因有：散热器的材质导热率低，散热器与CPU接触面之间有异物（多为质保帖），风扇转速低，风扇和散热器积尘太多等等。还有P2/P3主板CPU下面的测温探头损坏或P4 CPU内部的测温电路损坏，主板上的BIOS有BUG在某一特殊条件下测温不准，CMOS中设置的CPU保护温度过低等等也会引起保护性重启。
②CPU内部的一、二级缓存损坏是CPU常见的故障。损坏程度轻的，还是可以启动，可以进入正常的桌面进行正常操作，当运行一些I/O吞吐量大的软件（媒体播放、游戏、平面/3D绘图）时就会重启或死机。
解决办法：在CMOS中屏蔽二级缓存（L2）或一级缓存（L1），或更换CPU排除。
4．AGP显卡、PCI卡（网卡、猫）引起的自动重启
①外接卡做工不标准或品质不良，引发AGP/PCI总线的RESET信号误动作导致系统重启。
②还有显卡、网卡松动引起系统重启的事例。
5. 并口、串口、USB接口接入有故障或不兼容的外部设备时自动重启]
①外设有故障或不兼容，比如打印机的并口损坏，某一脚对地短路，USB设备损坏对地短路，针脚定义、信号电平不兼容等等。
②热插拔外部设备时，抖动过大，引起信号或电源瞬间短路。
6．光驱内部电路或芯片损坏
光驱损坏，大部分表现是不能读盘/刻盘。也有因为内部电路或芯片损坏导致主机在工作过程中突然重启。光驱本身的设计不良，FireWare有Bug。也会在读取光盘时引起重启。
7．机箱前面板RESET开关问题
机箱前面板RESET键实际是一个常开开关，主板上的RESET信号是+5V电平信号，连接到RESET开关。当开关闭合的瞬间，+5V电平对地导通，信号电平降为0V，触发系统复位重启，RESET开关回到常开位置，此时RESET信号恢复到+5V电平。如果RESET键损坏，开关始终处于闭合位置，RESET信号一直是0V，系统就无法加电自检。当RESET开关弹性减弱，按钮按下去不易弹起时，就会出现开关稍有振动就易于闭合。从而导致系统复位重启。
解决办法：更换RESET开关。
还有机箱内的RESET开关引线短路，导致主机自动重启。
8. 主板故障
主板导致自动重启的事例很少见。一般是与RESET相关的电路有故障；插座、插槽有虚焊，接触不良；个别芯片、电容等元件损害。
三、其他原因
1．市电电压不稳
①计算机的开关电源工作电压范围一般为170V－240V，当市电电压低于170V时，计算机就会自动重启或关机。
解决方法：加稳压器（不是UPS）或130－260V的宽幅开关电源。
②电脑和空调、冰箱等大功耗电器共用一个插线板的话，在这些电器启动的时候，供给电脑的电压就会受到很大的影响，往往就表现为系统重启。
解决办法就是把他们的供电线路分开。
2．强磁干扰
不要小看电磁干扰，许多时候我们的电脑死机和重启也是因为干扰造成的，这些干扰既有来自机箱内部CPU风扇、机箱风扇、显卡风扇、显卡、主板、硬盘的干扰，也有来自外部的动力线，变频空调甚至汽车等大型设备的干扰。如果我们主机的搞干扰性能差或屏蔽不良，就会出现主机意外重启或频繁死机的现象。
3、交流供电线路接错
有的用户把供电线的零线直接接地（不走电度表的零线），导致自动重启，原因是从地线引入干扰信号。
4．插排或电源插座的质量差，接触不良。
电源插座在使用一段时间后，簧片的弹性慢慢丧失，导致插头和簧片之间接触不良、电阻不断变化，电流随之起伏，系统自然会很不稳定，一旦电流达不到系统运行的最低要求，电脑就重启了。解决办法，购买质量过关的好插座。
5. 积尘太多导致主板RESET线路短路引起自动重启。