1.主從模式
正常情況下，只有Master處理寫數據請求，同時Master與Slave通過主從復制技術保持數據一致。當Master發生故障宕機時，某個Slave會被提升為Master繼續對外提供服務。
主從復制原理：
- 1、當Master數據發生改變時，Master將數據的變更日志寫入二進制日志文件binlog
- 2、數據庫Slave啟動IO線程，并與Master建立網絡連接，從Master的binlog中讀取最新的數據變更日志
- 3、Slave的IO線程收到數據變更日志后，將其保存在中繼日志文件relay log的尾部
- 4、Slave啟動專門的SQL線程從relay log中獲取日志，并在本地重新執行SQL語句將數據回放到數據庫中，使Slave數據庫與Master數據庫保持數據一致
MySQL主從復制是異步的，Master提交完事務就直接返回了。會存在丟失數據的風險。
MySQL 5.5提供了半同步復制模式
- Master提交事務前，會等待Slave接收binlog，當至少有一個Slave確認接收binlog后（數據被寫入relay log后，并不是執行完SQL語句），Master才提交事務。
復制風暴：
- Master會因為向過多的Slave復制數據而壓力倍增。
- 解決方案：Slave向Slave復制數據
2.MHA（Master High Availability）
如何檢測節點故障和執行主從切換。
組成部分：
- MHA Manager：MHA是決策層，負責自動檢測Master的故障，檢查主從復制狀態，執行自動主從切換等。
- MHA Node：被部署在每臺MySQL服務器上，主要負責修復主從數據的差異。
MHA故障轉移流程
- MHA Manager會周期性地探測Master心跳，如果連續4次探測不到心跳，則認為Master宕機
- MHA Manager判斷各個Slave的binlog，哪個Slave的binlog數據更接近Master數據，就將哪個Slave作為備選Master
- MHA Node試圖通過SSH訪問Master所在的服務器（網絡可達，補齊數據；網絡不可達，Slave之間對比relay log差異，補齊數據）
- MHA Manager構建新主從關系，將備選Master提升為Master，其他Slave向新的Master復制數據
3.MMM（Multi-Master Replication Manager for MySQL）
MMM是一個MySQL雙主故障切換和雙主管理的腳本組件，它有兩個Master，并實現這兩個Master的高可用。
MMM通過移動虛擬IP地址的方式切換Master。當Master 1宕機時，Master 2可以立即上任，MySQL業務使用方不會感知到主從切換的發生。不過，MMM這套解決方案比較古老，不支持MySQL GTID，且社區活躍度不夠，目前MMM組件處于無人維護的狀態。
4.MGR（MySQL Group Replication）
MGR基于Paxos協議，所以主從節點數據有很強的一致性，可以做到數據不丟失。此外，在一個擁有2N + 1個節點的復制組中，MGR可以容忍N個節點發生故障，所以這套方案容忍性很高。
不過，數據強一致性的代價是每個寫請求都涉及與復制組內大多數節點的通信，所以MGR的寫性能不及異步復制和半同步復制，MGR更適合要求數據強一致性，且寫請求量不大的場景。
