dba学院课程之：mysql故障诊断案例
TRANSCRIPT
MySQL无故被kill – 现象
• MySQL实例宕机，检测到日志中是由mysqld被kill -9导致
• 如何排查？
MySQL无故被kill – 原因
• ulimit 有异常参数
$ ulimit -t
300
• -t的含义
– The maximum amount of cpu time in seconds
– 实际上为，进程消耗cpu的总量，达到阈值后会自己被kill
• 扩展
MySQL无故被shutdown – 现象
• MySQL实例宕机，检测到日志中是mysqld被正常的shutdown
• 如何排查？
MySQL无故被shutdown – 排查
• 定位问题的触发点
– 批量升级agent，导致集群中一台机器被shutdown(时间点吻合)
• 查看dbagent代码(关注各种kill)
• 各种猜测+验证
MySQL无故被shutdown – 结果
restart机器后, mysqld的pid和agent老的pid(agent的pid文件未被删除)相同例如：
重启前：agent pid=1000, mysqld pid=10001 重启后：agent pid=1000, mysqld pid=10000
MySQL机器内存爆掉—现象
MySQL机器的内存每隔几天就会增长，涨上去后，却不下来。累积后内存爆掉。
MySQL机器内存爆掉 -- 思考
• 近期升级过kernel的因素？
• innodb内部统计的内存使用量
• NUMA开关导致swap？
• 临时表、memory引擎表？
• 连接所消耗内存？
• table cache相关的内存？
• 真正的mysqld内存泄漏？
• … 其它
MySQL机器内存爆掉—解决
执行FLUSH TABLES发现mysqld的RSZ直接减少10G~
定时在业务低峰时flush tables
Communications link failure – 现象
MySQL APP业务线上最近抛出异常
Communications link failure – 现象 Information Schema库中的InnoDB_trx表，发现发现有不少
已经开启的事务：
Communications link failure – 本质
• 认识上的误区：在autocommit=0时，即使是select也要注意，显示地提交事务！
• 详情
MySQL上dump数据缓慢 – 现象
MySQL群集中某台机器拉数据明显地比其它机器慢 怎么办？
对比集群中的运行环境
MySQL上dump数据缓慢– 对比
IO调度策略改变后的对比
CFQ和DEADLINE的对比 --小结
• CFQ通过对IO地址排序来减少磁盘寻道时间 – 从rrqm/s和wrqm/s的数据看非常明显
• CFQ先来的IO请求并不一定能被满足 – await明显的偏长
• DEADLINE(或SSD中的NOOP)比CFQ更适合DB – rsec/s和wsec/s比CFQ中量更大
• 详情
对同一条记录的更新慢 – 现象
• 现象表现 - 应用有个别连接间断性报错：锁等待超时错误（超过100s)
- slow.log中大量的相同同一条记录更新语句：
update dep_deposit set
gmt_modified=now(), seller_id=xxx, ...
where id=239758;
• “热卖商品”死锁补丁？？？
对同一条记录的更新慢 --疑点
• 疑点1： – 从业务方了解，此记录为热门退货的某条记录，集中段在有大量的商品退货：
14点：203次 （出现异常）
13点：22次
12点：9次
• 疑点2 – innodb status的DEADLOCK DETECT无“检测递归深度过大”字样
对同一条记录的更新慢 – 解决
• APP应用在MySQL的事务中嵌套了对TAIR的访问
– TAIR慢而导致事务中个别未提交事务
– 引发其它锁相关的问题
• 将不合理的TAIR依赖从事务中移除
• 详情
MySQL-5.5多实例频繁发生swap
