mysql5.6 主从 延迟_MySQL5.6升级5.7时出现主从延迟问题排查过程

最近在做zabbix的数据库MySQL5.6升级5.7时,出现主从延迟问题,这个问题困扰了很久没有解决,昨天终于解决了,整理了一下整个排查过程,分享给大家。

环境说明:

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,,重新同步,延迟逐步降低,恢复。

疑问:为什么相同的表结构,在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时出现主从延迟问题排查过程的文章就介绍到这了,更多相关MySQL5.6升级5.7主从延迟内容请搜索脚本之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持脚本之家!

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
MySQL主从延迟问题是数据库运维中经常遇到的问题之一,通常会引起应用程序性能下降或者数据不一致的问题。下面我们来介绍一下如何排查MySQL主从延迟问题。 1. 确认主从复制的状态 首先需要确认主从复制的状态。可以通过以下命令查看: ``` SHOW SLAVE STATUS \G; ``` 在输出结果中,需要关注以下几个参数: - Slave_IO_Running:表示Slave I/O线程是否正在运行,如果为YES,则正常运行,否则需要检查错误日志; - Slave_SQL_Running:表示Slave SQL线程是否正在运行,如果为YES,则正常运行,否则需要检查错误日志; - Seconds_Behind_Master:表示从库落后主库的间,如果为0,则表示主从同步正常。 2. 确认网络延迟 如果主从复制状态正常,但是Seconds_Behind_Master不为0,那么需要确认网络延迟是否存在。可以通过在主库和从库上分别执行以下命令进行测试: 在主库执行: ``` SELECT NOW(); ``` 在从库执行: ``` SELECT NOW(); ``` 比较两个输出结果的间差,即可得到主从复制的网络延迟间。如果网络延迟较大,可以考虑优化网络连接或者将主从库部署在同一地域内。 3. 检查主从库配置 如果网络延迟不存在,那么需要检查主从库的配置是否正确。可以比较主从库的以下参数是否一致: - server_id:表示服务器的ID,主从库必须不同; - log_bin:表示二进制日志文件名称,主库必须开启二进制日志; - binlog_format:表示二进制日志格式,主库必须开启ROW格式; - replicate_do_db:表示从库需要复制的数据库,如果设置了该参数,则只复制该数据库; - replicate_ignore_db:表示从库忽略复制的数据库,如果设置了该参数,则不复制该数据库。 4. 检查主从库版本 如果主从库配置正确,但是主从延迟问题依然存在,那么需要检查主从库的版本是否一致。主从库的版本必须一致,否则会出现主从延迟问题。 5. 总结 通过以上步骤,可以排查MySQL主从延迟问题。在实际运维过程中,还可以通过监控工具对主从库的状态进行实监控,及发现主从延迟问题,并进行处理。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值