當從庫跟不上主庫的更新進度時就會出現同步(複製)延遲,這時在從庫裏,未同步的修改在relay_log裏出現堆積,數據的版本也會漸漸跟主庫差異愈來愈大。mysql
爲了肯定延遲的緣由,咱們須要肯定是哪一個複製線程出現問題了。在mysql中,一對主從同步的鏈接依賴三個不一樣的線程,其中兩個由從庫建立,一個由主庫建立。sql
I/o線程
:當你在從庫經過Start Slave
命令配置了主庫同步信息後,這個線程就會被從庫建立。用來請求主庫binlog日誌的備份Bin log Dump線程
: 當從庫連上主庫後,這個線程就會被建立,而後會將其binlog發送給從庫。Slave SQL 線程
: 從庫建立這個線程,而後從獲取的binlog裏讀取內容並應用。當I/O線程或SQL線程沒法處理對其提出的要求時,會致使複製延遲。網絡
slave_compressed_protocol
選項進行數據壓縮此種同步方式下使用Show master status
和show slave statue
命令能夠查看你須要的信息,好比: Show master status命令看到的:oracle
postion
-Read_Master_Log_Pos
得到你的IO線程落後主庫日誌的字節數postion
-Exec_Master_Log_Pos
得到你的SQL線程落後主庫日誌的字節數Read_Master_Log_Pos
-Exec_Master_Log_Pos
得到你的SQL線程落後IO的字節數 Show slave status命令看到的:seconds_behind_master
能夠參考落後主庫的秒數,不過不要過分依賴它,由於它的統計方式不是很準確得到GTID後,你能夠使用GTID_SUBTRACT()
函數計算從庫與主庫的差別。例如,如下對從庫查詢顯示從二進制日誌中讀取的還沒有應用的GTID(SQL線程延遲):ide
slave> SELECT GTID_SUBTRACT('96985d6f-2ebc-11e7-84df-08002715584a:5-133',
'96985d6f-2ebc-11e7-84df-08002715584a:26-132') AS MissingGTIDs;
+-----------------------------------------------+
| MissingGTIDs |
+-----------------------------------------------+
| 96985d6f-2ebc-11e7-84df-08002715584a:5-25:133 |
+-----------------------------------------------+
1 row in set (0.00 sec)
複製代碼
經過GTIDs【global transaction identifiers】,能夠標識每個事務,而且能夠在其一旦提交追蹤並應用於任何一個Slave上;這樣 就不須要像BinaryLog複製依賴Log file 和位置。GTIDs徹底基於事務,只要在Master提交的全部事務都在Slave上進行了Commit,那麼就能保證Master和Slave之間的數據 一致性。你能夠使用基於SBR或RBR的GTIDs來實現。推薦使用RBR【Row-based replication】.函數