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 size 819100

Buffer pool size, bytes 13420134400

Free buffers 1018

Database pages 722328

Old database pages 266620

Modified db pages 99073

Pending reads 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

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

value_min

double(16,4) NOT NULL DEFAULT '0.0000',

value_avg

value_max

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這個壓縮參數相關。