最近在做zabbix的數(shù)據(jù)庫(kù)MySQL5.6升級(jí)5.7時(shí)，出現(xiàn)主從延遲問(wèn)題，這個(gè)問(wèn)題困擾了很久沒有解決，昨天終于解決了，整理了一下整個(gè)排查過(guò)程，分享給大家。

環(huán)境說(shuō)明：

mysql主庫(kù)為5.6的版本，有四個(gè)從庫(kù)，三個(gè)為5.6的版本，一個(gè)為5.7的版本，所有主從的庫(kù)表結(jié)構(gòu)均一致，5.7的從庫(kù)出現(xiàn)大量延遲，5.6的沒問(wèn)題，業(yè)務(wù)為zabbix監(jiān)控，基本全部為insert批量插入操作，每條insert SQL插入數(shù)據(jù)為400-1000行左右。

問(wèn)題：

MySQL5.7的從庫(kù)大量延遲，relaylog落盤正常，應(yīng)用到數(shù)據(jù)庫(kù)比較慢，磁盤IO和CPU沒有壓力，sync_binlog為20000或是0沒有區(qū)別，max_allowed_packet=128M，innodb_flush_log_at_trx_commit=0，bulk_insert_buffer_size = 128M，binlog_format=row，sync_relay_log=10000,沒有使用并行復(fù)制,沒有開啟SSL，沒有開啟GDID，沒有開啟半同步。

排查過(guò)程：

1：檢查各個(gè)核對(duì)各個(gè)和性能相關(guān)的參數(shù)，沒有發(fā)現(xiàn)異常。

2：檢查網(wǎng)卡、硬盤、更換服務(wù)器、數(shù)據(jù)庫(kù)服務(wù)器重啟均沒有效果，5.7的延遲依然存在，排除硬件問(wèn)題。

3：5.7同步主庫(kù)5.6的binlog到relaylog很快，正常，但是relaylog在5.7數(shù)據(jù)庫(kù)中回放效率極低。

4：對(duì)比5.6和5.7從庫(kù)的show engine innodb status結(jié)果：

=============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]
+++++++++++++++++++++++

對(duì)比發(fā)現(xiàn)5.7中unzip存在數(shù)值，5.6的沒有，初步懷疑造成延遲的原因和壓縮解壓相關(guān)。

5：使用perf top -p pidof mysqld查看5.7從庫(kù)

發(fā)現(xiàn)libz.so.1.2.7 [.] crc32的占比要高于mysqld，在6%左右，這個(gè)庫(kù)和壓縮解壓相關(guān)。

6：修改innodb_compression_level的等級(jí)為0（就是不啟用壓縮，默認(rèn)為6，范圍為0-9），觀察無(wú)效果，延遲依然存在。只是

libz的占比下去了，但libc-2.17.so的占比上去了，比mysqld高，在9%左右。使用pstack查看存在研所解壓的等待的問(wèn)題。

7：檢查zabbix的歷史表，當(dāng)時(shí)為了節(jié)約磁盤空間，對(duì)這些表做了壓縮處理：

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這個(gè)壓縮參數(shù)相關(guān)。

8：重建所有歷史表，去掉ROW_FORMAT=COMPRESSED KEY_BLOCK_SIZE=8，，重新同步，延遲逐步降低，恢復(fù)。

疑問(wèn)：為什么相同的表結(jié)構(gòu)，在5.7中會(huì)造成主從延遲而5.6沒有？可能是壓縮和解壓在MySQL5.7中向下兼容性問(wèn)題造成的，沒有深究，但給官方提了一個(gè)BUG，讓官方走源碼層面去看看：http://bugs.mysql.com/100702。

在生產(chǎn)中請(qǐng)慎用ROW_FORMAT=COMPRESSED KEY_BLOCK_SIZE=8。和業(yè)內(nèi)幾位專家交流，表示MySQL8.0之前的版本壓縮不太靠譜，8.0的用ZSTD還好一點(diǎn)。

到此這篇關(guān)于MySQL5.6升級(jí)5.7時(shí)出現(xiàn)主從延遲問(wèn)題排查過(guò)程的文章就介紹到這了,更多相關(guān)MySQL5.6升級(jí)5.7主從延遲內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！