本篇文章給大家分享的是有關MySQL升級時出現主從延遲怎么解決，小編覺得挺實用的，因此分享給大家學習，希望大家閱讀完這篇文章后可以有所收獲，話不多說，跟著小編一起來看看吧。
環境說明：
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，，重新同步，延遲逐步降低，恢復。
在生產中請慎用ROW_FORMAT=COMPRESSED KEY_BLOCK_SIZE=8。和業內幾位專家交流，表示MySQL8.0之前的版本壓縮不太靠譜，8.0的用ZSTD還好一點。
以上就是MySQL升級時出現主從延遲怎么解決，小編相信有部分知識點可能是我們日常工作會見到或用到的。希望你能通過這篇文章學到更多知識。更多詳情敬請關注億速云行業資訊頻道。
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
