MySQL主從復制延時問題的解決方案

更新時間：2023年12月29日 11:09:10 作者：樓仔

MySQL主從一直是面試?？?里面的知識點雖然基礎,但是能回答全的同學不多,如果我們遇到問如何解決MySQL主從復制延時問題呢,所以本文給大家講解了MySQL主從復制延時問題的解決方法,需要的朋友可以參考下

1. MySQL 主從

1.1 什么是 MySQL 主從 ?

所謂 MySQL 主從，就是建立兩個完全一樣的數(shù)據(jù)庫，一個是主庫，一個是從庫，主庫對外提供讀寫的操作，從庫對外提供讀的操作。

1.2 為什么使用 MySQL 主從 ?

對于數(shù)據(jù)庫單機部署，在 4 核 8G 的機器上運行 MySQL 5.7 時，大概可以支撐 500 的 TPS 和 10000 的 QPS，當遇到一些活動時，查詢流量驟然，就需要進行主從分離。

大部分系統(tǒng)的訪問模型是讀多寫少，讀寫請求量的差距可能達到幾個數(shù)量級，所以我們可以通過一主多從的方式，主庫只負責寫入和部分核心邏輯的查詢，多個從庫只負責查詢，提升查詢性能，降低主庫壓力。

當主庫宕機時，從庫可以切成主庫，保證服務的高可用，然后主庫也可以做數(shù)據(jù)的容災備份，整體場景總結如下：

讀寫分離：從庫提供查詢，減少主庫壓力，提升性能；
高可用：故障時可切換從庫，保證服務高可用；
數(shù)據(jù)備份：數(shù)據(jù)備份到從庫，防止服務器宕機導致數(shù)據(jù)丟失。

2. 主從復制

2.1 主從復制原理

MySQL 的主從復制是依賴于 binlog，也就是記錄 MySQL 上的所有變化并以二進制形式保存在磁盤上二進制日志文件。

主從復制就是將 binlog 中的數(shù)據(jù)從主庫傳輸?shù)綇膸焐?，一般這個過程是異步的，即主庫上的操作不會等待 binlog 同步地完成。

詳細流程如下：

主庫寫 binlog：主庫的更新 SQL(update、insert、delete) 被寫到 binlog；
主庫發(fā)送 binlog：主庫創(chuàng)建一個 log dump 線程來發(fā)送 binlog 給從庫；
從庫寫 relay log：從庫在連接到主節(jié)點時會創(chuàng)建一個 IO 線程，以請求主庫更新的 binlog，并且把接收到的 binlog 信息寫入一個叫做 relay log 的日志文件；
從庫回放：從庫還會創(chuàng)建一個 SQL 線程讀取 relay log 中的內容，并且在從庫中做回放，最終實現(xiàn)主從的一致性。

2.2 如何保證主從一致

當主庫和從庫數(shù)據(jù)同步時，突然中斷怎么辦？因為主庫與從庫之間維持了一個長鏈接，主庫內部有一個線程，專門服務于從庫的這個長鏈接。

對于下面的情況，假如主庫執(zhí)行如下 SQL，其中 a 和 create_time 都是索引：

delete from t where a > '666' and create_time<'2022-03-01' limit 1;

我們知道，數(shù)據(jù)選擇了 a 索引和選擇 create_time 索引，最后 limit 1 出來的數(shù)據(jù)一般是不一樣的。

所以就會存在這種情況：在 binlog = statement 格式時，主庫在執(zhí)行這條 SQL 時，使用的是索引 a，而從庫在執(zhí)行這條 SQL 時，使用了索引 create_time，最后主從數(shù)據(jù)不一致了。

那么我們該如何解決呢？

可以把 binlog 格式修改為 row，row 格式的 binlog 日志記錄的不是 SQL 原文，而是兩個 event:Table_map 和 Delete_rows。

Table_map event 說明要操作的表，Delete_rows event用于定義要刪除的行為，記錄刪除的具體行數(shù)。row 格式的 binlog 記錄的就是要刪除的主鍵 ID 信息，因此不會出現(xiàn)主從不一致的問題。

但是如果 SQL 刪除 10 萬行數(shù)據(jù)，使用 row 格式就會很占空間，10 萬條數(shù)據(jù)都在 binlog 里面，寫 binlog 的時候也很耗 IO。但是 statement 格式的 binlog 可能會導致數(shù)據(jù)不一致。

