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

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

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

好了，我們這一節(jié)正要講解同步延遲問題，解決掉數(shù)據(jù)同步延遲問題。

一、主從優(yōu)勢

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

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

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

二、復(fù)制過程

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

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

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

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

(1)、主庫延遲問題

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

首要原因：數(shù)據(jù)庫在業(yè)務(wù)上讀寫壓力太大，CPU計算負荷大，網(wǎng)卡負荷大，硬盤隨機IO太高。

次要原因：讀寫binlog帶來的性能影響，網(wǎng)絡(luò)傳輸延遲。

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

1)、相關(guān)同步參數(shù):

首先在服務(wù)器上執(zhí)行show slave satus;　

Master_Log_File：SLAVE中的I/O線程當(dāng)前正在讀取的主服務(wù)器二進制日志文件的名稱Read_Master_Log_Pos：在當(dāng)前的主服務(wù)器二進制日志中，SLAVE中的I/O線程已經(jīng)讀取的位置

Relay_Log_File：SQL線程當(dāng)前正在讀取和執(zhí)行的中繼日志文件的名稱

Relay_Log_Pos：在當(dāng)前的中繼日志中，SQL線程已讀取和執(zhí)行的位置

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

Slave_SQL_Running：SQL線程是否被啟動

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

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

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

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

2)、DDL的IO問題

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

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

1)、架構(gòu)方面

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

2)、硬件方面

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

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

3)、mysql主從同步加速

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

4)、磁盤IO上操作

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

五、主從同步的延遲的解決數(shù)據(jù)一致性方案

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

●主庫宕機后，數(shù)據(jù)可能丟失

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

2)、解決方法：

● 半同步復(fù)制---解決數(shù)據(jù)丟失的問題

● 并行復(fù)制----解決從庫復(fù)制延遲的問題

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

● 確保事務(wù)提交后binlog至少傳輸?shù)揭粋€從庫

● 不保證從庫應(yīng)用完這個事務(wù)的binlog

● 性能有一定的降低，響應(yīng)時間會更長

● 網(wǎng)絡(luò)異?；驈膸戾礄C，卡主主庫，直到超時或從庫恢復(fù)

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

a、異步復(fù)制原理

(圖片來源于網(wǎng)絡(luò))

b、半同步復(fù)制原理

(圖片來源于網(wǎng)絡(luò))

事務(wù)在主庫寫完binlog后需要從庫返回一個已接受,才放回給客戶端；確保事務(wù)提交后binlog至少傳輸?shù)揭粋€從庫不保證從庫應(yīng)用完成這個事務(wù)的binlog性能有一定的降低網(wǎng)絡(luò)異?；驈膸戾礄C,卡主庫,直到超時或從庫恢復(fù)、mysql并行復(fù)制 。

總 結(jié)

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

更多內(nèi)容請關(guān)注公眾號(Laravel技術(shù)社區(qū))

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。