共計 8299 個字符，預計需要花費 21 分鐘才能閱讀完成。

丸趣 TV 小編給大家分享一下 MHA 調研與應用的示例分析，相信大部分人都還不怎么了解，因此分享這篇文章給大家參考一下，希望大家閱讀完這篇文章后大有收獲，下面讓我們一起去了解一下吧！

MHA 調研與應用   一、問題與需求
1.1、問題匯總

1、沒有工具來快速切換集群主庫，如果切換主庫，需要 DBA 手動修改從庫指向，修改元信息等

2、需要能快速上線，不影響當前架構

3、需要全部自動化處理，方便 DBA 使用，例如檢查，操作，展示等

二、MHA 介紹 2.1、什么是 MHA

MHA（Master High Availability）目前在 MySQL 高可用方面是一個相對成熟的解決方案，它由日本 DeNA 公司 youshimaton 開發，是一套優秀的作為 MySQL 高可用性環境下故障切換和主從提升的高可用軟件。

在 MySQL 故障切換過程中，MHA 能做到在 0~30 秒之內自動完成數據庫的故障切換操作，并且在進行故障切換的過程中，MHA 能在最大程度上保證數據的一致性，以達到真正意義上的高可用。

2.2、MHA 原理

phase 1: Configuration Check Phase..

        mha will check the mha default file,then it can get the status of all mysql nodes and the relationship between them, who is master ,who is slave and who is dead ,who is alive.

Phase 2: Dead Master Shutdown Phase 

        使用 master_ip_failover_scirpt 和 shutdown script  to  shutdown or inactive the dead master ,（sush as  IP  or DNS switching，which was  defined in a self-defined script in advance ,just in case of split-brain）and I tend to use python. 

     （執行 master_ip_failover_script –command=stopssh 使原主庫 IP 失效；執行 SHUTDOWN script –command=stopssh，關閉原主庫）

Phase 3: Master Recovery Phase

     3.1 比較所有從庫的 bin log 的 pos 點，找出 latest binlog file pos 和 oldest file pos

     3.2 嘗試去原主庫上獲取 binlog

     3.3 根據 no_master、candidate_master 和各從庫延遲情況，選出新主庫；獲取新主庫的日志缺失情況

     3.4 給新選出來的主庫補日志，并激活新主庫。（生成 change master to 語句）

Phase 4: Slaves Recovery Phase

     4.1 給從庫補日志：從主庫上補日志，或者，從 lastest 從庫上給其他從庫補日志

     4.2  execute change master to command in all avaiable slaves , which is generated in former steps

Phase 5: New master cleanup

      清除新主庫的 slave info

[info] * Phase 1: Configuration Check Phase..
[info] ** Phase 1: Configuration Check Phase completed. 
[info] * Phase 2: Dead Master Shutdown Phase..
[info] * Phase 2: Dead Master Shutdown Phase completed.
[info] * Phase 3: Master Recovery Phase..
[info] * Phase 3.1: Getting Latest Slaves Phase..
[info] * Phase 3.2: Saving Dead Master s Binlog Phase..
[info] * Phase 3.3: Determining New Master Phase..
[info] * Phase 3.3: New Master Diff Log Generation Phase..
[info] * Phase 3.4: Master Log Apply Phase..
[info] * Phase 3: Master Recovery Phase completed.
[info] * Phase 4: Slaves Recovery Phase..
[info] * Phase 4.1: Starting Parallel Slave Diff Log Generation Phase..
[info] * Phase 4.2: Starting Parallel Slave Log Apply Phase..
[info] * Phase 5: New master cleanup phase..
[info] Sending mail..

2.3、MHA 優勢

1、不影響服務器性能，易安裝，不改變現有部署

2、故障切換（實現自動故障檢測和故障轉移，通常在 30 秒以內;）

3、數據一致性保證

2.4、mha 模式

按節點分為：manage/node 模式，即 MHA 管理機器與集群 node 節點

按切換分為：online/failover 模式切換，即在線切換與主庫損壞切換

2.5、MHA 要求

1、最少一主一從
2、ssh 互信

3、mysql 賬號

4、linux 系統

5、mysql 版本 5.0 及以后

6、mysqlbinlog 必須是 3.3 及以上版本

7、log-bin 必須在每一個可稱為 master 的 mysql 服務器上設置

8、所有 mysql 服務器的復制過濾規則必須一致

9、必須在能成為 master 的服務器上設置復制賬戶

10、基于語句的復制時，不要使用 load datainfile 命令

