本篇文章給大家分享的是有關(guān)MySQL升級時出現(xiàn)主從延遲怎么解決,小編覺得挺實用的,因此分享給大家學(xué)習(xí),希望大家閱讀完這篇文章后可以有所收獲,話不多說,跟著小編一起來看看吧。
創(chuàng)新互聯(lián)公司是一家集網(wǎng)站建設(shè),于都企業(yè)網(wǎng)站建設(shè),于都品牌網(wǎng)站建設(shè),網(wǎng)站定制,于都網(wǎng)站建設(shè)報價,網(wǎng)絡(luò)營銷,網(wǎng)絡(luò)優(yōu)化,于都網(wǎng)站推廣為一體的創(chuàng)新建站企業(yè),幫助傳統(tǒng)企業(yè)提升企業(yè)形象加強企業(yè)競爭力??沙浞譂M足這一群體相比中小企業(yè)更為豐富、高端、多元的互聯(lián)網(wǎng)需求。同時我們時刻保持專業(yè)、時尚、前沿,時刻以成就客戶成長自我,堅持不斷學(xué)習(xí)、思考、沉淀、凈化自己,讓我們?yōu)楦嗟钠髽I(yè)打造出實用型網(wǎng)站。環(huán)境說明:
mysql主庫為5.6的版本,有四個從庫,三個為5.6的版本,一個為5.7的版本,所有主從的庫表結(jié)構(gòu)均一致,5.7的從庫出現(xiàn)大量延遲,5.6的沒問題,業(yè)務(wù)為zabbix監(jiān)控,基本全部為insert批量插入操作,每條insert SQL插入數(shù)據(jù)為400-1000行左右。
問題:
MySQL5.7的從庫大量延遲,relaylog落盤正常,應(yīng)用到數(shù)據(jù)庫比較慢,磁盤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,沒有開啟半同步。
排查過程:
1:檢查各個核對各個和性能相關(guān)的參數(shù),沒有發(fā)現(xiàn)異常。
2:檢查網(wǎng)卡、硬盤、更換服務(wù)器、數(shù)據(jù)庫服務(wù)器重啟均沒有效果,5.7的延遲依然存在,排除硬件問題。
3:5.7同步主庫5.6的binlog到relaylog很快,正常,但是relaylog在5.7數(shù)據(jù)庫中回放效率極低。
4:對比5.6和5.7從庫的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]