MySQL 主從同步延遲的緣由及解決辦法

mysql 用主從同步的方法進行讀寫分離，減輕主服務器的壓力的作法如今在業內作的很是廣泛。 主從同步基本上能作到實時同步。我從別的網站借用了主從同步的原理圖。

 

 

在配置好了， 主從同步之後， 主服務器會把更新語句寫入binlog, 從服務器的IO 線程(這裏要注意， 5.6.3 以前的IO線程僅有一個，5.6.3以後的有多線程去讀了，速度天然也就加快了)回去讀取主服務器的binlog 而且寫到從服務器的Relay log 裏面，而後從服務器的 的SQL thread 會一個一個執行 relay log 裏面的sql ， 進行數據恢復。

 

relay 就是 傳遞, relay race 就是接力賽的意思

 

1. 主從同步的延遲的緣由

咱們知道， 一個服務器開放Ｎ個連接給客戶端來鏈接的，　這樣有會有大併發的更新操做, 可是從服務器的裏面讀取binlog 的線程僅有一個， 當某個SQL在從服務器上執行的時間稍長 或者因爲某個SQL要進行鎖表就會致使，主服務器的SQL大量積壓，未被同步到從服務器裏。這就致使了主從不一致， 也就是主從延遲。

 

2. 主從同步延遲的解決辦法

實際上主從同步延遲根本沒有什麼一招制敵的辦法， 由於全部的SQL必須都要在從服務器裏面執行一遍，可是主服務器若是不斷的有更新操做源源不斷的寫入， 那麼一旦有延遲產生， 那麼延遲加劇的可能性就會原來越大。 固然咱們能夠作一些緩解的措施。

a. 咱們知道由於主服務器要負責更新操做， 他對安全性的要求比從服務器高， 全部有些設置能夠修改，好比sync_binlog=1，innodb_flush_log_at_trx_commit = 1 之類的設置，而slave則不須要這麼高的數據安全，徹底能夠講sync_binlog設置爲0或者關閉binlog，innodb_flushlog，innodb_flush_log_at_trx_commit 也 能夠設置爲0來提升sql的執行效率 這個能很大程度上提升效率。另外就是使用比主庫更好的硬件設備做爲slave。

b. 就是把，一臺從服務器當度做爲備份使用， 而不提供查詢， 那邊他的負載下來了， 執行relay log 裏面的SQL效率天然就高了。

c. 增長從服務器嘍，這個目的仍是分散讀的壓力， 從而下降服務器負載。

 

3. 判斷主從延遲的方法

MySQL提供了從服務器狀態命令，能夠經過 show slave status 進行查看， 好比能夠看看Seconds_Behind_Master參數的值來判斷，是否有發生主從延時。其值有這麼幾種：NULL - 表示io_thread或是sql_thread有任何一個發生故障，也就是該線程的Running狀態是No,而非Yes.0 - 該值爲零，是咱們極爲渴望看到的狀況，表示主從複製狀態正常