MHA調研與應用的示例分析

小編給大家分享一下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調研與應用的示例分析”這篇文章的所有內容，感謝各位的閱讀！相信大家都有了一定的了解，希望分享的內容對大家有所幫助，如果還想學習更多知識，歡迎關注億速云行業資訊頻道！