MySQL 主從，六分鐘帶你掌握！
大家好，我是樓仔!
MySQL 主從一直是面試?？?，里面的知識點雖然基礎，但是能回答全的同學不多。
比如我之前面試小米，就被問到過主從復制的原理，以及主從延遲的解決方案，你之前面試，有遇到過哪些 MySQL 主從的問題呢?
1. MySQL 主從
1.1 什么是 MySQL 主從 ?
所謂 MySQL 主從，就是建立兩個完全一樣的數據庫，一個是主庫，一個是從庫，主庫對外提供讀寫的操作，從庫對外提供讀的操作。
1.2 為什么使用 MySQL 主從 ?
對于數據庫單機部署，在 4 核 8G 的機器上運行 MySQL 5.7 時，大概可以支撐 500 的 TPS 和
10000 的 QPS，當遇到一些活動時，查詢流量驟然，就需要進行主從分離。
大部分系統的訪問模型是讀多寫少，讀寫請求量的差距可能達到幾個數量級，所以我們可以通過一主多從的方式，主庫只負責寫入和部分核心邏輯的查詢，多個從庫只負責查詢，提升查詢性能，降低主庫壓力。
當主庫宕機時，從庫可以切成主庫，保證服務的高可用，然后主庫也可以做數據的容災備份，整體場景總結如下：
- 讀寫分離：從庫提供查詢，減少主庫壓力，提升性能;
- 高可用：故障時可切換從庫，保證服務高可用;
- 數據備份：數據備份到從庫，防止服務器宕機導致數據丟失。
2. 主從復制
2.1 主從復制原理
MySQL 的主從復制是依賴于 binlog，也就是記錄 MySQL 上的所有變化并以二進制形式保存在磁盤上二進制日志文件。
主從復制就是將 binlog 中的數據從主庫傳輸到從庫上，一般這個過程是異步的，即主庫上的操作不會等待 binlog 同步地完成。
詳細流程如下：
- 主庫寫 binlog：主庫的更新 SQL(update、insert、delete) 被寫到 binlog;
- 主庫發送 binlog：主庫創建一個 log dump 線程來發送 binlog 給從庫;
- 從庫寫 relay log：從庫在連接到主節點時會創建一個 IO 線程，以請求主庫更新的 binlog，并且把接收到的 binlog 信息寫入一個叫做
relay log 的日志文件; - 從庫回放：從庫還會創建一個 SQL 線程讀取 relay log 中的內容，并且在從庫中做回放，最終實現主從的一致性。
2.2 如何保證主從一致
當主庫和從庫數據同步時，突然中斷怎么辦?因為主庫與從庫之間維持了一個長鏈接，主庫內部有一個線程，專門服務于從庫的這個長鏈接。
對于下面的情況，假如主庫執行如下 SQL，其中 a 和 create_time 都是索引：
delete from t where a > '666' and create_time<'2022-03-01' limit 1;
我們知道，數據選擇了 a 索引和選擇 create_time 索引，最后 limit 1 出來的數據一般是不一樣的。
所以就會存在這種情況：在 binlog = statement 格式時，主庫在執行這條 SQL 時，使用的是索引 a，而從庫在執行這條 SQL
時，使用了索引 create_time，最后主從數據不一致了。
那么我們該如何解決呢?
可以把 binlog 格式修改為 row，row 格式的 binlog 日志記錄的不是 SQL 原文，而是兩個 event:Table_map 和
Delete_rows。
Table_map event 說明要操作的表，Delete_rows event用于定義要刪除的行為，記錄刪除的具體行數。row 格式的 binlog
記錄的就是要刪除的主鍵 ID 信息，因此不會出現主從不一致的問題。
但是如果 SQL 刪除 10 萬行數據，使用 row 格式就會很占空間，10 萬條數據都在 binlog 里面，寫 binlog 的時候也很耗 IO。但是
statement 格式的 binlog 可能會導致數據不一致。
設計 MySQL 的大叔想了一個折中的方案，mixed 格式的 binlog，其實就是 row 和 statement 格式混合使用，當 MySQL
判斷可能數據不一致時，就用 row 格式，否則使用就用 statement 格式。
3. 主從延遲
有時候我們遇到從數據庫中獲取不到信息的詭異問題時，會糾結于代碼中是否有一些邏輯會把之前寫入的內容刪除，但是你又會發現，過了一段時間再去查詢時又可以讀到數據了，這基本上就是主從延遲在作怪。
主從延遲，其實就是“從庫回放” 完成的時間，與 “主庫寫 binlog” 完成時間的差值，會導致從庫查詢的數據，和主庫的不一致。
3.1 主從延遲原理
談到 MySQL 數據庫主從同步延遲原理，得從 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 卡主了，需要執行 10 分鐘，那么所有之后的 DDL 會等待這個 DDL 執行完才會繼續執行，這就導致了延時。
總結一下主從延遲的主要原因：主從延遲主要是出現在 “relay log 回放” 這一步，當主庫的 TPS 并發較高，產生的 DDL 數量超過從庫一個
SQL 線程所能承受的范圍，那么延時就產生了，當然還有就是可能與從庫的大型 query 語句產生了鎖等待。
3.2 主從延遲情況
- 從庫機器性能：從庫機器比主庫的機器性能差，只需選擇主從庫一樣規格的機器就好。
- 從庫壓力大：可以搞了一主多從的架構，還可以把 binlog 接入到 Hadoop 這類系統，讓它們提供查詢的能力。
- 從庫過多：要避免復制的從節點數量過多，從庫數據一般以3-5個為宜。
- 大事務：如果一個事務執行就要 10 分鐘，那么主庫執行完后，給到從庫執行，最后這個事務可能就會導致從庫延遲 10 分鐘啦。日常開發中，不要一次性
delete 太多 SQL，需要分批進行，另外大表的 DDL 語句，也會導致大事務。 - 網絡延遲：優化網絡，比如帶寬 20M 升級到 100M。
- MySQL 版本低：低版本的 MySQL 只支持單線程復制，如果主庫并發高，來不及傳送到從庫，就會導致延遲，可以換用更高版本的
MySQL，支持多線程復制。
3.3 主從延遲解決方案
我們一般會把從庫落后的時間作為一個重點的數據庫指標做監控和報警，正常的時間是在毫秒級別，一旦落后的時間達到了秒級別就需要告警了。
解決該問題的方法，除了縮短主從延遲的時間，還有一些其它的方法，基本原理都是盡量不查詢從庫，具體解決方案如下：
- 使用緩存：我們在同步寫數據庫的同時，也把數據寫到緩存，查詢數據時，會先查詢緩存，不過這種情況會帶來 MySQL 和 Redis 數據一致性問題。
- 查詢主庫：直接查詢主庫，這種情況會給主庫太大壓力，不建議這種方式。
- 數據冗余：對于一些異步處理的場景，如果只扔數據 ID，消費數據時，需要查詢從庫，我們可以把數據全部都扔給消息隊列，這樣消費者就無需再查詢從庫。(這種情況應該不太能出現，數據轉了一圈，MySQL 主從還沒有同步好，直接去撕 DBA 吧)
在實際應用場景中，對于一些非常核心的場景，比如庫存，支付訂單等，需要直接查詢從庫，其它非核心場景，就不要去查主庫了。
4. 主從切換
4.1 一主一從
兩臺機器 A 和 B，A 為主庫，負責讀寫，B 為從庫，負責讀數據。
如果 A 庫發生故障，B 庫成為主庫負責讀寫，修復故障后，A 成為從庫，主庫 B 同步數據到從庫 A。
優點：從庫支持讀，分擔了主庫的壓力，提升了并發度，且一個機器故障了可以自動切換，操作比較簡單，公司從庫還可以充當數據備份的角色;
缺點：一臺從庫，并發支持還是不夠，并且一共兩臺機器，還是存在同時故障的機率，不夠高可用。
對于一主一從的模式，一般小公司會這么用，不過該模式下，主從分離的意義其實并不大，因為小公司的流量不高，更多是為了數據庫的可用性，以及數據備份。
4.2 一主多從一臺主庫多臺從庫，A 為主庫，負責讀寫，B、C、D為從庫，負責讀數據。
如果 A 庫發生故障，B 庫成為主庫負責讀寫，C、D 負責讀，修復故障后，A 也成為從庫，主庫 B 同步數據到從庫 A。
- 優點：多個從庫支持讀，分擔了主庫的壓力，明顯提升了讀的并發度。
- 缺點：只有臺主機寫，因此寫的并發度不高。
基本上大公司，比如百度、滴滴，都是這種一主多從的模式，因為查詢流量太高，一定需要進行讀寫分離，同時也需要支持服務的高可用、數據容災。
