温州网站推广优化,wordpress discuz插件,淘宝客领券网站怎么做,青岛做商城网站最近在做zabbix的数据库MySQL5.6升级5.7时#xff0c;出现主从延迟问题#xff0c;这个问题困扰了很久没有解决#xff0c;昨天终于解决了#xff0c;整理了一下整个排查过程#xff0c;分享给大家。环境说明#xff1a;mysql主库为5.6的版本#xff0c;有四个从库…最近在做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_packet128Minnodb_flush_log_at_trx_commit0bulk_insert_buffer_size 128Mbinlog_formatrowsync_relay_log10000,没有使用并行复制,没有开启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 1Buffer pool size 655359Buffer pool size, bytes 10737401856Free buffers 1019Database pages 649599Old database pages 239773Modified db pages 119309Pending reads 0Pending writes: LRU 0, flush list 0, single page 0Pages made young 10777670, not young 18111924613.90 youngs/s, 157.51 non-youngs/sPages read 8853516, created 135760152, written 78451480320.96 reads/s, 58.17 creates/s, 507.02 writes/sBuffer pool hit rate 1000 / 1000, young-making rate 0 / 1000 not 2 / 1000Pages read ahead 0.00/s, evicted without access 0.00/s, Random read ahead 0.00/sLRU len: 649599, unzip_LRU len: 0I/O sum[209618]:cur[2], unzip sum[0]:cur[0]5.7---BUFFER POOL 1Buffer pool size 819100Buffer pool size, bytes 13420134400Free buffers 1018Database pages 722328Old database pages 266620Modified db pages 99073Pending reads 0Pending writes: LRU 0, flush list 0, single page 0Pages made young 37153, not young 7950.00 youngs/s, 0.00 non-youngs/sPages read 149632, created 572696, written 27063690.00 reads/s, 0.00 creates/s, 0.00 writes/sBuffer pool hit rate 1000 / 1000, young-making rate 0 / 1000 not 0 / 1000Pages read ahead 0.00/s, evicted without access 0.00/s, Random read ahead 0.00/sLRU len: 722328, unzip_LRU len: 453903I/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)) ENGINEInnoDB DEFAULT CHARSETutf8 ROW_FORMATCOMPRESSED KEY_BLOCK_SIZE8怀疑和ROW_FORMATCOMPRESSED KEY_BLOCK_SIZE8这个压缩参数相关。8重建所有历史表去掉ROW_FORMATCOMPRESSED KEY_BLOCK_SIZE8重新同步延迟逐步降低恢复。疑问为什么相同的表结构在5.7中会造成主从延迟而5.6没有可能是压缩和解压在MySQL5.7中向下兼容性问题造成的没有深究但给官方提了一个BUG让官方走源码层面去看看http://bugs.mysql.com/100702。在生产中请慎用ROW_FORMATCOMPRESSED KEY_BLOCK_SIZE8。和业内几位专家交流表示MySQL8.0之前的版本压缩不太靠谱8.0的用ZSTD还好一点。到此这篇关于MySQL5.6升级5.7时出现主从延迟问题排查过程的文章就介绍到这了,更多相关MySQL5.6升级5.7主从延迟内容请搜索我们以前的文章或继续浏览下面的相关文章希望大家以后多多支持我们本文标题: MySQL5.6升级5.7时出现主从延迟问题排查过程本文地址: http://www.cppcns.com/shujuku/mysql/342435.html