11、關閉 relay_log_purge，需要腳本 / 手動定期清理（清理方式：set global relay_log_purge=1;flush logs;）

2.6、MHA 版本選擇

從 MHA 的 0.56 版本開始，也支持基于 GTID 的故障切換。MHA 會自動檢測 mysqld 是否在 GTID 運行，如果 GTID 開啟，MHA 就實現帶 GTID 的故障切換，如果沒有啟用，MHA 就使用基于 relay log 的故障切換。

2.7、重要參數

ignore_fail=1                 忽略報錯

candidate_master=1    1：優先成為 master 0：不優先  

no_master=1               1：不能成為 master  0：可以成為 master

三、MHA 實現
3.1、架構圖

3.2、具體實現與自動化 3.2.1、mha 操作、部署、檢查等程序 –mhacluster

集成 mha 日常操作，部署，檢查，修復等功能

包括：

1 添加互信關系

2 安裝 MHA 軟件包等

3 授權相關賬戶

4 檢查 ssh、repl、conf 正確性等

5 自動修復問題集群

6 自動更新每個集群的 conf 文件

7 自動更新別名，方便使用

8 自動清理 relaylog

功能情況如下

 

3.2.2、mhacluster 功能 – 互信

中控 /MHA 管理機到所有機器互信 完成  

添加集群內部互信，利用 make_ssh_authentication.sh 腳本來自動添加互信

3.2.3、mhacluster 功能 – 授權

需要 super 權限的數據庫用戶，來源 集群的所有實例 IP 完成

3.2.4、mhacluster 功能 –relay_log_purge  設置  

默認設置為 off，利用腳本任務，定期清理

利用 MHA 自帶的 purge 腳本，部署到 crontab 就可以了（安裝完 node 自動會有，暫時沒有使用此方式，模擬此方式進行清理）                                                                                                       

3.2.5、mhacluster 功能 –mysqlbinlog 收集更新

因目前存在 binlog 目錄不固定，暫時先利用腳本收集入庫至元信息

3.3.6、mhacluster 功能 – 安裝軟件包

所有實例安裝 2 個軟件包

rpm -ivh /data/soft/perl-DBD-MySQL-4.013-3.el6.x86_64.rpm

rpm -ivh /data/soft/mha4mysql-node-0.56-0.el6.noarch.rpm

3.3.7、mhacluster 功能 – 檢查 ssh/repl/conf

檢查 mha 要求的 masterha_check_ssh/repl

檢查 mha 配置文件與元信息是否一致

3.3.8、mhacluster 功能 – 自動修復問題集群

自動修復 ssh/repl/conf 檢查問題的集群

3.3.9、mhacluster 功能 – 更新別名與 mha 配置文件

更新 mha 的常用別名

alias masterha_check_ssh.1= masterha_check_repl –conf=/data/masterha/conf/1#testdb

alias masterha_check_repl.1= masterha_check_repl –conf=/data/masterha/conf/1#testdb

注：此處的 1 為集群號

更新 mha 配置文件

根據元信息來更新 mha 的 conf 文件

3.3.9、mhacluster 功能 – 授權 mha 要求賬戶
自動授權 mha 要求的賬號

3.4、元信息字段情況

cluster_id   集群號  

cluster_name 集群名  

role：Master，Slave,Backup   角色  

binlog_dir  binlog 地址

no_master   不能成為 master，1 不能成為 master，0 可以

candidate_master   是否優先可切為 master，1 優先，0 不優先 ,

mha_write_into_conf   是否寫到配置文件，1 寫入，0 不寫入

3.5、MHA 配置
3.5.1、MHA 默認配置文件

[root@dbmon conf]# vi /etc/masterha_default.cnf 

[server default]

manager_workdir=/data/masterha/work/

user=dba

password=

ssh_user=root

repl_user=repadm

repl_password=

ping_interval=30

shutdown_script=

master_ip_failover_script= /data/mha/master_ip_failover_script.py   注：failover 模式切換主腳本

master_ip_online_change_script= /data/mha/master_ip_online_change_script.py       注： online 模式切換主腳本

report_script= /data/mha/send_report.py           注：  發送切換后郵件主腳本

3.5.2、mha 的集群 conf 配置文件

根據元信息自動生成

[server1]

hostname=10.0.0.1

port=3306

master_binlog_dir=/data/my3306/

ignore_fail=1

no_master=1

candidate_master=0

[server2]

hostname=10.0.0.2

port=3306

master_binlog_dir=/data/my3306/

ignore_fail=1

