《MySQL生产环境突发故障处理手册》由会员分享，可在线阅读，更多相关《MySQL生产环境突发故障处理手册（3页珍藏版）》请在金锄头文库上搜索。
1、MySQL 生产环境突发故障处理手册1. LOAD 飙高一般导致 MySQL 服务器 LOAD 突然飙高，可能的五种情况：1.全表扫描的 SQL 语句；2.SELECT 操作语句的执行计划走错；3.存在 UPDATE/DELETE 语句没有索引可选择，而导致堵塞其他 SQL 语句的执行；4.存在修改表结构或 OPTIMIZE 语句执行；5.大数据量的导入 或 导出，尤其数据库的逻辑备份操作；6.业务量大到超过服务器处理能力（我们大家都高度关注业务发展，以及公司业务特点，还有与开发和运营保持良好联系，很难出现未知的业务突然爆发性增长） ；要解决 LOAD 飙高，必须先找到造成飙高的真实原因，请登
2、陆数据库服务器后，执行命令：SHOW PROCESSLIST;（适合 MySQL 各种版本）或SELECT * FROM INFORMATION_SCHEMA.PROCESSLIST WHERE COMMAND 100;（5.1.x 系列及以上版本）若一直处在执行状态，且执行时间比较久，可以分析下 SQL 语句执行计划：EXPLAIN SQL-statement;若执行计划不合理，则可以根据 SQL 类型选择是否与应用负责人联系。首先，查找造成服务器 LOAD 飙高的 PID，特别是 DELETE 或 UPDATE 等会堵住其他 SQL 语句的 PID，然后进入 MySQL 命令行工具中，对一
3、些 SQL 先记录下来，再适情考虑执行：kill sql_pid;1.1 统计信息更新单表索引统计信息查看命令：SHOW INDEXES FROM tablename;若发现其统计信息存在偏差，则可以执行：ANALYZE LOCAL TABLE tablename;备注：请加上 LOCAL 参数，从而使此语句执行时不需要登记到二进制文件中。1.2 碎片整理和统计信息更新OPTIMIZE 操作等于 recreate + analyze 的组合操作，所以会堵塞更新类型 SQL 语句。对于备机上跑只读类型操作的业务，可以考虑使用此操作命令，对于主服务器不建议使用此命令，为此备机上执行 OPTIMIZ
4、E 语句，必须这样写：OPTIMIZE LOCAL TABLE tablename;备注：这样执行将不会记录到二进制日志文件中，从而不会复制到对其有复制关系的主机上。2. HA 切换2.1 启动备机 Heartbeat若要启动备机上的 Heartbeat 进程，则必须先保证备机上的 mysqld 服务已经停止掉，然后再启动备机上的 Heartbeat 服务，最后再启动 mysqld 服务。2.2 VIP 服务快速漂移直接关闭掉 VIP 所挂载的主服务器上的 Heartbeat 服务：service heartbeat stop，待切换之前的备机 VIP 服务挂载成功，再启动被关掉机器的 Hea
5、rtbeat 服务，且确保 mysqld 服务已经处于停止状态，最后再启动 mysqld 服务。另外一种强制 VIP 飘移办法：crm_resource -M -r resource_name -H nodename其中： resource_name 可以通过命令 crm_resource L进行强制 VIP 漂移后，还需要检查 failcount 值，命令与设置值，如下：crm_failcount U nodename -r resource_name G如果 failcount 大于 0，则进行下面的操作：crm_resource -r resource_name -p is_manage
6、d -v false （设置资源为非受控）crm_failcount -U nodename -r resource_name -G D （重新设置 failcount 值)crm_resource -H nodename -r resource_name Ccrm_resource -r resource_name -d is_managed (设置为受控）3.复制中断复制突然中断的可能原因：1. 备机无法连接到主服务器，可能是网络问题，也可能是主服务器的 mysqld 已停止；2. 主键冲突；3. 主从服务器数据不一致；4. 其他原因；为使复制继续，我们可以进行如下处理：1. Stop s
7、lave ;2 start slave;3 检查服务是否正常：show slave statusG若是主健冲突或数据不一致的情况，则需要额外处理：1.stop slave;2 start slave;3 show slave statusG 记录错误的信息，一般会有详细的 SQL 保存起来4 stop slave;5 SET GLOBAL sql_slave_skip_counter=1;6 start slave ;7 show slave statusG8 检查复制是否恢复正常，若没有循环 17步骤（备注：有些场景，也可以考虑借助脚本循环的方式解决）4.MySQL 假死4.1 假死状态判断
8、MySQL 假死状态一般只会响应对内存表、服务器状态和变量的操作，而且 SHOW PROCESSLIST;可以看到很多连接线程处于命令解析或处理的各种状态，且 SQL 语句执行时间较长。此时，为校验是否真处于 MysQL 假死状态，那么可以到库 test 中任意执行创建表或更新数据的语句，若回车键后没有响应，则一般可以断定 MySQL 是否已经处于假死状态。4.2 假死状态处理若使用 Heartbeat + Dual Master 的数据库架构，VIP 所在的数据库服务器出现假死状态，则应该直接关闭 service heartbeat stop，从而迫使 VIP 服务转移到另外一台数据库服务器
9、上。其次，根据处理 MySQL 假死状态的经验，使用 mysqladmin uroot p shutdown 命令关闭 mysqld 服务也是无法处理的，最快的办法是直接 Kill 进程：ps -ef | grep mysql | grep -v grep | awk print $2 | xargs kill -9然后，把 Heartbeat 启动成功之后，再启动 mysqld 服务；对于没有 Heartbeat 服务的数据库服务器，则直接启动 mysqld 服务即可。5.紧急事件处理的流程1.突发紧急事情：首先，要保持头脑清醒，心态要放平，建议先深呼吸；其次，仔细检查相关状态、日志等信息，
10、并且保存现场的状态信息，以便后续分析；最后，确认解决此问题的可行方案，以及判断此方案是否会引入新风险，是否需要其他同事协助；2.处理步骤复杂或命令语句多的情况，必须先把相关命令，分步骤在文档中写好；3.突发紧急事情的处理，会影响到前端应用服务的事情，应先跟团队领导沟通和确认处理方法，以及影响范围有多大，影响程度有多严重；4.确定紧急处理过程或完毕后，需要那些应用方负责人检查应用是否正常，则应该先联系相关同事；5.处理完毕且业务正常之后，优先分析问题和查找是否还有隐患；6.发邮件描述整个故障发生、影响范围和程度 、处理过程，以及补填写紧急处理的 ITIL 流程单；7.回复报警邮件；备注：突发事情的解决过程中，无关同事不得围观，需要配合的同事要迅速提供帮助和协调起来，对突发事情解决无帮助的主管及以上级别的人员，一律不得围观，否则以罚款方式处理。【编注】突然发现邮箱中竟然还有一份 2 年前写的东西，应该不是最新的版本，稍作整理分享出来，虽然内容不太丰富，也许对一些技术朋友有借鉴意义，大家也可以互相交换下意见和提供行业案例而逐渐把此主题相关的内容丰富起来。
