小編給大家分享一下MHA調(diào)研與應(yīng)用的示例分析，相信大部分人都還不怎么了解，因此分享這篇文章給大家參考一下，希望大家閱讀完這篇文章后大有收獲，下面讓我們一起去了解一下吧！
1、沒有工具來快速切換集群主庫，如果切換主庫，需要DBA手動(dòng)修改從庫指向，修改元信息等
2、需要能快速上線，不影響當(dāng)前架構(gòu)
3、需要全部自動(dòng)化處理，方便DBA使用，例如檢查，操作，展示等
MHA（Master High Availability）目前在MySQL高可用方面是一個(gè)相對成熟的解決方案，它由日本DeNA公司youshimaton開發(fā)，是一套優(yōu)秀的作為MySQL高可用性環(huán)境下故障切換和主從提升的高可用軟件。
在MySQL故障切換過程中，MHA能做到在0~30秒之內(nèi)自動(dòng)完成數(shù)據(jù)庫的故障切換操作，并且在進(jìn)行故障切換的過程中，MHA能在大程度上保證數(shù)據(jù)的一致性，以達(dá)到真正意義上的高可用。
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.
（執(zhí)行master_ip_failover_script --command=stopssh 使原主庫IP 失效；執(zhí)行SHUTDOWN script --command=stopssh，關(guān)閉原主庫）
Phase 3: Master Recovery Phase
3.1 比較所有從庫的bin log的pos點(diǎn)，找出latest binlog file&pos和oldest file&pos
3.2 嘗試去原主庫上獲取binlog
3.3 根據(jù)no_master、candidate_master和各從庫延遲情況，選出新主庫；獲取新主庫的日志缺失情況
3.4 給新選出來的主庫補(bǔ)日志，并激活新主庫。 （生成change master to語句）
Phase 4: Slaves Recovery Phase
4.1 給從庫補(bǔ)日志：從主庫上補(bǔ)日志，或者，從lastest從庫上給其他從庫補(bǔ)日志
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..
1、不影響服務(wù)器性能，易安裝，不改變現(xiàn)有部署
2、故障切換（實(shí)現(xiàn)自動(dòng)故障檢測和故障轉(zhuǎn)移，通常在30秒以內(nèi);）
3、數(shù)據(jù)一致性保證
按節(jié)點(diǎn)分為：manage/node模式，即MHA管理機(jī)器與集群node節(jié)點(diǎn)
按切換分為：online/failover模式切換，即在線切換與主庫損壞切換
1、最少一主一從
2、ssh互信
3、mysql賬號
4、linux系統(tǒng)
5、mysql版本5.0及以后
6、mysqlbinlog必須是3.3及以上版本
7、log-bin必須在每一個(gè)可稱為master的mysql服務(wù)器上設(shè)置
8、所有mysql服務(wù)器的復(fù)制過濾規(guī)則必須一致
9、 必須在能成為master的服務(wù)器上設(shè)置復(fù)制賬戶
10、基于語句的復(fù)制時(shí)，不要使用load datainfile命令
11、關(guān)閉relay_log_purge，需要腳本/手動(dòng)定期清理（清理方式：set global relay_log_purge=1;flush logs;）
2.6、MHA版本選擇
從MHA的0.56版本開始，也支持基于GTID的故障切換。MHA會自動(dòng)檢測mysqld是否在GTID運(yùn)行，如果GTID開啟，MHA就實(shí)現(xiàn)帶GTID的故障切換，如果沒有啟用，MHA就使用基于relay log的故障切換。
2.7、重要參數(shù)
ignore_fail=1 忽略報(bào)錯(cuò)
candidate_master=1 1：優(yōu)先成為master 0：不優(yōu)先
no_master=1 1：不能成為master 0：可以成為master
集成mha日常操作，部署，檢查，修復(fù)等功能
包括：
<1>添加互信關(guān)系
<2>安裝MHA軟件包等
<3>授權(quán)相關(guān)賬戶
<4>檢查ssh、repl、conf正確性等
<5>自動(dòng)修復(fù)問題集群
<6>自動(dòng)更新每個(gè)集群的conf文件
<7>自動(dòng)更新別名，方便使用
<8>自動(dòng)清理relaylog
功能情況如下
中控/MHA管理機(jī)到所有機(jī)器互信 完成
添加集群內(nèi)部互信，利用make_ssh_authentication.sh腳本來自動(dòng)添加互信
需要super 權(quán)限的數(shù)據(jù)庫用戶，來源 集群的所有實(shí)例IP 完成
默認(rèn)設(shè)置為off，利用腳本任務(wù)，定期清理
利用MHA自帶的purge腳本，部署到crontab就可以了（安裝完node自動(dòng)會有，暫時(shí)沒有使用此方式，模擬此方式進(jìn)行清理）
因目前存在binlog目錄不固定，暫時(shí)先利用腳本收集入庫至元信息
所有實(shí)例安裝2個(gè)軟件包
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
檢查mha要求的masterha_check_ssh/repl
檢查mha配置文件與元信息是否一致
自動(dòng)修復(fù)ssh/repl/conf 檢查問題的集群
更新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配置文件
根據(jù)元信息來更新mha的conf文件
自動(dòng)授權(quán)mha要求的賬號
cluster_id 集群號
cluster_name 集群名
role：Master，Slave,Backup 角色
binlog_dir binlog地址
no_master 不能成為master，1不能成為master，0可以
candidate_master 是否優(yōu)先可切為master，1優(yōu)先，0不優(yōu)先',
mha_write_into_conf 是否寫到配置文件，1寫入，0不寫入
[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" 注： 發(fā)送切換后郵件主腳本
根據(jù)元信息自動(dòng)生成
[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
切換程序，利用Python封裝，方便日常切換使用
支持批量切換集群
切換方式：online/dead 模式切換，即原主庫存活切換，原主庫故障切換
注：其他輔助腳本暫時(shí)不標(biāo)注
可以展示集群的實(shí)例信息，如下
支持online模式與failover模式 切換（對應(yīng)程序的alive，dead）
online模式：可選原主庫是否作為新主庫的從庫
failover模式：關(guān)閉原主庫進(jìn)行切換
<1>當(dāng)傳入命令為stopssh 或 stop，即關(guān)閉原主庫
<2>等2秒檢查原主庫是否關(guān)閉，沒有關(guān)閉會print "old master still run,please check",程序退出
<3>當(dāng)傳入命令為start 時(shí)，開始進(jìn)行元數(shù)據(jù)的修改
<4>修改域名-IP的對應(yīng)關(guān)系
<5>設(shè)置新主庫read_only=off，同時(shí)修改配置文件
<6>修改原主庫read_only=on，同時(shí)修改配置文件
<1>當(dāng)傳入命令為stopssh 或 stop，即設(shè)置原主庫為read_only
<2>檢查原主庫是否為read_only，如果沒有read_only會print " not read_only,please check",程序退出
<3>當(dāng)傳入命令為start 時(shí)，開始進(jìn)行元數(shù)據(jù)的修改
<4>修改域名-IP的對應(yīng)關(guān)系
<5>設(shè)置新主庫read_only=off，同時(shí)修改配置文件
<6>修改原主庫read_only=on，同時(shí)修改配置文件
<1>發(fā)送failover模式切換的日志，切換結(jié)果
<2>發(fā)送MHA配置文件地址
<3>老主庫IP，端口
<4>新主庫IP，端口
<5>庫名，服務(wù)名
<6>檢查切換后的集群狀態(tài)（表格形式）：
集群號，IP，角色，是否可以連接，slave sql線程，slave io線程，slave所指主庫host檢查，slave所指主庫端口檢查，slave延遲，連接數(shù)，/data空間情況，只讀情況，時(shí)間
<1>發(fā)送在線切換的日志，切換結(jié)果
<2>發(fā)送MHA配置文件地址
<3>老主庫IP，端口
<4>新主庫IP，端口
<5>庫名，服務(wù)名
<6>檢查切換后的集群狀態(tài)（表格形式）：
集群號，IP，角色，是否可以連接，slave sql線程，slave io線程，slave所指主庫host檢查，slave所指主庫端口檢查，slave延遲，連接數(shù)，/data空間情況，只讀情況，時(shí)間
<1>更改域名-IP的對應(yīng)關(guān)系腳本
mhaswitch
請輸入要切換的集群號:78 注：切換的集群號
###請輸入集群 ['78'] 主庫的狀態(tài)【alive/dead】:alive 注：選擇切換方式
<1>alive，不關(guān)閉原主庫
<2>dead，關(guān)閉原主庫
將利用MHA的online模式切換，主庫不會關(guān)閉，且 '老主庫' 是否作為 '新集群' 的 '從庫' 呢？【yes/no】,默認(rèn)no:yes 注：選擇alive后：需要選擇 原主庫 是否 作為新主庫的從庫，yes 是，no不做（即設(shè)置read_only后不關(guān)閉）
### 是否進(jìn)行切換【yes/no】,默認(rèn)no:yes 注：是否確認(rèn)開始切換，yes確認(rèn)即開始切換，no退出
<1>查看mhaswitch輸出
<2>查看郵件
<3>查看實(shí)例狀態(tài)報(bào)表
<4>查看新主庫訪問等
<5>檢查數(shù)據(jù)一致性等
此處只舉例一個(gè)online模式的切換，failover模式類似
拓?fù)淝闆r
郵件情況
輸入用時(shí)： 10秒 左右
切換用時(shí)： 3-5秒左右
檢查、更新及郵件用時(shí)： 5秒
總計(jì)：18-20秒左右，實(shí)際影響業(yè)務(wù)寫時(shí)間為3-5秒左右
檢查ssh、repl、conf正確性，檢查程序?yàn)閙hacluster，結(jié)果入庫并利用django前端展示
命令為：
python mhacluster.py --options=check_all_mha_ssh_repl_conf
前端報(bào)表為：
且支持自動(dòng)修復(fù)，即根據(jù)報(bào)錯(cuò)情況進(jìn)行修復(fù)，命令如下：
python mhacluster.py --options=auto_repair_all_mha_fail
清理過期relay_log，并檢查程序運(yùn)行狀態(tài)及清理后狀態(tài)，入庫并前端展示，命令如下
python mhacluster.py --options=purge_relaylog_all
前端：
檢查實(shí)例運(yùn)行狀態(tài)，包括readonly，從庫IO,SQL線程，從庫所指主庫IP,port是否正確，主從延遲，連接數(shù)，空間情況等，來方便查看集群切換后的狀態(tài)，可快速定位問題
python mysql_check.py --options=check_all
前端報(bào)表如下：
<1>沒有切換，元信息等都沒有更改
<2>切換了，部分從庫實(shí)例切換失敗
情況：沒有切換，元信息沒有修改
原因：
masterha_check_repl 檢查失敗的原因有多種：
<1>無信任關(guān)系
<2>賬戶權(quán)限問題
<3>無可切為主庫設(shè)置問題等
解決：
1,2問題可以通過初始化mha環(huán)境來解決
python mhacluster.py --options=add_mha_single_cluster --cluster_ids=1,2,3
3問題：數(shù)據(jù)庫不可切，優(yōu)先切，是否寫入配置文件 配置錯(cuò)誤問題，改正確即可
情況：已經(jīng)切換了，部分從庫有問題
原因：原因比較復(fù)雜，例如網(wǎng)絡(luò)，本身change命令無法執(zhí)行（例如5.7的某些配置導(dǎo)致）等
處理：
<1>檢查實(shí)例狀態(tài)，確認(rèn)哪些實(shí)例有問題
查看報(bào)表：實(shí)例狀態(tài)即可確認(rèn)，例如：
<2>修復(fù)切換失敗的從庫
根據(jù)日志等情況進(jìn)行修復(fù)或者重做。
目前已經(jīng)成功在線上運(yùn)行4個(gè)月以上，已經(jīng)切換線上集群6個(gè)以上（線上測試環(huán)境切換30+），暫時(shí)沒有發(fā)現(xiàn)問題
真正切換耗時(shí)大約在秒級（多數(shù)在3-5s之間）
1、沒有方便的工具來快速切換集群主庫，發(fā)生主庫故障時(shí)：
需要DBA花費(fèi)5分鐘手動(dòng)修改從庫指向，2-3分鐘檢查集群狀態(tài)，3-5分鐘修改元信息，
實(shí)際停機(jī)操作時(shí)間3-5分鐘；等共需要10-20分鐘
（僅DBA操作）
2、沒有工具快速顯示某集群拓?fù)?/strong>情況
3、沒有工具快速檢查實(shí)例運(yùn)行情況
1、利用mhaswitch工具來快速切換主庫
<1>可以降低丟失數(shù)據(jù)的風(fēng)險(xiǎn)
<2>影響寫入時(shí)間少，秒級
切換前后共需要5分鐘左右（僅DBA操作），實(shí)際停機(jī)操作：3-30s左右（如果在線切換大致在3-5s，如果是停原主庫切換，則大于10s）
DBA效率提升 50%-75%左右，快的話總時(shí)間可控制在1分鐘內(nèi)
線上實(shí)際操做：輸入信息10s左右，切換影響寫入 3-5s 左右，更新與檢查等9s左右，共計(jì)22-24s左右
<3>mhacluster集成部署，幾個(gè)小時(shí)即可自動(dòng)部署全部mysql實(shí)例（目前近700個(gè)實(shí)例，近500臺機(jī)器，實(shí)際部署與檢查大約4-6個(gè)小時(shí)）
<4>無需DBA手動(dòng)修改主從，節(jié)約手動(dòng)操作時(shí)間約10-20分鐘
<5>無需DBA手動(dòng)修改元信息,節(jié)約修改元信息時(shí)間3-5分鐘左右
無需DBA手動(dòng)調(diào)整域名IP關(guān)系，節(jié)約調(diào)整域名IP時(shí)間1-3分鐘左右
<6>封裝MHA，方便DBA使用，無需繁瑣命令
<7>郵件程序，發(fā)送信息全，可快速查看切換結(jié)果與日志等
2、查詢集群拓?fù)涔ぞ遯mysql，1秒內(nèi)查看集群拓?fù)?
3、檢查集群狀態(tài)工具mysql_check，查詢近700個(gè)實(shí)例，近500臺機(jī)器僅需30s左右
4、django前端展示，MHA監(jiān)控，報(bào)表，方便監(jiān)控MHA情況與排錯(cuò)等
以上是“MHA調(diào)研與應(yīng)用的示例分析”這篇文章的所有內(nèi)容，感謝各位的閱讀！相信大家都有了一定的了解，希望分享的內(nèi)容對大家有所幫助，如果還想學(xué)習(xí)更多知識，歡迎關(guān)注創(chuàng)新互聯(lián)-成都網(wǎng)站建設(shè)公司行業(yè)資訊頻道！
重慶分公司
重慶分公司
