1. 數據庫主從概念、優點、用途
主從數據庫是什么意思呢，主是主庫的意思，從是從庫的意思。數據庫主庫對外提供讀寫的操作，從庫對外提供讀的操作。
數據庫為什么需要主從架構呢？
- 高可用，實時災備，用於故障切換。比如主庫掛了，可以切從庫。
- 讀寫分離，提供查詢服務，減少主庫壓力，提升性能
- 備份數據，避免影響業務。
2. 數據庫主從復制原理
主從復制原理，簡言之，分三步曲進行：
- 主數據庫有個
bin log二進制文件，記錄了所有增刪改SQL語句。（binlog線程） - 從數據庫把主數據庫的
bin log文件的SQL語句復制到自己的中繼日志relay log（io線程） - 從數據庫的
relay log重做日志文件，再執行一次這些sql語句。（sql執行線程）
詳細的主從復制過程如圖：
上圖主從復制過程分了五個步驟進行：
- 主庫的更新SQL（update、insert、delete）被寫到binlog
- 從庫發起連接，連接到主庫。
- 此時主庫創建一個
binlog dump thread，把bin log的內容發送到從庫。 - 從庫啟動之后，創建一個
I/O線程，讀取主庫傳過來的bin log內容並寫到relay log - 從庫還會創建一個SQL線程，從
relay log里面讀取內容，從ExecMasterLog_Pos位置開始執行讀取到的更新事件，將更新內容寫入到slave的db
3.主主、主從、主備的區別
數據庫主主：兩台都是主數據庫，同時對外提供讀寫操作。客戶端訪問任意一台。數據存在雙向同步。
數據庫主從：一台是主數據庫，同時對外提供讀寫操作。一台是從數據庫，對外提供讀的操作。數據從主庫同步到從庫。
從庫和備庫，就是slave庫功能不同因此叫法不一樣而已。一般slave庫都會對外提供讀的功能的，因此，大家日常聽得最多的就是主從。
4.MySQL是怎樣保證主從一致的
我們學習數據庫的主從復制原理后，了解到從庫拿到並執行主庫的binlog日志，就可以保持數據與主庫一致了。這是為什么呢？哪些情況會導致不一致呢？
4.1長鏈接
主庫和從庫在同步數據的過程中斷怎么辦呢，數據不就會丟失了嘛。因此主庫與從庫之間維持了一個長鏈接，主庫內部有一個線程，專門服務於從庫這個長鏈接。
4.2binlog格式
binlog 日志有三種格式，分別是 statement，row 和 mixed。
如果是 statement 格式，binlog 記錄的是 SQL的原文，如果主庫和從庫選的索引不一致，可能會導致主庫不一致。我們來分析一下。假設主庫執行刪除這個SQL（其中，a 和 create_time 都會有索引）如下：
delete from t where a > '666' and create_time < '2022-03-02' 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。所謂的 mixed格式其實就是 row 和 statement 格式混合使用，當 MySQL 判斷可能數據不一致時，就用 row 格式，否則使用 statement 格式。
5.數據庫主從延遲的原因與解決方案
主從延遲是怎樣定義的呢？與主從數據同步相關的時間點有三個
- 主庫執行完一個事務，寫入binlog，我們把這個時刻記為
T1; - 主庫同步數據給從庫，從庫接受完這個binlog的時刻，記錄為
T2； - 從庫執行完這個事務，這個時刻記錄為
T3。
所謂主從延遲，其實就是指同一個事務，在從庫執行完的時間和在主庫執行完的時間差值，即 T3-T1。
哪些情況會導致主從延遲呢？
- 如果從庫所在的機器比主庫的機器性能差，會導致主從延遲，這種情況比較好解決，只需選擇主從庫一樣規格的機器就好。
- 如果從庫的壓力大，也會導致主從延遲。比如主庫直接影響業務，大家可能使用會比較克制，因此一般查詢都打到從庫了，結果導致從庫查詢消耗大量CPU，影響同步速度，最后導致主從延遲。這種情況的話，可以搞一主多從架構，即多接幾個從庫分攤讀的壓力。另外，還可以把binlog接入到Hadoop這類系統，讓它們提供查詢的能力。
- 大事務也會導致主從延遲。如果一個事務執行就要10分鍾，那么主庫執行完后，給到從庫執行，最后這個事務可能就會導致從庫延遲10分鍾啦。日常開發中，我們為什么特別強調，不要一次性delete太多SQL，需要分批進行，其實也是為了避免大事務。另外，大表的DDL語句，也會導致大事務，大家日常開發關注一下哈。
- 網絡延遲也會導致主從延遲，這種情況你只能優化你的網絡啦，比如帶寬20M升級到100M類似意思等。
- 如果從數據庫過多也會導致主從延遲，因此要避免復制的從節點數量過多。從庫數據一般以3-5個為宜。
- 低版本的MySQL只支持單線程復制，如果主庫並發高，來不及傳送到從庫，就會導致延遲。可以換用更高版本的Mysql，可以支持多線程復制。
6.聊聊數據的庫高可用方案
6.1雙機主備高可用
- 架構描述：兩台機器A和B，A為主庫，負責讀寫，B為備庫，只備份數據。如果A庫發生故障，B庫成為主庫負責讀寫。修復故障后，A成為備庫，主庫B同步數據到備庫A
- 優點：一個機器故障了可以自動切換，操作比較簡單。
- 缺點：只有一個庫在工作，讀寫壓力大，未能實現讀寫分離，並發也有一定限制
6.2一主一從
- 架構描述: 兩台機器A和B，A為主庫，負責讀寫，B為從庫，負責讀數據。如果A庫發生故障，B庫成為主庫負責讀寫。修復故障后，A成為從庫，主庫B同步數據到從庫A。
- 優點：從庫支持讀，分擔了主庫的壓力，提升了並發度。一個機器故障了可以自動切換，操作比較簡單。
- 缺點：一台從庫，並發支持還是不夠，並且一共兩台機器，還是存在同時故障的機率，不夠高可用。
6.3一主多從
- 架構描述: 一台主庫多台從庫，A為主庫，負責讀寫，B、C、D為從庫，負責讀數據。如果A庫發生故障，B庫成為主庫負責讀寫，C、D負責讀。修復故障后，A也成為從庫，主庫B同步數據到從庫A。
- 優點：多個從庫支持讀，分擔了主庫的壓力，明顯提升了讀的並發度。
- 缺點：只有台主機寫，因此寫的並發度不高
6.4MariaDB同步多主機集群
- 架構描述:有代理層實現負載均衡，多個數據庫可以同時進行讀寫操作；各個數據庫之間可以通過
Galera Replication方法進行數據同步，每個庫理論上數據是完全一致的。 - 優點：讀寫的並發度都明顯提升，可以任意節點讀寫，可以自動剔除故障節點，具有較高的可靠性。
- 缺點：數據量不支持特別大。要避免大事務卡死，如果集群節點一個變慢，其他節點也會跟着變慢。
6.5數據庫中間件
- 架構描述：mycat分片存儲，每個分片配置一主多從的集群。
- 優點：解決高並發高數據量的高可用方案
- 缺點：維護成本比較大。
巨人的肩膀
微信公眾號：撿田螺的小男孩