no_master=0

candidate_master=0

3.6、切換程序 –mhaswitch

切換程序，利用 Python 封裝，方便日常切換使用  

支持批量切換集群

切換方式：online/dead 模式切換，即原主庫存活切換，原主庫故障切換

3.6.1、mhaswitch 架構

注：其他輔助腳本暫時不標注

3.6.2、mhaswitch 功能 – 展示切換信息

可以展示集群的實例信息，如下

3.6.3、mhaswitch 功能 –2 種切換方式

支持 online 模式與 failover 模式 切換（對應程序的 alive，dead）

online 模式：可選原主庫是否作為新主庫的從庫

failover 模式：關閉原主庫進行切換

3.6.4、mhaswitch 輔助腳本 –master_ip_failover_script.py 功能  
1 當傳入命令為 stopssh 或 stop，即關閉原主庫

2 等 2 秒檢查原主庫是否關閉，沒有關閉會 print old master still run,please check , 程序退出

3 當傳入命令為 start 時，開始進行元數據的修改

4 修改域名 -IP 的對應關系

5 設置新主庫 read_only=off，同時修改配置文件

6 修改原主庫 read_only=on，同時修改配置文件

3.6.5、 mhaswitch 輔助腳本 –master_ip_online_change_script.py  功能

1 當傳入命令為 stopssh 或 stop，即設置原主庫為 read_only

2 檢查原主庫是否為 read_only，如果沒有 read_only 會 print not read_only,please check , 程序退出

3 當傳入命令為 start 時，開始進行元數據的修改

4 修改域名 -IP 的對應關系

5 設置新主庫 read_only=off，同時修改配置文件

6 修改原主庫 read_only=on，同時修改配置文件

3.6.6、mhaswitch 輔助腳本 –send_report.py 功能

1 發送 failover 模式切換的日志，切換結果

2 發送 MHA 配置文件地址

3 老主庫 IP，端口

4 新主庫 IP，端口

5 庫名，服務名

6 檢查切換后的集群狀態（表格形式）：

集群號，IP，角色，是否可以連接，slave sql 線程，slave io 線程，slave 所指主庫 host 檢查，slave 所指主庫端口檢查，slave 延遲，連接數，/data 空間情況，只讀情況，時間

3.6.7、mhaswitch 輔助腳本 –online_switch_send_report.py 功能

1 發送在線切換的日志，切換結果

2 發送 MHA 配置文件地址

3 老主庫 IP，端口

4 新主庫 IP，端口

5 庫名，服務名

6 檢查切換后的集群狀態（表格形式）：

集群號，IP，角色，是否可以連接，slave sql 線程，slave io 線程，slave 所指主庫 host 檢查，slave 所指主庫端口檢查，slave 延遲，連接數，/data 空間情況，只讀情況，時間

3.6.8、mhaswitch 輔助腳本 –change_domain_ip.sh 功能

1 更改域名 -IP 的對應關系腳本

3.7、開始切換
3.7.1、mhaswitch 使用說明

mhaswitch 

請輸入要切換的集群號:78            注：切換的集群號

### 請輸入集群 [78] 主庫的狀態【alive/dead】:alive            注：選擇切換方式

                                                                1 alive，不關閉原主庫

                                                                2 dead，關閉原主庫    

將利用 MHA 的 online 模式切換，主庫不會關閉，且 老主庫 是否作為 新集群 的 從庫 呢？【yes/no】, 默認 no:yes                  注：選擇 alive 后：需要選擇 原主庫 是否 作為新主庫的從庫，yes 是，no 不做（即設置 read_only 后不關閉）

### 是否進行切換【yes/no】, 默認 no:yes     注：是否確認開始切換，yes 確認即開始切換，no 退出

3.7.2、切換后檢查

1 查看 mhaswitch 輸出
2 查看郵件
3 查看實例狀態報表

4 查看新主庫訪問等

5 檢查數據一致性等

3.8、切換舉例

此處只舉例一個 online 模式的切換，failover 模式類似

3.8.1、切換前集群拓撲

3.8.2、mhaswitch 切換

 

3.8.3、切換后

拓撲情況

 

郵件情況

輸入用時： 10 秒 左右  

切換用時： 3- 5 秒左右

檢查、更新及郵件用時： 5 秒

總計：18-20 秒左右，實際影響業務寫時間為 3 - 5 秒左右

四、監控
4.1、MHA 日常檢查監控

檢查 ssh、repl、conf 正確性，檢查程序為 mhacluster，結果入庫并利用 django 前端展示