設計 MySQL 的大叔想了一個折中的方案，mixed 格式的 binlog，其實就是 row 和 statement 格式混合使用，當 MySQL 判斷可能數(shù)據(jù)不一致時，就用 row 格式，否則使用就用 statement 格式。

3. 主從延遲

有時候我們遇到從數(shù)據(jù)庫中獲取不到信息的詭異問題時，會糾結于代碼中是否有一些邏輯會把之前寫入的內容刪除，但是你又會發(fā)現(xiàn)，過了一段時間再去查詢時又可以讀到數(shù)據(jù)了，這基本上就是主從延遲在作怪。

主從延遲，其實就是“從庫回放” 完成的時間，與 “主庫寫 binlog” 完成時間的差值，會導致從庫查詢的數(shù)據(jù)，和主庫的不一致。

3.1 主從延遲原理

談到 MySQL 數(shù)據(jù)庫主從同步延遲原理，得從 MySQL 的主從復制原理說起：

MySQL 的主從復制都是單線程的操作，主庫對所有 DDL 和 DML 產生 binlog，binlog 是順序寫，所以效率很高；
Slave 的 Slave_IO_Running 線程會到主庫取日志，放入 relay log，效率會比較高；
Slave 的 Slave_SQL_Running 線程將主庫的 DDL 和 DML 操作都在 Slave 實施，DML 和 DDL 的 IO 操作是隨機的，不是順序的，因此成本會很高，還可能是 Slave 上的其他查詢產生 lock 爭用，由于 Slave_SQL_Running 也是單線程的，所以一個 DDL 卡住了，需要執(zhí)行 10 分鐘，那么所有之后的 DDL 會等待這個 DDL 執(zhí)行完才會繼續(xù)執(zhí)行，這就導致了延時。

總結一下主從延遲的主要原因：主從延遲主要是出現(xiàn)在 “relay log 回放” 這一步，當主庫的 TPS 并發(fā)較高，產生的 DDL 數(shù)量超過從庫一個 SQL 線程所能承受的范圍，那么延時就產生了，當然還有就是可能與從庫的大型 query 語句產生了鎖等待。

3.2 主從延遲情況

從庫機器性能：從庫機器比主庫的機器性能差，只需選擇主從庫一樣規(guī)格的機器就好。
從庫壓力大：可以搞了一主多從的架構，還可以把 binlog 接入到 Hadoop 這類系統(tǒng)，讓它們提供查詢的能力。
從庫過多：要避免復制的從節(jié)點數(shù)量過多，從庫數(shù)據(jù)一般以3-5個為宜。
大事務：如果一個事務執(zhí)行就要 10 分鐘，那么主庫執(zhí)行完后，給到從庫執(zhí)行，最后這個事務可能就會導致從庫延遲 10 分鐘啦。日常開發(fā)中，不要一次性 delete 太多 SQL，需要分批進行，另外大表的 DDL 語句，也會導致大事務。
網絡延遲：優(yōu)化網絡，比如帶寬 20M 升級到 100M。
MySQL 版本低：低版本的 MySQL 只支持單線程復制，如果主庫并發(fā)高，來不及傳送到從庫，就會導致延遲，可以換用更高版本的 MySQL，支持多線程復制。

3.3 主從延遲解決方案

我們一般會把從庫落后的時間作為一個重點的數(shù)據(jù)庫指標做監(jiān)控和報警，正常的時間是在毫秒級別，一旦落后的時間達到了秒級別就需要告警了。

解決該問題的方法，除了縮短主從延遲的時間，還有一些其它的方法，基本原理都是盡量不查詢從庫，具體解決方案如下：

使用緩存：我們在同步寫數(shù)據(jù)庫的同時，也把數(shù)據(jù)寫到緩存，查詢數(shù)據(jù)時，會先查詢緩存，不過這種情況會帶來 MySQL 和 Redis 數(shù)據(jù)一致性問題。
查詢主庫：直接查詢主庫，這種情況會給主庫太大壓力，不建議這種方式。
數(shù)據(jù)冗余：對于一些異步處理的場景，如果只扔數(shù)據(jù) ID，消費數(shù)據(jù)時，需要查詢從庫，我們可以把數(shù)據(jù)全部都扔給消息隊列，這樣消費者就無需再查詢從庫。（這種情況應該不太能出現(xiàn)，數(shù)據(jù)轉了一圈，MySQL 主從還沒有同步好，直接去撕 DBA 吧）

在實際應用場景中，對于一些非常核心的場景，比如庫存，支付訂單等，需要直接查詢主庫，其它非核心場景，就不要去查主庫了。