当前位置:首页 >> 计算机硬件及网络 >>

MySQL生产环境突发故障处理手册


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


相关文章:
更多相关标签: