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_mit=0,bulk_insert_buffer_size = 128M,binlog_format=row,sync_relay_log=10000,没有使用并行复制,没有开启SSL,没有开启GDID,没有开启半同步。
排查过程
1检查各个核对各个和性能相关的参数,没有发现异常。
2检查网卡、硬盘、更换服务器、数据库服务器重启均没有效果,5.7的延迟依然存在,排除硬件问题。
35.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 aess 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 aess 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 -p pidof mysqld查看5.7从库
发现libz.so.1.2.7 [.] crc32的占比要高于mysqld,在6%左右,这个库和压缩解压相关。
6修改innodb_pression_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,让官方走源码层面去看看。
在生产中请慎用ROW_FORMAT=COMPRESSED KEY_BLOCK_SIZE=8。和业内几位专家交流,表示MySQL8.0之前的版本压缩不太靠谱,8.0的用ZSTD还好一点。
到此这篇关于MySQL5.6升级5.7时出现主从延迟问题排查过程的文章就介绍到这了,更多相关MySQL5.6升级5.7主从延迟内容请搜索狼蚁SEO以前的文章或继续浏览狼蚁网站SEO优化的相关文章希望大家以后多多支持狼蚁SEO!
编程语言
- 宿迁百度关键词排名指南:实现精准营销的关键
- 四川SEO优化怎么做网络推广
- 立昂技术备案老域名收购:如何为您的业务赋能
- 安徽百度关键词seo贵不贵,一般需要多少钱
- 吉林百度快照排名怎么做电话营销
- 多伦新手做SEO怎么做
- 甘肃优化关键词排名推广怎么做论坛营销
- 沙雅SEO网站推广:提升您的在线可见性
- 四川SEO优化如何提升销售额和销售量
- 聂荣网站排名优化:提升网站可见性的全方位指
- 涞水SEO:提升地方企业在线可见性的策略
- 辽宁百度seo排名怎样做网站排名
- 临湘哪有关键词排名优化:提升网站可见度的关
- 黑龙江百度网站优化有没有优惠
- 凉城优化关键词排名推广:提升您的网络可见性
- 萝北整站优化:提升您网站流量和排名的全面指