- Mysql 介紹
- 高可用結構
- 主從模式
- 主從模式介紹
- 主從複製技術
- 主從模式注意事項
- MHA（MasterHighAvailability）
- MHA模式介紹
- MHA工作流程
- MMM（Multi-MasterReplicationManagerForMysql）
- MGR（MysqlGroupReplication）
- 總結
Mysql 介紹
Mysql是典型的開源關係型資料庫，是許多網站、應用程式、企業軟體產品的首選資料庫。
Mysql特性：
- 易於使用，功能強大，支援事務、觸發器、儲存過程
- 管理工具多種多樣且功能豐富
- 可以作為千萬級資料管理的大型資料庫
- 採用GPL開源協議，允許自由修改原始碼並應用到商業系統中
- Mysql的InnoDB事務性儲存引擎符合事務ACID模型，能保證完整、可靠地進行資料地儲存
高可用結構
-
主從模式
-
MHA
-
MMM
-
MGR
主從模式
主從模式介紹
主從模式是最基本的Mysql高可用架構，一臺伺服器作為Master節點，若干伺服器作為Slave節點。只有Master處理寫資料請求，讀請求可僅由Slave節點處理，也可讓Master、Slave同時處理。
Master和Slave透過主從複製技術保持資料一致，即Master節點將資料同步給Slave節點。
主從模式具備高可用的基礎是主從複製技術。
主從複製技術
- 當Master 資料發生變更（新增、刪除、修改）時，Master將變更日誌寫入二進位制日誌檔案 binlog
- Slave啟動單獨執行緒（I/O執行緒）與Master建立網路連線，從Master的binlog中獲取變更日誌
- Slave的I/O執行緒捕獲到資料變更日誌後，按照順序儲存到中繼日誌檔案 relay log
- Slave啟動單獨執行緒（Sql執行緒）從relay log 中讀取日誌並執行，使Slave 庫的資料和Master一致
主從模式注意事項
Mysql 5.5之前主從複製為非同步方式，Master 提交事務不需要經過Slave 們的確認，那麼就會有這種極端情況：
- Slave 讀取Master 的binlog失敗了
- Slave 處理relay log 失敗了
- Slave 執行Sql語句失敗了
- 等......
類似的極端情況將導致資料不一致。所以在Mysql 5.5 主從複製提供了半同步的方式，具體來說就是增加了ACK確認的機制，當Slave接收到binlog 後，會給Master 傳送一條確認訊息，Master在接收到ACK確認訊息之後才會提交事務。半同步方式可以提高資料的一致性，但是Master在寫入資料的時候需要等待Slave的確認，所以效能會有所下降。
複製風暴問題，來考慮這樣一種更加極端的情況，一個Master ，10個Slave ， 這種情況下基於主從複製技術，Master在寫入資料前需要同時處理10個Slave的資料複製請求，這種情況下對於Master只能說是不堪重負，如果在加上“半同步機制”，寫入效能將大打折扣，這種情況稱之為複製風暴問題。解決這種問題的方法是，Master 僅處理一個Slave的主從複製，其它的Slave複製由Slave負責。
MHA（MasterHighAvailability）
MHA模式介紹
以主從模式為基礎，接下來就該考慮如下問題了：
- 如何檢測節點故障
- master節點故障之後如何重新選舉
MHA就是在解決這兩個問題的，理論上，MHA模式可以在10s-30s內完成主從叢集的自動故障檢測和自動主從切換。
MHA由兩個部分組成：
- MHA-Manager：負責自動檢測Master是否故障，檢查主從複製狀態，執行自動主從切換等。需要單獨伺服器部署。
- MHA-Node：負責修復主從資料的差異，通常和Mysql伺服器例項繫結部署。
MHA工作流程
-
Manager 和 Master之間心跳，如果連續4次探測不到心跳，就認為該Master當機了，Master例項繫結一個Node。
-
Manager 分析各個Slave的binlog，選擇一個更接近Master資料的Slave作為備選Master，一個Slave例項分別繫結一個Node。
-
Slave的Node試圖透過SSH訪問Master所在伺服器：
- 如果可達，Slave的Node獲取Master的binlog資料，若發現Master和Slave資料存在差異，會將差異資料主動複製到Slave，以保持主從資料一致。
- 如果不可達，Node對比各個Slave的relay log 差異，並做差異資料補齊。
-
Manager將備選Master提升為Master。
MMM（Multi-MasterReplicationManagerForMysql）
MMM模式簡單來說就是引入虛擬IP（vip）技術，這種架構下，一個叢集中有兩個Master和若干個Slave，當其中一個Master不可用的時候，MMM會指示vip切換到另外一個Master上面，同時會向所有的Slave傳送更換Master的訊息，之後主從複製將切換到新的Master。
此方案比較古老，不支援Mysql GTID ，並且社群活躍度不夠，目前處於無人維護的狀態。
MGR（MysqlGroupReplication）
MGR，Mysql組複製模式是Mysql5.7.17版本推出的高可用解決方案，具備如下特性：
- 一致性高：資料複製基於分散式共識演算法Paxos，可以保證多個節點資料的一致性
- 容錯性高：只要不是超過一半的節點當機，就可以繼續提供服務
- 靈活性強：MGR支援單主模式和多主模式，單主模式下如果Master故障，Slave們會重新選舉一個新的Master，多主模式下每一個Mysql節點都可以同時處理寫請求
MGR要求至少由3個Mysql節點組成一個複製組，即一主兩從，一個事務必須經過複製組內超過半數節點透過後才能提交。
如果在不同的Mysql節點上執行不同的寫操作發生了事務衝突，那麼先提交的事務先執行，後提交的事務被回滾。在多主模式下，由於每個Mysql節點都可以執行寫請求，在寫請求高併發的場景下發生事務衝突的機率會非常大，會造成大量事務回滾。
在單主模式下，MGR會自動為複製組選擇一個Master負責寫請求，如果複製組內超過一半節點與Master通訊失敗，就認為Master當機了，這時會根據各個節點的權重和ID標識重新選主。
MGR更加適合一致性強，寫併發量不大的場景下使用。
總結
本文闡述了Mysql高可用架構方案，介紹了 主從模式，MHA模式，MMM模式，MGR模式 方案的實現方式，沒有哪個方案是完美的，開發人員在選擇何種方案應用到專案中也沒有標準答案，合適的才是最好的。