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