MySQL主從延遲問題解決

更新時間：2021年01月12日 09:51:11 作者：熬夜不加班

這篇文章主要介紹了MySQL主從延遲問題解決的方法，幫助大家更好的理解和使用MySQL數(shù)據(jù)庫，感興趣的朋友可以了解下

今天我們就來看看為什么會產(chǎn)生主從延遲以及主從延遲如何處理等相關問題。

坐好了，準備發(fā)車！

主從常見架構

隨著日益增長的訪問量，單臺數(shù)據(jù)庫的應接能力已經(jīng)捉襟見肘。因此采用主庫寫數(shù)據(jù)，從庫讀數(shù)據(jù)這種將讀寫分離開的主從架構便隨之衍生了出來。

在生產(chǎn)環(huán)境中，常見的主從架構有很多種，在這里給大家介紹幾種比較常見的架構模式。

主從復制原理

了解了主從的基本架構及相關配置后，下面就要進入正題了。

對于主從來說，通常的操作是主庫用來寫入數(shù)據(jù)，從庫用來讀取數(shù)據(jù)。這樣的好處是通過將讀寫壓力分散開，避免了所有的請求都打在主庫上。同時通過從庫進行水平擴展使系統(tǒng)的伸縮性及負載能力也得到了很大的提升。

但是問題就來了，讀從庫時的數(shù)據(jù)要與主庫保持一致，那就需要主庫的數(shù)據(jù)在寫入后同步到從庫中。如何保持主庫與從庫的數(shù)據(jù)一致性，主庫又是通過什么樣的方式將數(shù)據(jù)實時同步到從庫的？

基本原理

Mysql 中主從復制時有兩個很重要的日志文件：

binlog（二進制日志文件）
relay log（中繼日志文件）

在主從同步的過程中，主庫會將所有的操作事件記錄在 binlog 中，從庫通過開啟一個 I/O 線程保持與主庫的通信，并在一定時間間隔內(nèi)探測 binlog 日志文件是否發(fā)生改變。如果 binlog 日志發(fā)生了變化，主庫生成一個 binlog dump 線程向從庫 I/O 線程傳送 binlog。從庫上的 I/O 線程將 binlog 復制到自己的 relay log 中。最終由從庫中的 SQL 線程讀取 relay log 中的事件重放到從庫上。

主從延遲原因

上面的流程我們已經(jīng)知道了主從復制的相關過程了，但是主庫有更新就會同步從庫，那為什么會出現(xiàn)主從延遲的情況呢？

隨機重放

Mysql 主庫中寫 binlog 的操作是順序寫的，之前我們提到過，磁盤的順序讀寫速度是很快的。同樣的，從庫中的 I/O 線程操作日志的速度效率也是很高的。但是別忘了，還有一個 SQL 線程來進行數(shù)據(jù)重放，而重放的過程是隨機寫盤的。到這里你應該就明白了吧，某一時刻 relay log 里的數(shù)據(jù)來不及重放進從庫，就會產(chǎn)生主從延遲的情況。