一直以來(lái)，都是聽(tīng)到 mysql 5.7已 消除了延遲，但我們測(cè)試環(huán)境主從一直存在延遲。
找了很多原因，但一直不理想，直接到找參數(shù)：sync_relay_log　，在討論主從延遲時(shí)，很少會(huì)說(shuō)到這個(gè)參數(shù)。
因?yàn)樗J(rèn)是　１００００．也正是這樣，容易被忽略。

×××××××××××××××××××××××××××××××××××××××××××××××××××××

innodb_flush_log_at_trx_commit：是 InnoDB 引擎特有的，
ib_logfile的刷新方式（ ib_logfile：記錄的是redo log和undo log的信息）

innodb_flush_log_at_trx_commit= 2
sync_binlog = 500

#sync_relay_log，這個(gè)參數(shù)用來(lái)保證relay log的安全 功能類(lèi)似于 sync_binlog 參數(shù)
sql_thread 讀取主節(jié)點(diǎn)同步過(guò)來(lái)的日志進(jìn)行重解析為sql，并刷新到relay_log 文件中。
這個(gè)參數(shù)默認(rèn)就是 10000 ，在不明所以的情況下，被設(shè)置成了 sync_relay_log=1 ,
坑太大，測(cè)試了半天才知道是這個(gè)參數(shù)引起的大延遲。
這個(gè)參數(shù)不常用，很少會(huì)被設(shè)置成1，被它害慘了。

sync_relay_log = 10000 #寫(xiě)10000個(gè)event才fsync一次寫(xiě)盤(pán)
sync_relay_log_info = 10000
sync_master_info = 10000

relay_log_recovery=1 #保證relay-log的完整性

#多線(xiàn)程 sql_thread 重解析，以加快同步
slave-parallel-type=LOGICAL_CLOCK #行級(jí)別多線(xiàn)程
slave-parallel-workers=16 #線(xiàn)程數(shù)量
master-info-repository=TABLE #
relay-log-info-repository=TABLE #

log_slave_updates=1

#緩存刷新方式，IO優(yōu)化
innodb_flush_method=O_DIRECT

總結(jié)

以上是生活随笔為你收集整理的mysql 5.7主从延迟 相关参数配置的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。