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。
综上
由于没有统一数据库上线平台和代码审核机制,造成一些不规范的代码以及数据库设计在生产运行。建议上线使用规范化的数据库上线平台,由平台自动发现数据库设计、数据库上线脚本问题,靠人肉上线难免会有疏漏,自动化运维势在必行,研发团队要使用代码规范检查工具避免不规范的代码上线。

原文地址:http://blog.51cto.com/175779/2309757

时间: 2024-10-05 05:31:33

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

MySQL 解密 --> 如何查看二进制日志ROW模式下最原始的SQL语句

MySQL的binlog的ROW模式解析          在mysql5.6以后,对主从数据一致性要求变高了,statement格式逐渐不太适合业务的需求了,所以生产环境大家都采用了row模式,row模式是传输最底层的数据变化的insert的模块来进行主从数据的传输,那么在binlog里面就和普通的statement模式有何差别?能否看到最原始的sql语句呢? 1.准备录入数据 mysql> create table test1(id int,c1 varchar(20),type int,a

设置Linux下Mysql表名不区分大小写

1.Linux下mysql安装完后是默认:区分表名的大小写,不区分列名的大小写:2.用root帐号登录后,在/etc/my.cnf中的[mysqld]后添加添加lower_case_table_names=1,重启MYSQL服务,这时已设置成功:不区分表名的大小写:lower_case_table_names参数详解:lower_case_table_names=0其中0:区分大小写,1:不区分大小写 MySQL在Linux下数据库名.表名.列名.别名大小写规则是这样的:1.数据库名与表名是严格

mysql 在row模式下truncate 与 delete 二进制日志记录的差异

二进行日志的格式为row mysql> show variables like 'binlog_format'; +---------------+-------+ | Variable_name | Value | +---------------+-------+ | binlog_format | ROW | +---------------+-------+ 1 row in set (0.00 sec) 在testdb库下执行 mysql> select * from t1; +--

【转载】备库由于表无主键导致延迟

摘要: 由于ROW模式的复制已经广泛使用,但对于没有主键的表而言,如果发生大更新,在备库上会表现出极大的延迟,因为在binlog中产生的大量行记录将无法根据主键快速查找,最差的情况,需要对每条修改的记录进行全表扫描. 5.6已经解决了这个问题,可以只扫描一次表:5.5最新的版本只是在错误日志里输出了一些信... 由于ROW模式的复制已经广泛使用,但对于没有主键的表而言,如果发生大更新,在备库上会表现出极大的延迟,因为在binlog中产生的大量行记录将无法根据主键快速查找,最差的情况,需要对每条修

SAS vs SSD各种模式下MySQL TPCC OLTP对比测试结果

在各种测试组合方案中,组合10(组合10:SSD * 2, RAID 0, XFS,WB,nobarrier,noop)的综合性能最高,因此以它为基准,其他方案与其对比,下表是各组合和组合10的对比: 相应的对比线形图: 测试环境: 结语1. 在xfs文件系统模式下,SSD设备的性能是SAS设备性能的6 ~ 13倍,平均:9倍,在并发16线程时最高(和MySQL的内部机制有关):2. SSD设备使用noop模式的IO调度器效率最高(关于Linux内核IO调度器详见:http://www.redh

EF模式下 多表关联查询结果作为数据源 gridview无法编辑的问题解决思路

之前做项目都习惯了使用SQL方便又快捷,但是近期领导要求使用对象实体的方式进行程序的开发 比较了多个ORM框架之后 决定还是采用微软自家的EF吧 .初次使用EF,没有什么经验 ,在实际使用过程中 遇到了一些问题,也折腾了好长时间... 前天在开发某个功能的时候 一个小兄弟 就发现 采用EF模式 在多表关联查询的结果作为数据源的情况下 gridview可以正常的显示 但是无法进行编辑,各种属性也都没问题,这可怎么办?百度之,有人说这是因为EF下gridview编辑都是依托于实体类的 ,多表关联的结

linux下mysql表名大小写问题

近日,新mysql实例导入sql数据时,发现比老的mysql多了100+张表,最终发现是mysql表名大小写所致:很简单的问题却耽误很长时间,在此记录一下,以防再犯同样的错误: 1.Linux下mysql安装完后是默认:区分表名的大小写,不区分列名的大小写:2.用root帐号登录后,在/etc/my.cnf中的[mysqld]后添加添加lower_case_table_names=1,重启MYSQL服务,这时已设置成功:不区分表名的大小写:lower_case_table_names参数详解:l

解决windows下MySQL表名大写自动变小写的问题

有些人可能会遇到在windows下,表名不能用大写字母, 即使使用了大写字母的建表语句,还是会被自动转成小写. 解决方法: 打开 MySQL 的配置文件 my.ini ,在 [mysqld] 节下加入 Xml代码 lower_case_table_names=0 重启MySQL,大功告成.

Windows平台使用C语言在用户模式下注册表的增删改查

一.Wiodws注册表介绍 Windows操作系统提供了一个称为“注册表”的中心存储设施作为系统的配置和管理中心.应用程序和内核通过访问注册表来读写各种配置.Windows同时提供了一些API供应用程序访问注册表,这些API函数在接到注册表访问请求后会将他们转发给内核的系统服务.然后内核会做出相应的处理. Widows注册表是一个树状结构,每一个节点是一个键或值.键是一个容器,好比文件系统中的文件夹,值存储的是数据,相当于文件系统的文件,键可以包含其它的键(目录)或值(文件).注册表的根目录称为