新闻资讯

MySQL5.6升级5.7时出现延迟问题排查

发布时间:2020-11-16 浏览次数:10

近期做 zabbix数据库 MySQL5.6升级5.7时,出现主从式延迟问题,这是困扰许久未解决的问题,昨天终于解决了,整理了整个排查过程,分享给大家。


环境说明:

mysql主库是5.6的版本,它有4个从库,3个5.6,一个5.7,所有主从的库表结构都是一致的,5.7的从库有很多延迟,5.6没有问题,业务是 zabbix监控,基本上都是 insert批量插入操作,每条 insert SQL插入数据在400-1000行左右。


问题:

MySQL5.7的从库大量延迟,relaylog落盘正常,应用到数据库比较慢,磁盘IO和CPU没有压力,sync_binlog为20000或是0没有区别,max_allowed_packet=128M,innodb_flush_log_at_trx_commit=0,bulk_insert_buffer_size = 128M,binlog_format=row,sync_relay_log=10000,没有使用并行复制,没有开启SSL,没有开启GDID,没有开启半同步。


排查过程:


1:检查各个核对各个和性能相关的参数,没有发现异常。


2:检查网卡、硬盘、更换服务器、数据库服务器重启均没有效果,5.7的延迟依然存在,排除硬件问题。


3:5.7同步主库5.6的binlog到relaylog很快,正常,但是relaylog在5.7数据库中回放效率极低。


4:对比5.6和5.7从库的show engine innodb status结果:

image

对比发现5.7中unzip存在数值,5.6的没有,初步怀疑造成延迟的原因和压缩解压相关。


5:使用perf top -p pidof mysqld查看5.7从库

发现libz.so.1.2.7 [.] crc32的占比要高于mysqld,在6%左右,这个库和压缩解压相关。


6:修改innodb_compression_level的等级为0(就是不启用压缩,默认为6,范围为0-9),观察无效果,延迟依然存在。只是


libz的占比下去了,但libc-2.17.so的占比上去了,比mysqld高,在9%左右。使用pstack查看存在研所解压的等待的问题。


7:检查zabbix的历史表,当时为了节约磁盘空间,对这些表做了压缩处理:

image

怀疑和ROW_FORMAT=COMPRESSED KEY_BLOCK_SIZE=8这个压缩参数相关。


8:重建所有历史表,去掉ROW_FORMAT=COMPRESSED KEY_BLOCK_SIZE=8,,重新同步,延迟逐步降低,恢复。


疑问:为什么相同的表结构,在5.7中会造成主从延迟而5.6没有?可能是压缩和解压在MySQL5.7中向下兼容性问题造成的,没有深究,但给官方提了一个BUG,让官方走源码层面去看看:http://bugs.mysql.com/100702。


在生产中请慎用ROW_FORMAT=COMPRESSED KEY_BLOCK_SIZE=8。和业内几位专家交流,表示MySQL8.0之前的版本压缩不太靠谱,8.0的用ZSTD还好一点。

到此这篇关于MySQL5.6升级5.7时出现主从延迟问题MySQL排查过程的文章就介绍到这了。


上一篇: 没有了

下一篇: 运维数据库的作用和特点有哪些?

产品试用 产品试用
400-820-6580 免费电话