binlog_format=ROW模式下mysql表无主键造成的从库延迟(卡住)

Posted

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了binlog_format=ROW模式下mysql表无主键造成的从库延迟(卡住)相关的知识,希望对你有一定的参考价值。

场景:
mysql-5.6.30, 主从架构, 只读从库的SQL线程卡在某一个事务两个多小时没有动过, show processlist发现从库当时没有连接和慢查询语句;
show open TABLES where In_use >0; 发现一个表被锁定如下:

mysql> show open TABLES where In_use >0;
+----------+---------------+--------+-------------+
| Database | Table         | In_use | Name_locked |
+----------+---------------+--------+-------------+
| cxx      | t_post_xxxxxx |      1 |           0 |
+----------+---------------+--------+-------------+

结论
从库没有线程,说明锁定的表是从主库同步过来的语句锁定的,应该是主库对此表的大事务操作造成。
分析
1.通过show slave status 确定的position去分析主库的binlog,发现生成了大量的删除 t_post_xxxxxx的语句;
2.查看慢查询日志,发现 delete from t_post_xxxxxx;
3.在主库查看 t_post_xxxxxx表结构,发现竟然没有主键也没有索引;
4.select count(*) from t_post_xxxxxx;发现此表20多万条数据;
5.真相大白了,没有主键直接delete删除全表会生成20多万条delete语句在binlog中,没有主键同步到从库需要执行20多万次全表扫描,20W*20W=400多亿,吓人!;
6.MySQL同步的时候, 会去利用主键来搜索需要修改的行(或者是一些二级索引)。
解决方案
1.增加主键;
2.跟研发沟通delete from t_post_xxxxxx改为truncate table t_post_xxxxxx。
综上
由于没有统一数据库上线平台和代码审核机制,造成一些不规范的代码以及数据库设计在生产运行。建议上线使用规范化的数据库上线平台,由平台自动发现数据库设计、数据库上线脚本问题,靠人肉上线难免会有疏漏,自动化运维势在必行,研发团队要使用代码规范检查工具避免不规范的代码上线。

以上是关于binlog_format=ROW模式下mysql表无主键造成的从库延迟(卡住)的主要内容,如果未能解决你的问题,请参考以下文章

mysql中binlog_format模式与配置详解

mysql的binlog日志的binlog_format模式与配置详解

mysql binlog_format row and Statement 比较

MySQL Binlog Mixed模式记录成Row格式

MySQL binlog_format中sbr 和rbr(Statement-Based and Row-Based Replication)的优缺点

mysql row日志格式下 查看binlog sql语句