MySQL高可用架構對比

Real_man發表於2019-04-03
MySql架構

MMM與MHA以及MGR，高可用架構都有如下的共同點：

  • 對主從複製叢集中的Master節點進行監控
  • 自動的對Master進行遷移，通過VIP。
  • 重新配置叢集中的其它slave對新的Master進行同步

MMM

需要兩個Master，同一時間只有一個Master對外提供服務，可以說是主備模式。

image-20190402160607794

需要基礎資源：

資源 數量 說明
主DB 2 用於主備模式的主主複製
從DB 0~N臺 可以根據需要配置N臺從伺服器
IP地址 2n+1 N為MySQL伺服器的數量
監控使用者 1 使用者監控資料庫狀態的MySQL使用者(replication)
代理使用者 1 用於MMM代理端改變read_only狀態

故障轉移步驟：

  • Slave伺服器上的操作
    • 完成原主上已經複製的日誌恢復
    • 使用Change Master命令配置新主
  • 主伺服器上操作
    • 設定read_only關閉
    • 遷移VIP到新主伺服器

優點：

  • 提供了讀寫VIP的配置，試讀寫請求都可以達到高可用
  • 工具包相對比較完善，不需要額外的開發指令碼
  • 完成故障轉移之後可以對MySQL叢集進行高可用監控

缺點：

  • 故障簡單粗暴，容易丟失事務，建議採用半同步複製方式，減少失敗的概率
  • 目前MMM社群已經缺少維護，不支援基於GTID的複製

適用場景：

  • 讀寫都需要高可用的
  • 基於日誌點的複製方式

MHA

image-20190402162734119

需要資源：

資源 數量 說明
主DB 2 用於主備模式的主主複製
從DB 2~N臺 可以根據需要配置N臺從伺服器
IP地址 n+2 N為MySQL伺服器的數量
監控使用者 1 使用者監控資料庫狀態的MySQL使用者(replication)
複製使用者 1 用於配置MySQL複製的使用者

MHA採用的是從slave中選出Master，故障轉移：

  • 從伺服器：
    • 選舉具有最新更新的slave
    • 嘗試從當機的master中儲存二進位制日誌
    • 應用差異的中繼日誌到其它的slave
    • 應用從master儲存的二進位制日誌
    • 提升選舉的slave為master
    • 配置其它的slave向新的master同步

優點：

  • MHA除了支援日誌點的複製還支援GTID的方式
  • 同MMM相比，MHA會嘗試從舊的Master中恢復舊的二進位制日誌，只是未必每次都能成功。如果希望更少的資料丟失場景，建議使用MHA架構。

缺點：

MHA需要自行開發VIP轉移指令碼。

MHA只監控Master的狀態，未監控Slave的狀態

MGR

MGR是基於現有的MySQL架構實現的複製外掛，可以實現多個主對資料進行修改，使用paxos協議複製，不同於非同步複製的多Master複製叢集。

支援多主模式，但官方推薦單主模式：

  • 多主模式下，客戶端可以隨機向MySQL節點寫入資料
  • 單主模式下，MGR叢集會選出primary節點負責寫請求，primary節點與其它節點都可以進行讀請求處理.

image-20190402165047454

// 檢視MGR的組員
select * from performance_schema.replication_group_members;
// 檢視MGR的狀態
select * from performance_schema.replication_group_member_stats;
// 檢視MGR的一些變數
show variables like 'group%';
// 檢視伺服器是否只讀
show variables like 'read_only%';
複製程式碼

優點：

  • 基本無延遲，延遲比非同步的小很多
  • 支援多寫模式，但是目前還不是很成熟
  • 資料的強一致性，可以保證資料事務不丟失

缺點:

  • 僅支援innodb
  • 只能用在GTID模式下，且日誌格式為row格式

適用的業務場景：

  • 對主從延遲比較敏感
  • 希望對對寫服務提供高可用，又不想安裝第三方軟體
  • 資料強一致的場景

讀寫負載大問題

讀負載大：

  • 增加slave

  • 加中間層(MyCat，ProxySQL，Maxscale)

  • 讀寫分離

關於寫負載大：

  • 分庫分表
  • 增加中間層

最後

參考慕課網課程，s.imooc.com/S8KFBvs

相關文章