MySQL 主從，六分鐘帶你掌握！

作者：樓仔 2022-05-30 07:51:13

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

大家好，我是樓仔!

MySQL 主從一直是面試常客，里面的知識(shí)點(diǎn)雖然基礎(chǔ)，但是能回答全的同學(xué)不多。

比如我之前面試小米，就被問到過主從復(fù)制的原理，以及主從延遲的解決方案，你之前面試，有遇到過哪些 MySQL 主從的問題呢?

1. MySQL 主從

1.1 什么是 MySQL 主從 ?

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

1.2 為什么使用 MySQL 主從 ?

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

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

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

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

2. 主從復(fù)制

2.1 主從復(fù)制原理

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

主從復(fù)制就是將 binlog 中的數(shù)據(jù)從主庫傳輸?shù)綇膸焐希话氵@個(gè)過程是異步的，即主庫上的操作不會(huì)等待 binlog 同步地完成。

詳細(xì)流程如下：

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

2.2 如何保證主從一致

當(dāng)主庫和從庫數(shù)據(jù)同步時(shí)，突然中斷怎么辦?因?yàn)橹鲙炫c從庫之間維持了一個(gè)長鏈接，主庫內(nèi)部有一個(gè)線程，專門服務(wù)于從庫的這個(gè)長鏈接。

對(duì)于下面的情況，假如主庫執(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ù)一般是不一樣的。

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

那么我們?cè)撊绾谓鉀Q呢?

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

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

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

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

3. 主從延遲

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

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

3.1 主從延遲原理

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

MySQL 的主從復(fù)制都是單線程的操作，主庫對(duì)所有 DDL 和 DML 產(chǎn)生 binlog，binlog 是順序?qū)懀孕屎芨?
Slave 的 Slave_IO_Running 線程會(huì)到主庫取日志，放入 relay log，效率會(huì)比較高;
Slave 的 Slave_SQL_Running 線程將主庫的 DDL 和 DML 操作都在 Slave 實(shí)施，DML 和 DDL 的 IO 操作是隨機(jī)的，不是順序的，因此成本會(huì)很高，還可能是 Slave 上的其他查詢產(chǎn)生 lock 爭用，由于 Slave_SQL_Running 也是單線程的，所以一個(gè) DDL 卡主了，需要執(zhí)行 10 分鐘，那么所有之后的 DDL 會(huì)等待這個(gè) DDL 執(zhí)行完才會(huì)繼續(xù)執(zhí)行，這就導(dǎo)致了延時(shí)。

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

3.2 主從延遲情況

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

3.3 主從延遲解決方案

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

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

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

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