這篇文章主要介紹“如何解決MySQL中主庫跑太快從庫追不上的問題”，在日常操作中，相信很多人在如何解決MySQL中主庫跑太快從庫追不上的問題問題上存在疑惑，小編查閱了各式資料，整理出簡單好用的操作方法，希望對(duì)大家解答”如何解決MySQL中主庫跑太快從庫追不上的問題”的疑惑有所幫助！接下來，請(qǐng)跟著小編一起來學(xué)習(xí)吧！
創(chuàng)新互聯(lián)專注于企業(yè)成都營銷網(wǎng)站建設(shè)、網(wǎng)站重做改版、思南網(wǎng)站定制設(shè)計(jì)、自適應(yīng)品牌網(wǎng)站建設(shè)、HTML5建站、商城網(wǎng)站定制開發(fā)、集團(tuán)公司官網(wǎng)建設(shè)、成都外貿(mào)網(wǎng)站建設(shè)公司、高端網(wǎng)站制作、響應(yīng)式網(wǎng)頁設(shè)計(jì)等建站業(yè)務(wù)，價(jià)格優(yōu)惠性價(jià)比高，為思南等各大城市提供網(wǎng)站開發(fā)制作服務(wù)。
- 思維導(dǎo)圖 -
隨著日益增長的訪問量，單臺(tái)數(shù)據(jù)庫的應(yīng)接能力已經(jīng)捉襟見肘。因此采用主庫寫數(shù)據(jù)，從庫讀數(shù)據(jù)這種將讀寫分離開的主從架構(gòu)便隨之衍生了出來。
在生產(chǎn)環(huán)境中，常見的主從架構(gòu)有很多種，在這里給大家介紹幾種比較常見的架構(gòu)模式。
了解了主從的基本架構(gòu)及相關(guān)配置后，下面就要進(jìn)入正題了。
對(duì)于主從來說，通常的操作是主庫用來寫入數(shù)據(jù)，從庫用來讀取數(shù)據(jù)。這樣的好處是通過將讀寫壓力分散開，避免了所有的請(qǐng)求都打在主庫上。同時(shí)通過從庫進(jìn)行水平擴(kuò)展使系統(tǒng)的伸縮性及負(fù)載能力也得到了很大的提升。
但是問題就來了，讀從庫時(shí)的數(shù)據(jù)要與主庫保持一致，那就需要主庫的數(shù)據(jù)在寫入后同步到從庫中。如何保持主庫與從庫的數(shù)據(jù)一致性，主庫又是通過什么樣的方式將數(shù)據(jù)實(shí)時(shí)同步到從庫的？
Mysql 中主從復(fù)制時(shí)有兩個(gè)很重要的日志文件：
binlog（二進(jìn)制日志文件）
relay log（中繼日志文件）
在主從同步的過程中，主庫會(huì)將所有的操作事件記錄在 binlog 中，從庫通過開啟一個(gè) I/O 線程保持與主庫的通信，并在一定時(shí)間間隔內(nèi)探測(cè) binlog 日志文件是否發(fā)生改變。如果 binlog 日志發(fā)生了變化，主庫生成一個(gè) binlog dump 線程向從庫 I/O 線程傳送 binlog。從庫上的 I/O 線程將 binlog 復(fù)制到自己的 relay log 中。最終由從庫中的 SQL 線程讀取 relay log 中的事件重放到從庫上。
上面的流程我們已經(jīng)知道了主從復(fù)制的相關(guān)過程了，但是主庫有更新就會(huì)同步從庫，那為什么會(huì)出現(xiàn)主從延遲的情況呢？
Mysql 主庫中寫 binlog 的操作是順序?qū)懙?，之前我們提到過，磁盤的順序讀寫速度是很快的。同樣的，從庫中的 I/O 線程操作日志的速度效率也是很高的。但是別忘了，還有一個(gè) SQL 線程來進(jìn)行數(shù)據(jù)重放，而重放的過程是隨機(jī)寫盤的。到這里你應(yīng)該就明白了吧，某一時(shí)刻 relay log 里的數(shù)據(jù)來不及重放進(jìn)從庫，就會(huì)產(chǎn)生主從延遲的情況。
知道了從庫中 SQL 線程的重放情況，對(duì)于主庫并發(fā)高導(dǎo)致主從延遲肯定就不難理解了。某一時(shí)刻，大量寫請(qǐng)求打到主庫上，意味著要不斷對(duì) binlog 進(jìn)行寫入，此時(shí)從庫中的 SQL 線程就會(huì)應(yīng)接不暇，自然會(huì)產(chǎn)生主從延遲。
對(duì)于 SQL 單線程來說，當(dāng)遇到阻塞時(shí)就會(huì)一直等待，直到執(zhí)行成功才會(huì)繼續(xù)進(jìn)行。如果某一時(shí)刻從庫因?yàn)椴樵儺a(chǎn)生了鎖等待的情況，此時(shí)只有當(dāng)前的操作執(zhí)行完成后才會(huì)進(jìn)行下面的操作，同理也就產(chǎn)生了主從延遲的情況。
知道了主從延遲的原因，接下來我們看看如何來進(jìn)行處理。
既然 SQL 單線程進(jìn)行重放時(shí)速度有限，那么能不能采用多線程的方式來進(jìn)行重放呢？MySQL 5.6 版本后，提供了一種并行復(fù)制的方式，通過將 SQL 線程轉(zhuǎn)換為多個(gè) work 線程來進(jìn)行重放，這樣就解決了主從延遲的問題。
你可能會(huì)說了，我現(xiàn)在用的低版本的數(shù)據(jù)庫，也沒法升版本啊，那我怎么整。對(duì)于主庫并發(fā)高的情況，這種方式你只能通過控制并發(fā)來解決延遲了，多用用 redis。
這種情況你肯定不陌生，對(duì)于一些實(shí)時(shí)性要求比較高的數(shù)據(jù)，你總不能讀從庫去拿吧，萬一延遲個(gè)大半天，你不得貢獻(xiàn)自己的年終獎(jiǎng)啊。
主從復(fù)制中有兩個(gè)很重要的日志文件，binlog和relay log，分別位于主庫與從庫中。其中 binlog 是主從復(fù)制的基礎(chǔ)，通過將操作事件寫入 binlog 通過 I/O 線程傳送至從庫進(jìn)行同步。
從庫中 SQL 線程重放的過程是隨機(jī)寫盤的，并且 SQL 線程是單線程的，因此數(shù)據(jù)來不及重放的話就會(huì)導(dǎo)致主從延遲。
主庫并發(fā)高會(huì)導(dǎo)致寫操作不斷寫入 binlog，對(duì)于 SQL 線程說可能會(huì)應(yīng)接不暇，也會(huì)產(chǎn)生主從延遲。
重放過程中如果遇到鎖等待也是產(chǎn)生延遲的原因之一。
MySQL 5.6版本以后通過并行復(fù)制的方式來解決 SQL 單線程產(chǎn)生的主從延遲問題。對(duì)于低版本來說，可以通過降低主庫的并發(fā)來解決。如果對(duì)數(shù)據(jù)實(shí)時(shí)性要求比較嚴(yán)格的話，可以通過讀主庫來達(dá)到目的。
到此，關(guān)于“如何解決MySQL中主庫跑太快從庫追不上的問題”的學(xué)習(xí)就結(jié)束了，希望能夠解決大家的疑惑。理論與實(shí)踐的搭配能更好的幫助大家學(xué)習(xí)，快去試試吧！若想繼續(xù)學(xué)習(xí)更多相關(guān)知識(shí)，請(qǐng)繼續(xù)關(guān)注創(chuàng)新互聯(lián)網(wǎng)站，小編會(huì)繼續(xù)努力為大家?guī)砀鄬?shí)用的文章！
重慶分公司
重慶分公司
