Mysql高可用架構方案

目錄

• 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模式 方案的實現方式，沒有哪個方案是完美的，開發人員在選擇何種方案應用到專案中也沒有標準答案，合適的才是最好的。