场景说明:
由于业务以及历史原因MySQL单实例有一万个数据库左右,历史原因使用的MySQL5.5版本,计划升级,为了不影响业务,开启了MySQL数据的主从同步(具体步骤不在这里详述),备份时间比较长,start slave 之后一直在追赶主库的数据、接到反馈APP端请求超时排查原因的过程
查看当前同步的过程查看当前MySQL同步情况
从库的同步情况
![](https://i-blog.csdnimg.cn/blog_migrate/c9c41c20df32683424444a8c240af898.png)
主库的binlog情况
![](https://i-blog.csdnimg.cn/blog_migrate/40a353f5cea8a3ed259755760f30f817.png)
查看当前主库的io情况
![](https://i-blog.csdnimg.cn/blog_migrate/40a353f5cea8a3ed259755760f30f817.png)
从库还在追赶主库的数据
dstat -l -m -r -c --top-io --top -mem --top-cpu
![](https://i-blog.csdnimg.cn/blog_migrate/1684343a16d5da23e2b4c2df4e9bf81c.png)
查看当MySQL的进程
show full processlit
阻塞进程比较多
查看MySQL当前的事物以及内存使用情况
show engine innodb status\G
锁比较多
![](https://i-blog.csdnimg.cn/blog_migrate/626d61d9abc52018da8a69f048a0fb76.png)
查看MySQL的日志
![](https://i-blog.csdnimg.cn/blog_migrate/ceb9936df1790eabcee55f16fb9a99d3.png)
问题所在,开启主从同步之后这个warning就一直刷屏
分析MySQL主库binlog模式应该为为 statement
![](https://i-blog.csdnimg.cn/blog_migrate/2899e7c57be1c404d050ebdac12dd9b7.png)
找到元凶
处理过程:
- 在从库上stop slave
- 在主库上执行
- 在从库上
检测
错误日志消失、主从同步正常、业务也恢复了正常谨记谨记 MySQL主从复制binlog_format 一定要ROW模式
来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/29987453/viewspace-2150183/,如需转载,请注明出处,否则将追究法律责任。
转载于:http://blog.itpub.net/29987453/viewspace-2150183/