您好，登录后才能下订单哦！
密码登录
登录注册
点击 登录注册 即表示同意《亿速云用户服务条款》
本篇文章给大家分享的是有关MySQL升级时出现主从延迟怎么解决，小编觉得挺实用的，因此分享给大家学习，希望大家阅读完这篇文章后可以有所收获，话不多说，跟着小编一起来看看吧。
环境说明：
mysql主库为5.6的版本，有四个从库，三个为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结果：
=============5.6=============================== ---BUFFER POOL 1 Buffer pool size 655359 Buffer pool size, bytes 10737401856 Free buffers 1019 Database pages 649599 Old database pages 239773 Modified db pages 119309 Pending reads 0 Pending writes: LRU 0, flush list 0, single page 0 Pages made young 10777670, not young 181119246 13.90 youngs/s, 157.51 non-youngs/s Pages read 8853516, created 135760152, written 784514803 20.96 reads/s, 58.17 creates/s, 507.02 writes/s Buffer pool hit rate 1000 / 1000, young-making rate 0 / 1000 not 2 / 1000 Pages read ahead 0.00/s, evicted without access 0.00/s, Random read ahead 0.00/s LRU len: 649599, unzip_LRU len: 0 I/O sum[209618]:cur[2], unzip sum[0]:cur[0]
=============5.7============================== ---BUFFER POOL 1 Buffer pool size 819100 Buffer pool size, bytes 13420134400 Free buffers 1018 Database pages 722328 Old database pages 266620 Modified db pages 99073 Pending reads 0 Pending writes: LRU 0, flush list 0, single page 0 Pages made young 37153, not young 795 0.00 youngs/s, 0.00 non-youngs/s Pages read 149632, created 572696, written 2706369 0.00 reads/s, 0.00 creates/s, 0.00 writes/s Buffer pool hit rate 1000 / 1000, young-making rate 0 / 1000 not 0 / 1000 Pages read ahead 0.00/s, evicted without access 0.00/s, Random read ahead 0.00/s LRU len: 722328, unzip_LRU len: 453903 I/O sum[98685]:cur[0], unzip sum[882]:cur[6] +++++++++++++++++++++++
对比发现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的历史表，当时为了节约磁盘空间，对这些表做了压缩处理：
CREATE TABLE trends ( itemid bigint(20) unsigned NOT NULL, clock int(11) NOT NULL DEFAULT '0', num int(11) NOT NULL DEFAULT '0', value_min double(16,4) NOT NULL DEFAULT '0.0000', value_avg double(16,4) NOT NULL DEFAULT '0.0000', value_max double(16,4) NOT NULL DEFAULT '0.0000', PRIMARY KEY (itemid,clock), KEY clock (clock) ) ENGINE=InnoDB DEFAULT CHARSET=utf8 ROW_FORMAT=COMPRESSED KEY_BLOCK_SIZE=8
怀疑和ROW_FORMAT=COMPRESSED KEY_BLOCK_SIZE=8这个压缩参数相关。
8：重建所有历史表，去掉ROW_FORMAT=COMPRESSED KEY_BLOCK_SIZE=8，，重新同步，延迟逐步降低，恢复。
在生产中请慎用ROW_FORMAT=COMPRESSED KEY_BLOCK_SIZE=8。和业内几位专家交流，表示MySQL8.0之前的版本压缩不太靠谱，8.0的用ZSTD还好一点。
以上就是MySQL升级时出现主从延迟怎么解决，小编相信有部分知识点可能是我们日常工作会见到或用到的。希望你能通过这篇文章学到更多知识。更多详情敬请关注亿速云行业资讯频道。
免责声明：本站发布的内容（图片、视频和文字）以原创、转载和分享为主，文章观点不代表本网站立场，如果涉及侵权请联系站长邮箱：is@yisu.com进行举报，并提供相关证据，一经查实，将立刻删除涉嫌侵权内容。