MySQL5.6升级5.7时出现主从延迟问题排查过程
最近在做zabbix的数据库MySQL5.6升级5.7时，出现主从延迟问题，这个问题困扰了很久没有解决，昨天终于解决了，整理了一下整个排查过程，分享给大家。
环境说明：
mysql主库为5.6的版本，有四个从库，三个为5.6的版本，一个为5.7的版本，所有主从的库表结构均一致，5.7的从库出现大量延迟，5.6的没问题，业务为zabbix监控，基本全部为insert批量插入操作，每条insertSQL插入数据为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从库的showengineinnodbstatus结果：
=============5.6=============================== ---BUFFERPOOL1 Bufferpoolsize655359 Bufferpoolsize,bytes10737401856 Freebuffers1019 Databasepages649599 Olddatabasepages239773 Modifieddbpages119309 Pendingreads0 Pendingwrites:LRU0,flushlist0,singlepage0 Pagesmadeyoung10777670,notyoung181119246 13.90youngs/s,157.51non-youngs/s Pagesread8853516,created135760152,written784514803 20.96reads/s,58.17creates/s,507.02writes/s Bufferpoolhitrate1000/1000,young-makingrate0/1000not2/1000 Pagesreadahead0.00/s,evictedwithoutaccess0.00/s,Randomreadahead0.00/s LRUlen:649599,unzip_LRUlen:0 I/Osum[209618]:cur[2],unzipsum[0]:cur[0]
=============5.7============================== ---BUFFERPOOL1 Bufferpoolsize819100 Bufferpoolsize,bytes13420134400 Freebuffers1018 Databasepages722328 Olddatabasepages266620 Modifieddbpages99073 Pendingreads0 Pendingwrites:LRU0,flushlist0,singlepage0 Pagesmadeyoung37153,notyoung795 0.00youngs/s,0.00non-youngs/s Pagesread149632,created572696,written2706369 0.00reads/s,0.00creates/s,0.00writes/s Bufferpoolhitrate1000/1000,young-makingrate0/1000not0/1000 Pagesreadahead0.00/s,evictedwithoutaccess0.00/s,Randomreadahead0.00/s LRUlen:722328,unzip_LRUlen:453903 I/Osum[98685]:cur[0],unzipsum[882]:cur[6] +++++++++++++++++++++++
对比发现5.7中unzip存在数值，5.6的没有，初步怀疑造成延迟的原因和压缩解压相关。
5：使用perftop-ppidofmysqld查看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的历史表，当时为了节约磁盘空间，对这些表做了压缩处理：
CREATETABLEtrends( itemidbigint(20)unsignedNOTNULL, clockint(11)NOTNULLDEFAULT'0', numint(11)NOTNULLDEFAULT'0', value_mindouble(16,4)NOTNULLDEFAULT'0.0000', value_avgdouble(16,4)NOTNULLDEFAULT'0.0000', value_maxdouble(16,4)NOTNULLDEFAULT'0.0000', PRIMARYKEY(itemid,clock), KEYclock(clock) )ENGINE=InnoDBDEFAULTCHARSET=utf8ROW_FORMAT=COMPRESSEDKEY_BLOCK_SIZE=8
怀疑和ROW_FORMAT=COMPRESSEDKEY_BLOCK_SIZE=8这个压缩参数相关。
8：重建所有历史表，去掉ROW_FORMAT=COMPRESSEDKEY_BLOCK_SIZE=8，，重新同步，延迟逐步降低，恢复。
疑问：为什么相同的表结构，在5.7中会造成主从延迟而5.6没有？可能是压缩和解压在MySQL5.7中向下兼容性问题造成的，没有深究，但给官方提了一个BUG，让官方走源码层面去看看：http://bugs.mysql.com/100702。
在生产中请慎用ROW_FORMAT=COMPRESSEDKEY_BLOCK_SIZE=8。和业内几位专家交流，表示MySQL8.0之前的版本压缩不太靠谱，8.0的用ZSTD还好一点。
到此这篇关于MySQL5.6升级5.7时出现主从延迟问题排查过程的文章就介绍到这了,更多相关MySQL5.6升级5.7主从延迟内容请搜索毛票票以前的文章或继续浏览下面的相关文章希望大家以后多多支持毛票票！
声明：本文内容来源于网络，版权归原作者所有，内容由互联网用户自发贡献自行上传，本网站不拥有所有权，未作人工编辑处理，也不承担相关法律责任。如果您发现有涉嫌版权的内容，欢迎发送邮件至：czq8825#qq.com（发邮件时，请将#更换为@）进行举报，并提供相关证据，一经查实，本站将立刻删除涉嫌侵权内容。