作者简介:鲁越,腾讯云数据库架构师,主要负责腾讯云数据库MySQL、Redis、MongoDB、Oracle等数据库架构设计、数据库运维、运营开发等工作,曾就职于网易游戏。
问题描述
一、问题描述
1) 两个RO同时复制异常,程序读不到最新的数据。
2) 报错信息、数据库版本5.6。尝试执行了一下stop slave;start slave; 没办法快速恢复。
问题1:此时,如果是你,如何去处理这个case?
3)观察了一下主库的CPU、IO等状态,先把读写流量都切到主库。先恢复业务
4)通过迁移RO的方式来恢复RO与主实例的主从
5)同时通过报错信息,解析报错对应的binlog位点,详细分析1837报错的原因。
5.1)发现报错位点对应的事务为对同一张表进行的两个insert操作,并无什么异常。
5.2) 很自然的想到看看表结构,一看发现了怪异之处。
问题2:怪异之处在哪里?
CREATE TABLE `log_online_players` (
`count` int(4) unsigned NOT NULL COMMENT '在线人数',
`time` int(4) NOT NULL COMMENT '时间',
KEY `NewIndex1` (`time`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8 COLLATE=utf8_bin
5.3) Myisam这种非事务引擎,每一个DML操作都会被强制提交,也就是说,在这个case里面,每一个insert操作应该对应binlog里面的一个event。但是我们分析binlog的时候发现,一个event里面出现了2条insert语句。这条binlog在备机回放的时候,SQL线程执行完这个event里面的第一个insert语句以后就对整个事务提交了,这样造成了上述的报错。
5.4)报错的原因找出来了,但是为什么会出现这个问题呢?这个问题我非常的迷惑,现在核心的点就是为什么在对Myisam引擎执行insert操作的时候,一个事务里面会出现了2条insert。
5.5) 复现步骤
1# 复制库表接口到测试环境
2# 模拟插入流量 insert_normal.sh,发现主从复制并没有断。分析了一下binlog,也是跟我所认知的情况一致:在myisam引擎中,一个event里面只会存在一条insert,不可能出现一个event里面有2条或者多条DML记录的情况发生。
3# 我开始思考,有没有可能是我测试的环境下并发不够,有没有可能是因为在高并发情况下MySQL的机制有bug。在把并发提高,测试实例的TPS量与故障实例TPS量基本一致,甚至超过故障实例的情况下依然没办法复现。这个时候我陷入了瓶颈。
4# 这个时候,去主库上开启了Glog,执行了show processlist,发现真正执行的语句并不是insert into,而是insert delay into。在执行insert delay into语句的情况下,可能连续执行N个INSER操作,生成多个INSERT事件,而在生成GTID时,就只对应一个event。明显的,DELAYED语法生成了违反GTID限制的binlog。这个语法在GTID模式下应该是禁止。
5# 马上去主库上开了一下Glog,发现的确是执行的insert delay操作。整个case就真相大白了。
6# 自己做一次复现
扩展知识
二、扩展知识
1)针对GTID,官方主要有三个限制
- CREATE TABLE ... SELECT statements
- CREATE TEMPORARY TABLE statements inside transactions
- Transactions or statements that update both transactional and nontransactional tables.
2)insert delay
往数据库里插入数据的标准命令是INSERT,而DELAYED的意思,则是异步插入。也就是说,MySQL接受这个命令后,保存命令就直接返回给客户端,因此用户会发现在某些场景下INSERT DELAYED性能优于”INSERT,实际上只是更快的返回,而非更快的完成。
思考
三、思考
1、看到报错信息的时候,如果优先google一下,整体的排查速度会快的多;
2、RO出了问题,就一直在排查RO,如果早一点上master上执行一下show processlist,这样是有很大可能看到insert delay这个语句的;
3、慎做非标。