个人经验~mysql故障处理思路

一 简介:个人经验总结

二 思路: 从整体上再进行梳理

三 linux角度

1 硬件是否有问题  常见主板 raid卡 和raid磁盘组

2 综合指标 负载

uptime : 1min  5min  15min

平均负载 1 值取决于系统上处于R状态（running加runnable）和D状态（不可中断睡眠，也就是等待io完成的进程）的个数之和在指定时间段内的平均值。2 在多核处理中，你的系统均值不应该高于逻辑处理器核心的总数量

分析角度 :负载分为两部分

1 cpu密集型业务处理,表现形式top 下的cpu使用率 (单进程cpu使用率为使用逻辑核心数X100%)

1  user使用率高,正常情况

2 sys使用率高,很罕见, 暂时只有一例( 并发执行的SQL中出现timestamp字段，而linux本身非东八区时区,不断进行转化 引起问题)

2 cpu io 等待,表现形式为top下的iowait较高,iops超过报警阈值

2.5 磁盘性能

磁盘的性能决定  1 随机读 2 随机写 3 顺序读  4 顺序写 通常我们通过这四个角度进行判断磁盘的性能好坏,尤其要在随机读写情况下进行测试

1   观察 磁盘的吞吐量 是否达到阈值

2  观察 磁盘的IOPS是否达到阈值

3  观察磁盘的 util是否一直100%

4 观察iftop下的jdb2进程,如果繁忙,也代表磁盘存在瓶颈,不过很少见这种情况,如果jdb2经常占用资源多,建议采用XFX代替ext4或者直接关闭jdb2

总结  要结合这三点进行观察,查看磁盘性能问题,补充一点,iowait较高只能说明cpu的IO等待较高,不能直接反应磁盘瓶颈

3 综合指标 内存

mysqld  VIRT  RES

内存使用 VIRT~虚拟映射内存 RES~常驻内存 常规状态下基本与 innodb_buffer_pool相差不大,

分析角度: 内存相关问题

1 内存使用过度,直到占用swap内存,发生oom-killer,选择升级内存容量是比较好的选择

2  内存使用异常(可以理解成内存泄漏),根据top VIR RES 和 mysql内部BF设置的值对比,常态情况下,VIR的值会高于一些RES和BF设置的值,RES和BF设置的值应该相近,但是如果RES得值远远高于BF的值(几倍甚至数十倍),这样很大情况是出现了内存泄漏

1 可以尝试进行关闭NUMA/或者以 numactl --interleave=all 方式启动mysqld 2 flush tables 手动触发释放内存

3  swap占用过多,但是内存使用正常

1 通过命令  for i in $( cd /proc;ls |grep "^[0-9]"|awk ' $0 >100') ;do awk '/Swap:/{a=a+$2}END{print '"$i"',a/1024"M"}' /proc/$i/smaps 2>/dev/null ; done | sort -k2nr | head -10 查看占用swap过多pid 针对多实例场景

2 调节 /proc/sys/vm/swappiness,尽量减少swap的使用 默认值60 

注意: 1  重启服务器并不能解决内存泄漏,还会可能发生

2 mysql所占用的res内存并不会释放,除非重启整个服务

3 内存泄漏同样会发生OOM-KIIER现象,这点要注意

4 mysql数据查询大量使用的是cache

分析  1 从buffer_pool和会话session两方面进行分析占用

2 查询sys库指定视图进行线程分配定位(根据我另一篇文章使用)

4 综合指标  网络环境异常

1 网卡流量过高 2 大量连接 time out

分析角度:

1  网卡流量过高,堵死网卡

现象

1 show processlist中出现 waiting for net  网卡流量监控报警

2 短时间出现大量binlog生成,传输到从库

3  IDC内部集群其他机器流量影响到数据库机器

2 网络连通性出现异常

1 防火墙设置规则问题

2 周期性丢包,网络识别或者网卡本身有问题

解决方法 : 1 测试网络连通性  2 通过iftop定位网卡流量来源  3 linux关于系统方面关于网络连接参数的设置