命令為：

python mhacluster.py –options=check_all_mha_ssh_repl_conf

前端報表為：

 

且支持自動修復，即根據報錯情況進行修復，命令如下：

python mhacluster.py –options=auto_repair_all_mha_fail

4.2、relaylog_purge 監控

清理過期 relay_log，并檢查程序運行狀態及清理后狀態，入庫并前端展示，命令如下

python mhacluster.py –options=purge_relaylog_all

前端：

 

4.3、實例狀態檢查

檢查實例運行狀態，包括 readonly，從庫 IO,SQL 線程，從庫所指主庫 IP,port 是否正確，主從延遲，連接數，空間情況等，來方便查看集群切換后的狀態，可快速定位問題

python mysql_check.py  –options=check_all

前端報表如下：

 

五、常見切換報錯及處理
5.1、切換常見情況

1 沒有切換，元信息等都沒有更改

2 切換了，部分從庫實例切換失敗

5.2、MHA 的 masterha_check_ssh/repl 檢查失敗，無法切換

情況：沒有切換，元信息沒有修改

原因：

masterha_check_repl 檢查失敗的原因有多種：

1 無信任關系

2 賬戶權限問題

3 無可切為主庫設置問題等

解決：

1,2 問題可以通過初始化 mha 環境來解決

python mhacluster.py –options=add_mha_single_cluster –cluster_ids=1,2,3 

3 問題：數據庫不可切，優先切，是否寫入配置文件 配置錯誤問題，改正確即可

5.3、MHA 切換，部分從庫切換失敗

情況：已經切換了，部分從庫有問題

原因：原因比較復雜，例如網絡，本身 change 命令無法執行（例如 5.7 的某些配置導致）等

處理：

1 檢查實例狀態，確認哪些實例有問題

查看報表：實例狀態即可確認，例如：

2 修復切換失敗的從庫

根據日志等情況進行修復或者重做。

六、線上表現及優點
6.1、線上切換

目前已經成功在線上運行 4 個月以上，已經切換線上集群 6 個以上（線上測試環境切換 30+），暫時沒有發現問題

真正切換耗時大約在秒級（多數在 3 -5s 之間）

6.2、使用 MHA 環境 之前的情況

1、沒有方便的工具來快速切換集群主庫，發生主庫故障時：

  需要 DBA 花費 5 分鐘手動修改從庫指向，2- 3 分鐘檢查集群狀態，3- 5 分鐘修改元信息，

實際停機操作時間 3 - 5 分鐘；等共需要 10-20 分鐘

（僅 DBA 操作）

2、沒有工具快速顯示某集群拓撲情況

3、沒有工具快速檢查實例運行情況

6.3、使用 MHA 環境   后情況  

1、利用 mhaswitch 工具來快速切換主庫

    1 可以降低丟失數據的風險

    2 影響寫入時間少，秒級

切換前后共需要 5 分鐘左右（僅 DBA 操作），實際停機操作：3-30s 左右（如果在線切換大致在 3 -5s，如果是停原主庫切換，則大于 10s）

DBA 效率提升 50%-75% 左右，快的話總時間可控制在 1 分鐘內

線上實際操做：輸入信息 10s 左右，切換影響寫入  3-5s  左右，更新與檢查等 9s 左右，共計 22-24s 左右

    3 mhacluster 集成部署，幾個小時即可自動部署全部 mysql 實例（目前近 700 個實例，近 500 臺機器，實際部署與檢查大約 4 - 6 個小時）

    4 無需 DBA 手動修改主從，節約手動操作時間約 10-20 分鐘

    5 無需 DBA 手動修改元信息, 節約修改元信息時間 3 - 5 分鐘左右

      無需 DBA 手動調整域名 IP 關系，節約調整域名 IP 時間 1 - 3 分鐘左右

    6 封裝 MHA，方便 DBA 使用，無需繁瑣命令

    7 郵件程序，發送信息全，可快速查看切換結果與日志等

2、查詢集群拓撲工具 qmysql，1 秒內查看集群拓撲

3、檢查集群狀態工具 mysql_check，查詢近 700 個實例，近 500 臺機器   僅需 30s 左右

4、django 前端展示，MHA 監控，報表，方便監控 MHA 情況與排錯等

以上是“MHA 調研與應用的示例分析”這篇文章的所有內容，感謝各位的閱讀！相信大家都有了一定的了解，希望分享的內容對大家有所幫助，如果還想學習更多知識，歡迎關注丸趣 TV 行業資訊頻道！