mysql常见故障汇总和处理
作者：互联网
性能故障
1. 数据库主机LOAD飙高
(1)一般情况下导致MySQL服务器LOAD突然飙高，可能的五种情况如下：
– 全表扫描的SQL语句；– SELECT操作语句的执行计划走错；– 存在UPDATE/DELETE 语句没有索引可选择，而导致堵塞其他SQL语句的执行；– 存在修改表结构或OPTIMIZE 语句执行；– 大数据量的导入或导出，尤其数据库的逻辑备份操作；– 业务量大到超过服务器处理能力（我们大家都高度关注业务发展，以及公司业务特点，– 还有与开发和运营保持良好联系，很难出现未知的业务突然爆发性增长）；
(2)要解决LOAD飙高，必须先找到造成飙高的真实原因，请登陆数据库服务器后，执行如下命令：
1 | SHOW PROCESSLIST; |
2 | 或 |
3 | SELECT * FROM INFORMATION_SCHEMA.PROCESSLIST WHERE COMMAND <> ‘sleep’ AND TIME>100; |
(3)若一直处在执行状态，且执行时间比较久，可以分析下SQL语句执行计划：
1 | mysql>EXPLAIN SQL语句 |
(4)检查io请求状态
使用Linux命令iostat查看r/s(读请求)，w/s(写请求)，avgrq-sz(平均请求大小),await(IO等待),，svctm(IO响应时间)，若执行计划不合理，则可以根据SQL类型选择是否与应用负责人联系。首先，查找造成服务器LOAD飙高的PID，特别是DELETE 或UPDATE等会堵住其他SQL语句的PID，然后进入MySQL命令行工具中，对一些SQL先记录下来，再适情考虑执行：KILL SQL PID
2. 请求处理波动，应用大量请求超时失败
(1)检查数据库的响应状态,使用tcprstat
1 | tcprstat -l $ip_addr -t $interval -n $count |
按照汇报结果，切分是否为数据库端问题还是非数据库端问题.
(2)分析关键指标
com_select/insert/update/deleteinnodb_rows_read/update/delete/insertinnodb_logicial_read/physical read
使用SHOW STATUS和 orzdba -com 可以获取采样指标
(3)转向分析slow query， 检查可疑SQL
1 | EXPLAIN SQL语句; |
如有长时间运行异常SQL, 可以Kill SQL PID.
(4)重点关注索引的使用问题
复制故障
1. 复制中断
(1)备机无法连接到主服务器，可能是网络问题，也可能是主服务器的mysqld已停止；(2)主键冲突；(3)主从服务器数据不一致；(4)其他原因；
为使复制继续，我们可以进行如下处理：
(1)stop slave ;(2)start slave;(3)检查服务是否正常：show slave status\G
若是主健冲突或数据不一致的情况，则需要额外处理：
(1)停止slave进程
1 | STOP SLAVE; |
(2)设置事务号，事务号从Retrieved_Gtid_Set获取
1 | SET @@SESSION.GTID_NEXT= 'xxxxxxxxxxx' |
(3)设置空事务
1 | BEGIN; COMMIT; |
(4)恢复事务号
1 | SET SESSION GTID_NEXT = AUTOMATIC; |
(5)启动slave进程
1 | START SLAVE; |
实例故障
1.MySQL实例假死
(1)再次确认mysql的运行状态
1 | SHOW PROCESSLIST;是否有大量请求在等待处理 |
此时，为校验是否真处于MysQL假死状态，那么可以用test库中任意执行创建表或更新数据的语句，若回车键后没有响应，则一般可以断定MySQL 是否已经处于假死状态。
(2)检查mysql实例的进程的内存/交换分区状态
使用linux 命令: free -m
使用linux 命令: top
结合当前业务压力，检查内存消耗现状，消耗速度，是否开始使用交换分区,如内存消耗过快且业务压力不大，并发不高，转向对slow query的定位。
(3)检查mysql实例的进程分区使用情况和IO状态
使用Linux命令: df -hT
使用Linux命令: iostat -x
确认分区有足够空间，如异常，则进入对应目录，检查实例的数据和日志存放和增长情况，特别是对日志进行清理处理，或通过调整逻辑卷的大小解决问题。
检查iostat汇报值中 %user, %iowait, %idle 值是否异常，如异常且当前业务压力不大，转向对slow query的定位，同时要求主机运维人员协查物理存储的健康状况。
(4)检查mysqld的CPU使用情况
使用Linux命令: top
使用Linux命令:ps -eo pid,user,comm,pcpu,pmem,vsz | grep mysqld
结合当前业务压力和连接数，确认mysql进程的CPU占用率是否异常，如当前业务压力不大，并发不高，转向对slow query的定位。
(5)检查实例主机的网络通信
使用Linux命令: ping 检测到应用主机，到复制从机的RTT
使用Linux命令: iptraf 确认实例主机的网卡带宽和速度
如以上操作发现异常，需要主机运维人员使用tcpdump进行抓包分析
(6) Slow query 分析
打印slow query日志，分析和定位造成故障的SQL, 必要时，kill 掉出现问题的SQL ID
2.应用报连接池满
(1) 检查io请求状态
使用Linux命令: iostat
查看r/s(读请求),avgrq-sz(平均请求大小),svctm(IO响应时间)
(2)运行orzdba对照SQL执行数量(QPS-sel栏和TPS-iud栏)和逻辑读消耗(Hit%-lor栏)
(3) 转向slow query分析查看行扫描Query_time和Rows_examined栏，如无明显定位和结论，进入下一步全面分析
(4)使用pt-query-digest分析全面slow query，着重分析索引的合法性
(5) 检查General log
(6) 检查Binlog, 对于DML操作, 通过mysqlbinlog工具解析binlog检查
(7) 使用Linux命令 tcpdump抓包分析，配合pt-query-digest做进一步分析排查
3. MySQL请求线程堵塞
(1)检查 processlist
1 | processlist 主要查看 Time, State 栏的汇报值 |
(2)使用pstack 保存当前mysqld实例的栈调用，以备进一步分析
其它故障
1. 各种日志的标准存放路径和查看方法
(1)常规后台进程报错日志log-error路径
1 | show variables like '%log_error%'; |
2 | | log_error | /paic/mymon/data/mysqldata/mymon/mysql.err | |
文本文件，可以直接查看，类似oracle的alert日志。
(2)慢查询日志slow_query_log_file，其设定值long_query_time
1 | show variables like '%slow_query_log_file%'; |
2 | | slow_query_log_file | /paic/mymon/data/mysqldata/mymon/cnsh230234-slow.log | |
3 | show variables like '%long_query_time%'; |
4 | | long_query_time | 10.000000 | |
文本文件，可以看出sql文本及sql的执行时间
(3)数据库二进制日志文件binlog
查看方法mysqlbinlog mysql-bin.000001 |more
可以直接看到事务号和sql脚本
2. mysql进程报错，类似ORA-
例如：071221 11:12:12 [ERROR] Got error 127 when reading table ‘./download_utf8/source_uesrdown’
查看127报错原因
1 | cnsh230234: >perror 127 |
2 | OS error code 127: Key has expired |
3 | MySQL error code 127: Record file is crashed |
4 | 参考处理办法 Repair Table source_uesrdown ; Repair Table userday_money; |
3. 忘记root密码，重置方法如下
(1)/etc/init.d/mysql stop(2)mysqld_safe –skip-grant-tables &(3)mysql -uroot -p(4)update mysql.user set password=password(“”yourpasswd”") where user=”"root”"(5)flush privileges(6)quit
标签：常见故障,slow,检查,Linux,mysql,汇总,SQL,query 来源： https://blog.51cto.com/15127502/2655044