上一節我們成功搭建了主從復制、讀寫分離，實際上并發量和數據量不大的情況下，使用起來也是非常的流暢，無任何問題，可以正常運行了。

但是，要保證高可用，高并發的情況，可以寫數據庫master就有累了，從服務器slave讀取數據也很累，在復制的過程中就產生了數據同步延遲問題，導致主服務器上有數據，從服務器沒有數據情況，最終導致讀寫分離失效，訪問數據失敗。

有的網友就說我們可以升級主服務器的配置來解決，我說可以解決暫時的，一臺服務器再怎么升級也有極限，如果使用多臺服務器并且可以擴容的話，我們不是很好處理這個問題嗎？

好了，我們這一節正要講解同步延遲問題，解決掉數據同步延遲問題。

一、主從優勢

其中Master主服務器負責寫操作的負載，也就是說一切寫的操作都在Master上，而讀的操作則分攤到Slave從服務器上，這樣一來的可以大大提高讀取的效率。

為什么要分離讀和寫呢？寫操作涉及到鎖的問題，不管是行鎖還是表鎖還是塊鎖，都是比較降低系統執行效率的事情。

我們這樣的分離是把寫操作集中在一個節點上，而讀操作其他的N個節點上進行，有效的提高了讀的效率，保證了系統的高可用性。

二、復制過程

1)、Mysql的主從同步就是當master(主庫)發生數據變化的時候，會實時同步到slave(從庫)。

2)、主從復制可以水平擴展數據庫的負載能力，容錯，高可用，數據備份。

3)、不管是delete、update、insert都是在master上，當master有操作的時候，slave會快速的接受到這些操作，從而做同步。

三、主從同步的延遲的原因：

(1)、主庫延遲問題

當主庫的TPS并發較高時，產生的DDL數量超過slave一個sql線程所能承受的范圍，那么延時就產生了，當然還有就是可能與slave的大型query語句產生了鎖等待。

首要原因：數據庫在業務上讀寫壓力太大，CPU計算負荷大，網卡負荷大，硬盤隨機IO太高。

次要原因：讀寫binlog帶來的性能影響，網絡傳輸延遲。

(2)、從庫同步延遲問題

1)、相關同步參數:

首先在服務器上執行show slave satus;　

Master_Log_File：SLAVE中的I/O線程當前正在讀取的主服務器二進制日志文件的名稱Read_Master_Log_Pos：在當前的主服務器二進制日志中，SLAVE中的I/O線程已經讀取的位置

Relay_Log_File：SQL線程當前正在讀取和執行的中繼日志文件的名稱

Relay_Log_Pos：在當前的中繼日志中，SQL線程已讀取和執行的位置

Relay_Master_Log_File：由SQL線程執行的包含多數近期事件的主服務器二進制日志文件的名稱Slave_IO_Running：I/O線程是否被啟動并成功地連接到主服務器上

Slave_SQL_Running：SQL線程是否被啟動

Seconds_Behind_Master：從屬服務器SQL線程和從屬服務器I/O線程之間的時間差距，單位以秒計。

● show slave status顯示參數Seconds_Behind_Master不為0，這個數值可能會很大

● show slave status顯示參數Relay_Master_Log_File和Master_Log_File顯示bin-log的編號相差很大，說明bin-log在從庫上沒有及時同步，所以近期執行的bin-log和當前IO線程所讀的bin-log相差很大

● mysql從庫數據目錄下存在大量mysql-relay-log日志，該日志同步完成之后就會被系統自動刪除，存在大量日志，說明主從同步延遲很厲害。

2)、DDL的IO問題

DML和DDL的IO操作是隨機的,不是順序的，成本高很多，還可能slave上的其他查詢產生lock爭用，由于Slave_SQL_Running也是單線程的，所以一個DDL卡主了，需要執行10分鐘，那么所有之后的DDL會等待這個DDL執行完才會繼續執行，這就導致了延遲，比如:"主庫上那個相同的DDL也需要執行5分鐘，為什么slave會延時?",答案是master可以并發,Slave_SQL_Running線程卻不可以。

四、主從同步的延遲的解決方案(重點)：

1)、架構方面

• 業務的持久化層的實現采用分庫架構，mysql服務可平行擴展，分散壓力。
• 單個庫讀寫分離，一主多從，主寫從讀，分散壓力。這樣從庫壓力比主庫高，保護主庫。
• 服務的基礎架構在業務和mysql之間加入memcache或者redis的cache層。降低mysql的讀壓力。
• 不同業務的mysql物理上放在不同機器，分散壓力。

2)、硬件方面

• 采用好服務器，比如4u比2u性能明顯好，2u比1u性能明顯好。
• 存儲用ssd或者盤陣或者san，提升隨機寫的性能。
• 主從間保證處在同一個交換機下面，并且是萬兆環境。

總結，硬件強勁，延遲自然會變小。一句話，縮小延遲的解決方案就是花錢和花時間。

3)、mysql主從同步加速

• sync_binlog在slave端設置為0
• logs-slave-updates 從服務器從主服務器接收到的更新不記入它的二進制日志。
• 直接禁用slave端的binlog
• slave端，如果使用的存儲引擎是innodb，設置innodb_flush_log_at_trx_commit =2

4)、磁盤IO上操作

從文件系統本身屬性角度優化master端修改linux、Unix文件系統中文件的etime屬性， 由于每當讀文件時OS都會將讀取操作發生的時間回寫到磁盤上，對于讀操作頻繁的數據庫文件來說這是沒必要的，只會增加磁盤系統的負擔影響I/O性能。

五、主從同步的延遲的解決數據一致性方案

1)、主從復制存在的問題：

●主庫宕機后，數據可能丟失

●從庫只有一個sql Thread，主庫寫壓力大，復制很可能延時

2)、解決方法：

● 半同步復制---解決數據丟失的問題

● 并行復制----解決從庫復制延遲的問題

3)、半同步復制mysql semi-sync(半同步復制)半同步復制

● 確保事務提交后binlog至少傳輸到一個從庫

● 不保證從庫應用完這個事務的binlog

● 性能有一定的降低，響應時間會更長

● 網絡異常或從庫宕機，卡主主庫，直到超時或從庫恢復

4)、主從復制--異步復制原理、半同步復制和并行復制原理比較

a、異步復制原理

(圖片來源于網絡)

b、半同步復制原理

(圖片來源于網絡)

事務在主庫寫完binlog后需要從庫返回一個已接受,才放回給客戶端；確保事務提交后binlog至少傳輸到一個從庫不保證從庫應用完成這個事務的binlog性能有一定的降低網絡異常或從庫宕機,卡主庫,直到超時或從庫恢復、mysql并行復制 。

總 結

以上寫了那么多內容，主要查找主服務器和從服務器之間的問題，因為數據同步的過程就是服務器之間的數據傳輸，所以，我們需要把觀察問題所在，才好更好的解決問題，把數據延遲問題解決掉。

更多內容請關注公眾號(Laravel技術社區)

總結

以上是生活随笔為你收集整理的mysql集群和主从区别_搭建MySQL主从集群，主从复制过程中同步延迟问题的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。