日常工作中，MySQL資料庫是必不可少的儲存，其中讀寫分離基本是標配，而這背後需要MySQL開啟主從同步，形成一主一從、或一主多從的架構，掌握主從同步的原理和知道如何實際應用，是一個架構師的必備技能。樓主將在本文做總結，看這一篇就夠了。
1、主從同步原理
主從同步架構圖（非同步同步）
這是最常見的主從同步架構。
主從同步流程（非同步同步）
- 主庫把資料變更寫入binlog檔案
- 從庫I/O執行緒發起dump請求
- 主庫I/O執行緒推送binlog至從庫
- 從庫I/O執行緒寫入本地的relay log檔案（與binlog格式一樣）
- 從庫SQL執行緒讀取relay log並重新序列執行一遍，得到與主庫相同的資料
什麼是binlog？
主庫每提交一次事務，都會把資料變更，記錄到一個二進位制檔案中，這個二進位制檔案就叫binlog。需注意：只有寫操作才會記錄至binlog，只讀操作是不會的（如select、show語句）。
binlog的3種格式：
- statement格式：binlog記錄的是實際執行的sql語句
- row格式：binlog記錄的是變化前後的資料（涉及所有列），形如update table_a set col1=value1, col2=value2 ... where col1=condition1 and col2=condition2 ...
- mixed格式：預設選擇statement格式，只在需要時改用row格式
binlog格式對比
- statement級別：優點是binlog檔案小，缺點是主庫的慢sql也會在從庫上再出現一次，一些依賴環境或上下文的函式可能會產生不一致的資料
- row級別：缺點是檔案大（一條語句如果涉及多行，會放大n倍），優點是無上述慢sql問題，不依賴環境或上下文
- 為了獲取前後變化資料，canal建議使用row級別
主從同步的2種方式
- 非同步同步：預設方式，可能會導致主從切換時資料丟失。因為主庫是否commit與主從同步流程無關，也不感知。
- 半同步：高可用方案，較新mysql版本支援，需要至少1個從庫（預設1，具體數量可指定）對寫入relay log進行ack，主庫才會commit並把結果返回client。
主從同步流程（半同步）
- 從庫在連線主庫時，表明自己支援半同步複製
- 主庫也需支援半同步複製，主庫commit事務前會阻塞等待至少一個從庫寫入relay log的ack，直至超時
- 如果阻塞等待超時，則主庫臨時切換回非同步同步模式，當至少一個從庫的半同步追上進度時，主庫再切換至半同步模式
半同步適用場景
高可用備份：半同步複製，可確保從庫與主庫的一致性，當主庫發生故障時，切換到從庫不會丟失資料。為了保證穩定性（不因半同步慢而拖累主庫），一般不承擔業務流量、儘可能快地ack，只用於同步備份。
2、主從同步應用場景
普通場景：線上從庫非同步同步，高可用備份半同步
對一致性要求較高的大資料取數需求
大資料取數可能導致從庫cpu使用率飆升、ack變慢，可設定半同步所需ack數量為1，正常情況下高可用備份能很快ack，於是主庫會commit並返回，而大資料取數複製慢一些也無所謂。這樣就不會因為大資料取數ack慢而影響主庫和業務了。
參考：mysql官方文件