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>.回复报警邮件;

备注:

     突发事情的解决过程中,无关同事不得围观,需要配合的同事要迅速提供帮助和协调起来,对突发事情解决无帮助的主管及以上级别的人员,一律不得围观,否则以罚款方式处理。

©️2020 CSDN 皮肤主题: 大白 设计师:CSDN官方博客 返回首页