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 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,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,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,value_max double(16,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,讓官方走原始碼層面去看看:http://bugs.mysql.com/100702。
在生產中請慎用ROW_FORMAT=COMPRESSED KEY_BLOCK_SIZE=8。和業內幾位專家交流,表示MySQL8.0之前的版本壓縮不太靠譜,8.0的用ZSTD還好一點。
到此這篇關於MySQL5.6升級5.7時出現主從延遲問題排查過程的文章就介紹到這了,更多相關MySQL5.6升級5.7主從延遲內容請搜尋我們以前的文章或繼續瀏覽下面的相關文章希望大家以後多多支援我們!