MySQL復(fù)制滯后、延遲問題及解決方法

確認(rèn)復(fù)制延遲的方法

執(zhí)行

mysql>show slave status\G

如果"seconds_behind_master"不為"0"，需要對其關(guān)注，并調(diào)查其產(chǎn)生的根本原因

首先需要確認(rèn)滯后的原因會來自兩方面，來自IO_Thread （比如網(wǎng)絡(luò)連接速度慢，磁盤慢）或 SQL_Thread（施放中繼日志里面的SQL過慢）

執(zhí)行

mysql>show master status\G

Slave_IO_Running: Yes

Slave_SQL_Running: Yes

確認(rèn)一下兩個線程是否運(yùn)行，如果沒有正常運(yùn)行，確認(rèn)一下錯誤日志里面的內(nèi)容，然后使其運(yùn)行。

接下來需要確認(rèn)，是否

Master_log_file

Relay_Master_Log_File

Read_Master_Log_Pos

Exec_Master_Log_Pos

值相等，但是Seconds_Behind_Master從未減少。

然后在主服務(wù)上執(zhí)行SHOW MASTER STATUS，確認(rèn)當(dāng)前主服務(wù)的日志文件和位置，Exec_Master_Log_Pos 是否落后 Read_Master_Log_Pos。

解決方法

如果從服務(wù)有多臺的情況下，檢查：

全部的主機(jī)是否使用相同的硬件

是否使用同一版本的MySQL（從服務(wù)器的版本應(yīng)等于或高于主服務(wù)器版本）

檢查路由、網(wǎng)絡(luò)防火墻

IO 線程滯后

通常是網(wǎng)絡(luò)原因或者飽和原因

使用大容量的binlog

檢查網(wǎng)絡(luò)和磁盤的速度

SQL 線程滯后

1 、檢查在從服務(wù)器上執(zhí)行過長的事務(wù)

2 、檢查在從服務(wù)器上活動集中的IO操作

停止IO線程，確認(rèn)問題是否解決

改變innodb_flush_log_at_trx_commit參數(shù)，確認(rèn)是否解決，嘗試改為0，確認(rèn)一下結(jié)果，最終可以嘗試改為2。

減少max_relay_log_size值 避免讀取負(fù)載過大，例如8M mysql> set global max_relay_log_size = 8*1024*1024;

檢查從服務(wù)器沒有使用 log_slave_updates = 1

3 、考慮使用  Multi Threaded Slave (MTS)

4 、確認(rèn)是否過多的表沒有使用主鍵

如果日志采用row或MIXED格式，如果表沒有主鍵，會引起延遲。

這是因為當(dāng)在主服務(wù)器上執(zhí)行事務(wù)時，可以使用任何可用的鍵或直接的表掃描，

當(dāng)在從服務(wù)器SQL上應(yīng)用行事件時不使用這些。

從主服務(wù)器的二進(jìn)制日志中的行事件被逐行地應(yīng)用到從服務(wù)器的匹配行映像時，

如果使用主鍵惟一地標(biāo)識每一行時，就可以快速地將更改應(yīng)用到從服務(wù)器的適當(dāng)?shù)男杏诚瘛?

然而，當(dāng)沒有定義主鍵時，對于主服務(wù)器上的每一個受影響的行，整個行映像都必須逐行進(jìn)行比較。

5 、在MySQL 5.7中如果持續(xù)的統(tǒng)計特性會對MySQL復(fù)制產(chǎn)生負(fù)面影響就會禁用它并檢查是否有任何改進(jìn)。