最近在做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.7主从延迟

免责声明:本站文章均来自网站采集或用户投稿,网站不提供任何软件下载或自行开发的软件! 如有用户或公司发现本站内容信息存在侵权行为,请邮件告知! 858582#qq.com

《魔兽世界》大逃杀!60人新游玩模式《强袭风暴》3月21日上线

暴雪近日发布了《魔兽世界》10.2.6 更新内容,新游玩模式《强袭风暴》即将于3月21 日在亚服上线,届时玩家将前往阿拉希高地展开一场 60 人大逃杀对战。

艾泽拉斯的冒险者已经征服了艾泽拉斯的大地及遥远的彼岸。他们在对抗世界上最致命的敌人时展现出过人的手腕,并且成功阻止终结宇宙等级的威胁。当他们在为即将于《魔兽世界》资料片《地心之战》中来袭的萨拉塔斯势力做战斗准备时,他们还需要在熟悉的阿拉希高地面对一个全新的敌人──那就是彼此。在《巨龙崛起》10.2.6 更新的《强袭风暴》中,玩家将会进入一个全新的海盗主题大逃杀式限时活动,其中包含极高的风险和史诗级的奖励。

《强袭风暴》不是普通的战场,作为一个独立于主游戏之外的活动,玩家可以用大逃杀的风格来体验《魔兽世界》,不分职业、不分装备(除了你在赛局中捡到的),光是技巧和战略的强弱之分就能决定出谁才是能坚持到最后的赢家。本次活动将会开放单人和双人模式,玩家在加入海盗主题的预赛大厅区域前,可以从强袭风暴角色画面新增好友。游玩游戏将可以累计名望轨迹,《巨龙崛起》和《魔兽世界:巫妖王之怒 经典版》的玩家都可以获得奖励。