MySQL高可用架構之MHA(1)

目錄

  • 一、當前高可用方案
    • 1、Heartbeat+DRBD
    • 2、MySQL Cluster
    • 3、全局事務ID
    • 4、PXC
    • 5、MHA的優勢
      • 1)故障切換快
      • 2)master故障不會導致數據不一致
      • 3)無需修改當前的MySQL設置
      • 4)無需增加大量的伺服器
      • 5)無性能下降
      • 6)適用於任何存儲引擎
  • 二、MHA簡介:
    • 1、MHA結構
      • 1)MHA Manager
        • 1.Manager工具包主要工具
      • 2)MHA Node
        • 1.Node工具包
      • 3)注意
    • 2、MAH工作原理
  • 三、部署MHA
    • 1、環境準備
    • 2、安裝epel源
    • 3、環境初始化
      • 1)修改每台主機名
      • 2)主機名解析
      • 3)ssh無密碼登錄
  • 四、規劃mysql
    • 1)安裝mysql
    • 2)配置master、slave01和slave02之間的主從複製
    • 3)在master、slave01上創建主從同步的賬號。
    • 4)在master上執行命令,查看master狀態信息
    • 5)在slave01和slave02上執行主從同步
  • 五、規劃mha
    • 1)創建mha管理用的複製賬號
    • 2)在3台主機上(master、slave01和slave02)上分別安裝mha4mysql-node包
    • 3)在manager上安裝mha4mysql-manager和mha4mysql-node包
    • 4)修改manager端mha的配置文件
    • 5)檢查ssh是否暢通
    • 6)masterha_check_repl工具檢查mysql主從複製是否成功
  • 六、mha實驗模擬
    • 1)在每次做mha實驗的時候,我們都最好先執行如下命令做檢測
    • 2)在manager端啟動mha服務並時刻監控日誌文件的輸出變化
    • 3)測試master宕機後會自動切換
    • 4)恢復master服務
    • 5)再次啟動MHA的manager服務,並停止slave01
    • 6)恢復slave01服務
    • 7)重啟MHA的manager服務
  • 七、通過vip實現mysql的高可用
    • 1)修改/usr/local/mha/mha.cnf
    • 2)修改腳本/usr/local/mha/scripts/master_ip_failover
    • 3)模擬故障進行切換
  • 八、MHA日常維護命令
    • 1、查看ssh登陸是否成功
    • 2、查看複製是否建立好
    • 3、啟動mha
    • 4、檢查啟動的狀態
    • 5、停止mha
    • 6、failover後下次重啟
  • 九、FAQ(常見問題解答)
    • 1、可能報錯1
    • 2、可能報錯2
    • 3、可能報錯3
    • 4、可能報錯4
    • 5、可能報錯5
    • 6、小知識

一、當前高可用方案

1、Heartbeat+DRBD

開銷:需要額外添加處於被動狀態的master server(並不處理應用流量) 性能:為了實現DRBD複製環境的高可用,innodb-flush-log-at-trx-commit和sync-binlog必須設置為1,這樣會導致寫性能下降。

一致性:在master上必要的binlog時間可能會丟失,這樣slave就無法進行複製,導致產生數據一致性問題。

2、MySQL Cluster

MySQL Cluster真正實現了高可用,但是使用的是NDB存儲引擎,並且SQL節點有單點故障問題。

半同步複製(5.5+) 半同步複製大大減少了「binlog events只存在故障master上」的問題。

在提交時,保證至少一個slave(並不是所有的)接收到binlog,因此一些slave可能沒有接收到binlog。

3、全局事務ID

在二進位文件中添加全局事務ID(global transaction id)需要更改binlog格式,在5.1/5.5版本中不支持。

在應用方面有很多方法可以直線全局事務ID,但是仍避免不了複雜度、性能、數據丟失或者一致性的問題。

4、PXC

PXC實現了服務高可用,數據同步時是並發複製。但是僅支持InnoDB引擎,所有的表都要有主鍵。鎖衝突、死鎖問題相對較多等等問題。

5、MHA的優勢

1)故障切換快

在主從複製集群中,只要從庫在複製上沒有延遲,MHA通常可以在數秒內實現故障切換。9-10秒內檢查到master故障,可以選擇在7-10秒關閉master以避免出現裂腦,幾秒鐘內,將差異中繼日誌(relay log)應用到新的master上,因此總的宕機時間通常為10-30秒。恢復新的master後,MHA並行的恢復其餘的slave。即使在有數萬台slave,也不會影響master的恢復時間。

2)master故障不會導致數據不一致

當目前的master出現故障是,MHA自動識別slave之間中繼日誌(relay log)的不同,並應用到所有的slave中。這樣所有的salve能夠保持同步,只要所有的slave處於存活狀態。和Semi-Synchronous Replication一起使用,(幾乎)可以保證沒有數據丟失。

3)無需修改當前的MySQL設置

MHA的設計的重要原則之一就是儘可能地簡單易用。MHA工作在傳統的MySQL版本5.0和之後版本的主從複製環境中。和其它高可用解決方法比,MHA並不需要改變MySQL的部署環境。MHA適用於非同步和半同步的主從複製。

