MySQL升级时出现主从延迟怎么解决 - 行业资讯 - 肥雀云

　　介绍

本篇文章给大家分享的是有关MySQL升级时出现主从延迟怎么解决,小编觉得挺实用的,因此分享给大家学习,希望大家阅读完这篇文章后可以有所收获,话不多说,跟着小编一起来看看吧。

<强>环境说明:

MySQL主库为5.6的版本,有四个从库,三个为5.6的版本,一个为5.7的版本,所有主从的库表结构均一致,5.7的从库出现大量延迟,5.6的没问题,业务为zabbix监控,基本全部为插入批量插入操作,每条insert SQL插入数据为400 - 1000行左右。

MySQL5.7的从库大量延迟,relaylog落盘正常,应用到数据库比较慢,磁盘IO和CPU没有压力,sync_binlog为20000或是0没有区别,max_allowed_packet=128, innodb_flush_log_at_trx_commit=0, bulk_insert_buffer_size=128, binlog_format=行,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从库的显示引擎innodb状态结果:

=============5.6===============================撼宄? 　　缓冲池大小655359 　　缓冲池大小,字节10737401856 　　自由缓冲区1019 　　数据库页649599 　　旧数据库页239773 　　修改数据库页119309 　　等待读取0 　　等待写道:LRU 0,刷新列表0,单页0 　　让年轻的10777670页面,不年轻181119246 　　13.90扬斯/秒,157.51 non-youngs/s 　　写页面读8853516,创造了135760152,784514803 　　20.96读?秒,58.17创建/秒,507.02/s写道　　缓冲池命中率1000/1000,young-making率0/1000不是2/1000 　　页面读前0.00/s,驱逐没有0.00/s,随机读取之前0.00/s 　　LRU len: 649599年,unzip_LRU len: 0 　　I/O和[209618]:坏蛋[2],[0]:解压缩和坏蛋[0] =============5.7==============================撼宄? 　　缓冲池大小819100 　　缓冲池大小,字节13420134400 　　自由缓冲区1018 　　数据库页722328 　　旧数据库页266620 　　修改数据库页99073 　　等待读取0 　　等待写道:LRU 0,刷新列表0,单页0 　　让年轻的37153页,795年不年轻　　0.00扬斯/秒,0.00 non-youngs/s 　　读149632页,572696年创建,写2706369 　　0.00读?秒,0.00创建/秒,0.00/s写道　　缓冲池命中率1000/1000,young-making率0/1000不是0/1000 　　页面读前0.00/s,驱逐没有0.00/s,随机读取之前0.00/s 　　LRU len: 722328年,unzip_LRU len: 453903 　　I/O和[98685]:坏蛋[0],解压缩和[882]:坏蛋[6] 　　+ + + + + + + + + + + + + + + + + + + + + + +

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

5:使用穿孔前- 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。所以的占比上去了,比mysqld高,在9%左右。使用pstack查看存在研所解压的等待的问题。

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

创建表的趋势(
　　itemid bigint(20)无符号不是零,
　　时钟int (11) NOT NULL默认& # 39;0 & # 39;
　　num int (11) NOT NULL默认& # 39;0 & # 39;
　　value_min双(16日4)NOT NULL默认& # 39;0.0000 & # 39;
　　value_avg双(16日4)NOT NULL默认& # 39;0.0000 & # 39;
　　value_max双(16日4)NOT NULL默认& # 39;0.0000 & # 39;
　　主键(itemid,时钟),
　　关键时钟(时钟)
　　)引擎=InnoDB的默认字符集=utf8 ROW_FORMAT=压缩KEY_BLOCK_SIZE=8

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

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

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

以上就是MySQL升级时出现主从延迟怎么解决,小编相信有部分知识点可能是我们日常工作会见到或用到的。希望你能通过这篇文章学到更多知识。更多详情敬请关注行业资讯频道。