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

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

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

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

一、主從優(yōu)勢(shì)

其中Master主服務(wù)器負(fù)責(zé)寫操作的負(fù)載，也就是說(shuō)一切寫的操作都在Master上，而讀的操作則分?jǐn)偟絊lave從服務(wù)器上，這樣一來(lái)的可以大大提高讀取的效率。

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

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

二、復(fù)制過(guò)程

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

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

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

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

(1)、主庫(kù)延遲問(wèn)題

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

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

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

(2)、從庫(kù)同步延遲問(wèn)題

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

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

Master_Log_File：SLAVE中的I/O線程當(dāng)前正在讀取的主服務(wù)器二進(jìn)制日志文件的名稱Read_Master_Log_Pos：在當(dāng)前的主服務(wù)器二進(jìn)制日志中，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ù)器二進(jìn)制日志文件的名稱Slave_IO_Running：I/O線程是否被啟動(dòng)并成功地連接到主服務(wù)器上

Slave_SQL_Running：SQL線程是否被啟動(dòng)

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

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

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

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

2)、DDL的IO問(wèn)題

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

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

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

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

2)、硬件方面

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

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

3)、mysql主從同步加速

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

4)、磁盤IO上操作

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

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

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

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

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

2)、解決方法：

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

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

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

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

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

● 性能有一定的降低，響應(yīng)時(shí)間會(huì)更長(zhǎng)

● 網(wǎng)絡(luò)異?；驈膸?kù)宕機(jī)，卡主主庫(kù)，直到超時(shí)或從庫(kù)恢復(fù)

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

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

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

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

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

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

總 結(jié)

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

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

總結(jié)

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

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