记一次MYSQL故障定位分析全过程

场景说明：

由于业务以及历史原因MySQL单实例有一万个数据库左右，历史原因使用的MySQL5.5版本，计划升级，为了不影响业务，开启了MySQL数据的主从同步（具体步骤不在这里详述），备份时间比较长，start slave 之后一直在追赶主库的数据、接到反馈APP端请求超时

排查原因的过程

查看当前同步的过程
查看当前MySQL同步情况
从库的同步情况

主库的binlog情况

查看当前主库的io情况

从库还在追赶主库的数据

dstat -l -m -r -c --top-io --top -mem --top-cpu

查看当MySQL的进程

show full processlit

阻塞进程比较多

查看MySQL当前的事物以及内存使用情况

show engine innodb status\G

锁比较多

查看MySQL的日志

问题所在，开启主从同步之后这个warning就一直刷屏

分析MySQL主库binlog模式应该为为statement

找到元凶

处理过程：

在从库上stop slave

set global binlog_format = ROW

在主库上执行

set global binlog_format = ROW

在从库上

start slave;

检测

错误日志消失、主从同步正常、业务也恢复了正常

谨记谨记 MySQL主从复制binlog_format 一定要ROW模式