啟動/停止/升級/降級/安裝/卸載MHA不需要改變(包擴啟動/停止)MySQL複製。當需要升級MHA到新的版本,不需要停止MySQL,僅僅替換到新版本的MHA,然後重啟MHA Manager就好了。

MHA運行在MySQL 5.0開始的原生版本上。一些其它的MySQL高可用解決方案需要特定的版本(比如MySQL集群、帶全局事務ID的MySQL等等),但並不僅僅為了master的高可用才遷移應用的。在大多數情況下,已經部署了比較舊MySQL應用,並且不想僅僅為了實現Master的高可用,花太多的時間遷移到不同的存儲引擎或更新的前沿發行版。MHA工作的包括5.0/5.1/5.5的原生版本的MySQL上,所以並不需要遷移。

4)無需增加大量的伺服器

MHA由MHA Manager和MHA Node組成。

MHA Node運行在需要故障切換/恢復的MySQL伺服器上,因此並不需要額外增加伺服器。

MHA Manager運行在特定的伺服器上,因此需要增加一台(實現高可用需要2台),但是MHA Manager可以監控大量(甚至上百台)單獨的master,因此,並不需要增加大量的伺服器。即使在一台slave上運行MHA Manager也是可以的。綜上,實現MHA並沒用額外增加大量的服務。

5)無性能下降

MHA適用與非同步或半同步的MySQL複製。監控master時,MHA僅僅是每隔幾秒(默認是3秒)發送一個ping包,並不發送重查詢。可以得到像原生MySQL複製一樣快的性能。

6)適用於任何存儲引擎

MHA可以運行在只要MySQL複製運行的存儲引擎上,並不僅限制於InnoDB,即使在不易遷移的傳統的MyISAM引擎環境,一樣可以使用MHA。

二、MHA簡介:

MHA(Master High Availability),是比較成熟的MySQL高可用方案。MHA能夠在30秒內實現故障切換,並能在故障切換中,最大可能的保證數據一致性。目前淘寶也正在開發相似產品TMHA,目前已支持一主一從。

1、MHA結構

該軟體由兩部分組成:MHA Manager(管理節點)和MHA Node(數據節點)。

1)MHA Manager

可以單獨部署在一台獨立的機器上管理多個master-slave集群,也可以部署在一台slave節點上。MHA Manager主要運行一些工具,比如masterha_manager工具實現自動監控MySQL Master和實現master故障切換,其它工具實現手動實現master故障切換、在線master轉移、連接檢查等等。

1.Manager工具包主要工具

masterha_check_ssh 檢查MHA的SSH配置狀況masterha_check_repl 檢查MySQL複製狀況masterha_manger 啟動MHAmasterha_check_status 檢測當前MHA運行狀態masterha_master_monitor 檢測master是否宕機masterha_master_switch 控制故障轉移(自動或者手動)masterha_conf_host 添加或刪除配置的server信息

2)MHA Node

MHA Node 運行在每台MySQL伺服器上MHA Manager會定時探測集群中的master節點,當master出現故障時,它可以自動將最新數據的slave提升為新的master,然後將所有其他的slave重新指向新的master。整個故障轉移過程對應用程序完全透明。

部署在所有運行MySQL的伺服器上,無論是master還是slave。主要作用有三個。

Ⅰ、保存二進位日誌 如果能夠訪問故障master,會拷貝master的二進位日誌

II、應用差異中繼日誌 從擁有最新數據的slave上生成差異中繼日誌,然後應用差異日誌。

III、清除中繼日誌 在不停止SQL線程的情況下刪除中繼日誌

1.Node工具包

這些工具通常由MHA Manager的腳本觸發,無需人為操作主要包括以下幾個工具:

save_binary_logs 保存和複製master的二進位日誌apply_diff_relay_logs 識別差異的中繼日誌事件並將其差異的事件應用於其他的slavefilter_mysqlbinlog 去除不必要的ROLLBACK事件(MHA已不再使用這個工具)purge_relay_logs 清除中繼日誌(不會阻塞SQL線程)

3)注意

為了儘可能的減少主庫硬體損壞宕機造成的數據丟失,因此在配置MHA的同時建議配置成MySQL 5.5的半同步複製。關於半同步複製原理各位自己進行查閱。(不是必須)

2、MAH工作原理

1.從宕機崩潰的Master保存二進位日誌事件(binlog event);

2.識別含有最新更新的Slave;

3.應用差異的中繼日誌(relay log)到其他Slave;

4.應用從Master保存的二進位日誌事件;

5.提升一個Slave為新的Master;

6.使其他的Slave連接新的Master進行複製;

AD


推薦閱讀:

全局唯一ID在分散式系統中用來做什麼用?
資料庫高可用的定義和度量
探究高可用服務端架構的優秀資料索引
開源資料庫MySQL架構優劣對比
來自滴滴、微博、唯品會、魅族、點評關於高可用架構的實踐分享

TAG:MySQL | 系統架構 | 高可用 |