mysql主從複製延遲問題的相關知識與解決方案

 

 

 

 

 

 

 

 

1、如何監控發生了主從延遲？

 

在從庫機器上，執行show slave status，查看Seconds_Behind_Master值，表明主從同步從庫落後主庫的時間，單位爲秒，若同從同步無延遲，這個值爲0。

 

Mysql主從延遲一個重要的緣由之一是：mysql是以單線程串行執行。

 

主從複製數據時，在從服務器上的mysql，是一個線程在同步數據。

串行的方式，它是指，執行一個後才繼續執行下一個。若是一個卡住了，要等待時間，纔會繼續下一個。串行與並行是相反的。

 

 

2、同步延遲發生的場景

 

當主庫的TPS併發較高時，產生的DDL(修改類的sql語句)數量，超過了slave機器sql線程所能承受的能力，那麼延時就會產生了。

 

主庫寫binlog日誌到文件的時候，是順序寫入到磁盤，順序寫入速度是很快，避免了磁盤隨機尋址。

 

從庫的同步線程(Slave_IO_Running)，將binlog在slave上執行的時候，其實是隨機的，速度確定要慢點。

 

 從庫的同步線程(Slave_IO_Running)只有應該線程在操做，整個mysql實例就一個這樣的線程，那麼，若是mysql有n個庫的數據須要同步，所有要這個線程來處理。人手不夠啊(mysql-5.6.3)

 

 

 

3、解決思路

 

如何避免或解決主從延遲？能夠用來解決的辦法，有以下的:

 

• 從庫優化Mysql參數。好比增大innodb_buffer_pool_size，讓更多操做在Mysql內存中完成，減小磁盤操做。

• 從庫使用高性能主機。包括cpu強悍、內存加大。避免使用虛擬雲主機，使用物理主機，這樣提高了i/o方面性。

• 從庫使用SSD磁盤。機械硬盤是靠磁頭旋轉到指定位置來讀數據、寫數據。轉來轉去的，咱們叫作i/o。磁盤i/o存在速度瓶頸。固態硬盤是一個電子設備，電子設備不須要機械旋轉，讀寫固態硬盤上任意位置的數據，速度都是同樣的。

• 業務代碼的妥協。將實時性要求高的某些操做，使用主庫作讀操做。好比我寫了數據到主庫了，須要立刻展現數據，不要到從庫去讀數據，由於從庫可能還沒同步過去呢。直接從主庫讀數據，保證是最新的數據展現。

• 從庫的線程改成多個同步線程同步數據。mysql-5.6.3爲了解決這個問題，從服務器上，每個庫開一個線程來同步。
• 網絡優化。網絡堵塞，也會致使同步延遲。跨機房的數據庫同步，會存在同步延遲。保證主從在同一個機房裏面去。

 

 

 

 

 

附：mysql主從複製的三種格式數據

 

第一種是，statement格式。也就是記錄下原來執行的sql語句。

 

這是最先的一種方式，後來發現也不是很完美，在複製的過程當中會存在一些問題。

舉例：因爲sql語句中使用了某些mysql函數，而這個mysql函數是特定版本纔有的，其餘版本是沒有這個函數，放到slave端運行，假如slave的mysql版本不同，就可能執行出現問題。

 

使用了特定的功能，若是sql中使用了last_insert_id()函數，當一樣的sql語句複製到slave端執行的時候，last_insert_id()所獲得的結果是不一樣的。

 

上面兩種狀況致使了：複製過程當中，slave端的結果沒有徹底與master端一致了。

而基於row格式的就不會。因而發明了row格式的。

 

第二種，基於row格式的。會記錄下每一行修改前和修改後的值。binlog中存儲的就是被修改行的修改前和修改後的值，直接拿到結果便可。重作。

基於row的格式有個缺點：涉及到ddl操做，好比alter table，加一個字段，那麼意味着整個表的行都要進行修改。那麼binlog中記錄的是整個表中行的數據，形成binlog中的數據量很大。

因而，又發明了基於statement格式和基於row格式的綜合版，叫作mixed

 

第三種：mixed

 

遇到ddl表變動操做，則使用statement格式，遇到delete或update格式，則使用row格式。

 

 

三種格式的發展過程總結：

 

一直使用statement格式，到了5.1.5版本才支持row格式。後來存儲過程的出現，又帶來了新的問題。存儲過程當中調用一些函數，在slave端運行結果會不一樣。因此5.1.8版本開始支持mixed格式。上面全部策略的作法目標是，讓master與slave的數據保持一致。從這個角度出發。