注意:网卡流量如果达到网卡流量上线,可能会阻塞,导致网络不通,要及时解决

总结 : 1 负载比较高,一定是这两种之一出了问题 或者两者皆有

2 对于mysql服务, 服务器本身的cpu性能不会太差,80%的问题出现在磁盘本身的瓶颈上,最好采购标准采用较高转速的磁盘组

3 对于内存异常问题,则比较棘手,建议关闭NUMA进行尝试

4 不要使用廉价机器,一定要选用稳定的DELL机器

5 防止大流量的动作阻塞网卡

6 网卡硬件更换或者交换机识别问题

四 mysql角度:

1 事务语句

1 单库的并发事务操作

2 多库的并发事务操作,形成干扰

3 事务语句形成的大量锁等待情况

2 SELECT 查询

1 并发查询事务 比如定时task或者某个活动 形成瞬发的慢查询

2 慢查询 执行时间很长的慢sql->这里一定要注意是真正的慢查询,而非因为IO等待造成的慢sql

3 真正的慢查询

1 cpu消耗性慢查询

2 io  消耗性慢查询

3 混合型事务

由select和事务语句共同造成的

4  前端缓存失效

常见于 redis es等出现故障,导致程序不查缓存直接查询mysql，负载瞬间升高

5 程序问题

常见于 程序问题不断重试耗尽mysql最大链接数

6  mysql自身版本BUG

这个就比较难处理了,必须得根据perf定位具体代码问题,这里可以补充下,我之前遇到过最多的就是由于AHI有几率触发的BUG问题,所以大家不妨关闭AHI试试,其他的只能具体代码分析了,大家可以根据官网BUG汇总或者寻求高手帮助

五  硬件瓶颈

注意:在你使用下面处理故障思路都无法解决问题的情况下才会考虑这个问题,我举例子

在已做读写分离的场景下,由于主库大量的事务操作,导致瓶颈,出现的两个特征

1是主库负载平均负载很高  主业务反应迟缓

2从库出现周期性延迟, 读业务不能忍受延迟

六  处理故障思路

1 收集相关信息

监控走势图和数据 :

linux 1 平均负载 2 cpu使用率 3 网卡流量图   4 IOPS图

mysql 1 qps 2 tps 3 binlog生成量 4慢日志文件 5 锁等待相关数据

2 分析方法

1 定位故障时间 根据linux平均负载图和cpu使用率图可以定位出 是cpu还是IO导致的问题

2 根据qps和tps曲线图可以过滤出故障时间时是否有大的波动

1 假如是由于 qps造成的

1 分析慢日志 过滤row，看看在这段时间是否有大的慢sql扫描  解决方法:优化sql

补充:一条优化很差的慢sql就可能会导致磁盘组的util值达到100%,所以要重视

2 查看qps曲线图,看看在这段时间是否有大的并发提起             解决方法:降低频率，做读写分离

2 假如是由于tps造成的

通过qps曲线图可以定位是删 改 更新 操作

1 对于偶发故障  减少并发操作和锁等待

2 对于经常故障

1 单库业务  解决方法 拆分表，减少单库的压力

2 多库 业务 解决方法  拆分不同DB业务库,减少单库压力

3 假如是由于程序问题造成的

1 由于程序不断尝试引起的mysql max_connections被耗尽,大量sleep线程,如果被kill,还会自动生成

停止程序,修复BUG问题

3 缓存云失效

1 做好redis ES等的监控

总结

1 更改程序逻辑,降低复杂度和操作数据库次数、

2 mysql前端增加缓存云

3 尽量做读写分离 减少主库压力

4  提前做好分库分表的方案,避免因为数据量过多导致的主库压力

5 优化慢语句

6 在发生问题时及时和研发取得联系,因为有些应用程序会不断调用数据库,需要配合处理

小技巧 通过 show innodb status观察合并次数和网卡读写流量对比 可以帮助判断是事务还是查询量大