您好,登錄后才能下訂單哦!
本篇文章給大家分享的是有關(guān)MySQL中主從不同步如何解決,小編覺(jué)得挺實(shí)用的,因此分享給大家學(xué)習(xí),希望大家閱讀完這篇文章后可以有所收獲,話不多說(shuō),跟著小編一起來(lái)看看吧。
- 思維導(dǎo)圖 -
主從常見(jiàn)架構(gòu)
隨著日益增長(zhǎng)的訪問(wèn)量,單臺(tái)數(shù)據(jù)庫(kù)的應(yīng)接能力已經(jīng)捉襟見(jiàn)肘。因此采用主庫(kù)寫數(shù)據(jù),從庫(kù)讀數(shù)據(jù)這種將讀寫分離開(kāi)的主從架構(gòu)便隨之衍生了出來(lái)。
在生產(chǎn)環(huán)境中,常見(jiàn)的主從架構(gòu)有很多種,在這里給大家介紹幾種比較常見(jiàn)的架構(gòu)模式。
主從復(fù)制原理
了解了主從的基本架構(gòu)及相關(guān)配置后,下面就要進(jìn)入正題了。
對(duì)于主從來(lái)說(shuō),通常的操作是主庫(kù)用來(lái)寫入數(shù)據(jù),從庫(kù)用來(lái)讀取數(shù)據(jù)。這樣的好處是通過(guò)將讀寫壓力分散開(kāi),避免了所有的請(qǐng)求都打在主庫(kù)上。同時(shí)通過(guò)從庫(kù)進(jìn)行水平擴(kuò)展使系統(tǒng)的伸縮性及負(fù)載能力也得到了很大的提升。
但是問(wèn)題就來(lái)了,讀從庫(kù)時(shí)的數(shù)據(jù)要與主庫(kù)保持一致,那就需要主庫(kù)的數(shù)據(jù)在寫入后同步到從庫(kù)中。如何保持主庫(kù)與從庫(kù)的數(shù)據(jù)一致性,主庫(kù)又是通過(guò)什么樣的方式將數(shù)據(jù)實(shí)時(shí)同步到從庫(kù)的?
基本原理
Mysql 中主從復(fù)制時(shí)有兩個(gè)很重要的日志文件:
binlog(二進(jìn)制日志文件)
relay log(中繼日志文件)
在主從同步的過(guò)程中,主庫(kù)會(huì)將所有的操作事件記錄在 binlog 中,從庫(kù)通過(guò)開(kāi)啟一個(gè) I/O 線程保持與主庫(kù)的通信,并在一定時(shí)間間隔內(nèi)探測(cè) binlog 日志文件是否發(fā)生改變。如果 binlog 日志發(fā)生了變化,主庫(kù)生成一個(gè) binlog dump 線程向從庫(kù) I/O 線程傳送 binlog。從庫(kù)上的 I/O 線程將 binlog 復(fù)制到自己的 relay log 中。最終由從庫(kù)中的 SQL 線程讀取 relay log 中的事件重放到從庫(kù)上。
主從延遲原因
上面的流程我們已經(jīng)知道了主從復(fù)制的相關(guān)過(guò)程了,但是主庫(kù)有更新就會(huì)同步從庫(kù),那為什么會(huì)出現(xiàn)主從延遲的情況呢?
隨機(jī)重放
Mysql 主庫(kù)中寫 binlog 的操作是順序?qū)懙?,之前我們提到過(guò),磁盤的順序讀寫速度是很快的。同樣的,從庫(kù)中的 I/O 線程操作日志的速度效率也是很高的。但是別忘了,還有一個(gè) SQL 線程來(lái)進(jìn)行數(shù)據(jù)重放,而重放的過(guò)程是隨機(jī)寫盤的。到這里你應(yīng)該就明白了吧,某一時(shí)刻 relay log 里的數(shù)據(jù)來(lái)不及重放進(jìn)從庫(kù),就會(huì)產(chǎn)生主從延遲的情況。
主庫(kù)并發(fā)高
知道了從庫(kù)中 SQL 線程的重放情況,對(duì)于主庫(kù)并發(fā)高導(dǎo)致主從延遲肯定就不難理解了。某一時(shí)刻,大量寫請(qǐng)求打到主庫(kù)上,意味著要不斷對(duì) binlog 進(jìn)行寫入,此時(shí)從庫(kù)中的 SQL 線程就會(huì)應(yīng)接不暇,自然會(huì)產(chǎn)生主從延遲。
鎖等待
對(duì)于 SQL 單線程來(lái)說(shuō),當(dāng)遇到阻塞時(shí)就會(huì)一直等待,直到執(zhí)行成功才會(huì)繼續(xù)進(jìn)行。如果某一時(shí)刻從庫(kù)因?yàn)椴樵儺a(chǎn)生了鎖等待的情況,此時(shí)只有當(dāng)前的操作執(zhí)行完成后才會(huì)進(jìn)行下面的操作,同理也就產(chǎn)生了主從延遲的情況。
主從延遲處理
知道了主從延遲的原因,接下來(lái)我們看看如何來(lái)進(jìn)行處理。
并行復(fù)制
既然 SQL 單線程進(jìn)行重放時(shí)速度有限,那么能不能采用多線程的方式來(lái)進(jìn)行重放呢?MySQL 5.6 版本后,提供了一種并行復(fù)制的方式,通過(guò)將 SQL 線程轉(zhuǎn)換為多個(gè) work 線程來(lái)進(jìn)行重放,這樣就解決了主從延遲的問(wèn)題。
降低主庫(kù)并發(fā)
你可能會(huì)說(shuō)了,我現(xiàn)在用的低版本的數(shù)據(jù)庫(kù),也沒(méi)法升版本啊,那我怎么整。對(duì)于主庫(kù)并發(fā)高的情況,這種方式你只能通過(guò)控制并發(fā)來(lái)解決延遲了,多用用 Redis。
讀主庫(kù)
這種情況你肯定不陌生,對(duì)于一些實(shí)時(shí)性要求比較高的數(shù)據(jù),你總不能讀從庫(kù)去拿吧,萬(wàn)一延遲個(gè)大半天,你不得貢獻(xiàn)自己的年終獎(jiǎng)啊。
總結(jié)
主從復(fù)制原理
主從復(fù)制中有兩個(gè)很重要的日志文件,binlog和relay log,分別位于主庫(kù)與從庫(kù)中。其中 binlog 是主從復(fù)制的基礎(chǔ),通過(guò)將操作事件寫入 binlog 通過(guò) I/O 線程傳送至從庫(kù)進(jìn)行同步。
主從延遲原因
從庫(kù)中 SQL 線程重放的過(guò)程是隨機(jī)寫盤的,并且 SQL 線程是單線程的,因此數(shù)據(jù)來(lái)不及重放的話就會(huì)導(dǎo)致主從延遲。
主庫(kù)并發(fā)高會(huì)導(dǎo)致寫操作不斷寫入 binlog,對(duì)于 SQL 線程說(shuō)可能會(huì)應(yīng)接不暇,也會(huì)產(chǎn)生主從延遲。
重放過(guò)程中如果遇到鎖等待也是產(chǎn)生延遲的原因之一。
主從延遲處理
MySQL 5.6版本以后通過(guò)并行復(fù)制的方式來(lái)解決 SQL 單線程產(chǎn)生的主從延遲問(wèn)題。對(duì)于低版本來(lái)說(shuō),可以通過(guò)降低主庫(kù)的并發(fā)來(lái)解決。如果對(duì)數(shù)據(jù)實(shí)時(shí)性要求比較嚴(yán)格的話,可以通過(guò)讀主庫(kù)來(lái)達(dá)到目的。
以上就是MySQL中主從不同步如何解決,小編相信有部分知識(shí)點(diǎn)可能是我們?nèi)粘9ぷ鲿?huì)見(jiàn)到或用到的。希望你能通過(guò)這篇文章學(xué)到更多知識(shí)。更多詳情敬請(qǐng)關(guān)注億速云行業(yè)資訊頻道。
免責(zé)聲明:本站發(fā)布的內(nèi)容(圖片、視頻和文字)以原創(chuàng)、轉(zhuǎn)載和分享為主,文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng),如果涉及侵權(quán)請(qǐng)聯(lián)系站長(zhǎng)郵箱:is@yisu.com進(jìn)行舉報(bào),并提供相關(guān)證據(jù),一經(jīng)查實(shí),將立刻刪除涉嫌侵權(quán)內(nèi)容。