MHAを検証して導入した話

～育休開け検証第一弾～

MHA とは
 MHA とは MySQL のマスタ障害時に最新のス
レーブをマスタとして他のスレーブの差分を
補完しマスタの向き先を変えてくれるプロダ
クト。 replication の復旧を自動的にしてくれ
るもの。
 VIP を移動するのは自己責任。
 MHA for MySQL は Master High Availability
Manager and tools for MySQL の略らしいです。
 作者の日本語スライド
http://www.slideshare.net/matsunobu/mha-for-mysqlden

検証のきっかけ
 じつは MHA はきっと使いたいと要望が出
るに違いないと思って、産休直前に松信
さんの英語の .ppt を英語講習の先生とマ
ンツーの時間に一緒に訳してた。
 そして育休から復帰するのを待ってたか
のようにお客様要望が複数きてるので検
証せよとご依頼が。
 だってサービスレベルあがるもんね、そ
うよね。

DB の負荷分散と冗長化の構成
Before
LVS で分散して HertbeatV1+mon+mysql で冗長
化
LVS1LVS
DB
Master
Hertbeat1
+mon
DB
Slave2
DB
Slave1
Hertbeat1
VIP
webwebwebwebwebweb
write
read
repl
read
repl

Before
Failover すると、マスタ 1 台になってしまう
。
LVS1LVS
DB
Master
Hertbeat1
+mon
DB
Slave
DB
newMaster
Hertbeat1
VIP
webwebwebwebwebweb
write
read
repl
read
repl
×
×
×
×

After
LVS で分散して MHA+mysql で冗長化
※manager は Admin サーバと相乗り
LVS1
DB
Master
MHAnode
Admin
MHA
manager
DB
Slave
MHAnode
DB
Slave
MHAnode
VIP
webwebwebwebwebweb
write
read
repl
repl
read
LVS
chk

After
 Failover すると、 replicaiton も再構成され
る
LVS1
DB
Master
MHAnode
Admin
MHA
manager
DB
newMaster
MHAnode
DB
Slave
MHAnode
VIP
webwebwebwebwebweb
write
read
repl
read
LVS
※ 切り替えた後に
、
manager も落ちま
す

そのたの構成（余談）
 HertbeatV3+DRBD+mysql
　→ 1 台無駄 ( 共有ディスクで排他制御 ) でスケールしないのがヤ
ダって言われることがおおい
 RDS
　→値段が高いっていわれることがおおい、 DC 越しに chk してる
せいか無駄に切り替わることが多い ( 規模にもよる )
 多段 replication
　→昔社内の某案件で大障害がおきたきっかけが多段 replication で
あって、その復旧のために色々な人が寝る間もなかったことは
忘れ難い。
　　 (GTID が有効な場合に中間ノード障害の復旧が難しいかはよ
くわかりません！知ってたらおしえてほしいです）

何が問題だったか、何が嬉しいのか
問題だったのは
 フェイルオーバすると、 VIP の移動だけで replication の整合性
までは保障できず、マスタのみのシングル構成になってしまい
負荷に耐えられないのと、
 slave の復旧の際は再度マスタを止めて dump をとる必要があ
り、
　　復旧のための計画停止が必要になってしまっていたこと。
サービス停止時間はデータ量に依存し dump 時間が異なる。
嬉しいことは、
 MHA をつかうとフェイルオーバーしても 3 台以上 (slave ２台
以上 ) あれば replication まで再構成されてシングルになること
を防げて負荷耐性が向上したこと。
 また３台以上あれば slave 復旧のために dump でサービス停止
する必要がない

MHA 導入時の制限事項
 mysql5.0 以上、 SBR( ステートメントベー
スレプリケーション ) の場合 LOAD DATA
INFILE を使えない。
 MySQL-5.6 の GTID と違って MyISAM つか
えないとか Create..Select できないとかはな
い。
　 GTID が有効な場合に動作するかは確かめ
ていない。

注意したほうがいいところ ( 監視
等） 物理は大丈夫だけど仮想でコア数が少ない CPU パワーが
貧弱なサーバだと挙動がおかしかった
 mysqld をチェックする頻度の調整は可能だが、同じよう
に mysqld を chk する lvs 等と同じサーバに相乗りをする
と host が db から拒否されるので要注意。
 デーモンではないためバックグラウンドで起動したのと
同じターミナルでログを tail でみると固まることがあっ
た
 仮想 IP に対する監視と manager に対するプロセス監視
は別途必要
 slave が死んでも反応しないので、別途検知できる必要
がある
 通常切り戻しはしない運用になると思われる ( マスタ切
替るなら念のためメンテ入れることになると思う ) ので
どちらがマスタかややわかりづらいのでつど確認するの
と、リレーログパージの cron の有効無効化を忘れないよ
うに注意必要。

どういう動きをするのか動作フェーズ
1 ログをみるとかいてあるよ ( 作者のスライドの P.8 に図があります )
# grep Phase manager.log |head -20|grep -v completed
* Phase 1: Configuration Check Phase..
* Phase 2: Dead Master Shutdown Phase..
* Phase 3: Master Recovery Phase..
* Phase 3.1: Getting Latest Slaves Phase..
* Phase 3.2: Saving Dead Master's Binlog Phase..
* Phase 3.3: Determining New Master Phase..
* Phase 3.3: New Master Diff Log Generation Phase..
* Phase 3.4: Master Log Apply Phase..
* Phase 4: Slaves Recovery Phase..
* Phase 4.1: Starting Parallel Slave Diff Log Generation Phase..
* Phase 4.2: Starting Parallel Slave Log Apply Phase..
* Phase 5: New master cleanup phease..

どういう動きをするのか動作フェーズ
2 フェイルオーバ時の動作は以下のとおり。（ログから追った動き）
　※ SQL 処理のスレッド実行が終わった後
①config(/etc/app1.cnf) から各ノード情報を読み込む
②newMaster の VIP を停止する
③newMaste の mysqld を停止
④ 各 Slave リレーログを解析して次マスターの選出と差分位置を特定
⑤oldMaster にアクセス可能であればバイナリーログをローカルに
(/var/log/masterha/app1) コピーする
⑥⑤ で引き上げた最新のバイナリーログを newMaster(/var/log/masterha/app1) にコ
ピー
⑦oldMaster との差分を newMaster で更新
⑧neMaster に VIP を付与する
⑨newMaster の read-only を解除
⑩⑤ で引き上げた最新のバイナリーログを newSlave(/var/log/masterha/app1) にコピー
⑪oldMaster サーバとの差分を newSlave で更新
⑫newSlave で最新のバイナリーログと relay ログとの差分を確認して適用
⑬newSlave の Master を oldMaster サーバから newMaster サーバに変更し replication 再
開
⑭manager にて app1.failover.complete を /var/log/masterha/app1 に出力して
masterha_manager を停止する

入れ方とか使い方
 日本語だとこの辺が一番わかりやすいかと。
http://tech-sketch.jp/2012/12/mysql-mha.html
英語ですが公式サイトにもチュートリアルがあります。
https://code.google.com/p/mysql-master-ha/wiki/Tutorial
１．通常通りレプリケーションを組み、
２．ノードとマネージャにそれぞれ必要なパッケージを入れ、
３．設定ファイルとスクリプトを設置し、
４． ssh のカギ認証を設定し、付属コマンドで ssh 接続を Chk 、
５．付属コマンドでレプリケーション chk 、
６． Manager を起動、
７． Manager のステータスを確認、
８． Manager を停止、再度起動、
９．切り替えテスト、切り戻しをテスト項目に応じ繰り返す

manager の設定ファイル
　 # vi /etc/app1.cnf
---------------------------------
[server default]
# mysql user and password
user=root
password=
ssh_user=root
# working directory on the manager
manager_workdir=/var/log/masterha/app1
manager_log=/var/log/masterha/app1/manager.log
# working directory on MySQL servers
remote_workdir=/var/log/masterha/app1
# master binlog dir
master_binlog_dir=/usr/local/mysql/var
master_ip_failover_script=/usr/local/bin/master_ip_failover
ping_interval=3
[server1]
hostname=192.168.100.1
port=3306
[server2]
hostname=192.168.100.2
port=3306
candidate_master=1
[server3]
hostname=192.168.100.3
port=3306
no_master=1
----------------------------------
メイン設定パラメータ詳細は以下参照のこと
http://code.google.com/p/mysql-master-ha/wiki/Parameters
※ 他にあったほうがいいかもしれないパラメータ
secondary_check_script
　 2 つ目のインターフェースからも
チェックしてくれるスクリプトとホストを指定
ignore_fail
　 2 つ目のスレーブが落ちてもマスタが落ちたら
切り替えたい場合に無視していいスレーブに指定

master_ip_failover スクリプトが
要修正
 めんどくさいから VIP は Heartbeat でいい
じゃないと思ったらお客さんに拒否され
てしまった
 拾ってきたやつを修正しました
（ https://gist.github.com/2310502 ）（ダサ
くてすみま ry
 やりたいことは、更新用の VIP を旧マス
タから新マスタに移すのと LVS の参照分
散の重みを変えること、旧マスタを落と
すこと

参照分散との連携の拡張
 system コマンドで perl(master_ip_failover
スクリプト ) からシェルを呼び出すように
しました。（ダサくてすみま ry
system("/usr/local/bin/mod_lvs_weight.sh");
参照 VIP がついてるほうを確かめてついて
るほうの重みを変える処理をします。
　 (force reload で強制的に設定変更します )

リレーログを定期的にパージする必
要がある (cron 登録 )
 slave ごとに時差があったほうが復旧できるデータが残って
る確立が上がります。
　　 mysql> set global relay_log_purge=0;
　　 # crontab -e
----------slave1----------
30 2,4,6,10,14,16 * * * /usr/bin/perl /usr/bin/purge_relay_logs
--user=root --password=`cat /root/.mysql_pwd`
--disable_relay_log_purge >>
/var/log/masterha/purge_relay_logs.log 2>&1
----------slave2----------
30 3,5,9,11,15,17 * * * /usr/bin/perl /usr/bin/purge_relay_logs
--user=root --password=`cat /root/.mysql_pwd`
--disable_relay_log_purge >>
/var/log/masterha/purge_relay_logs.log 2>&1
--------------------------
　※ ioDrive とか SSD とかマウントしてるならハードリンク先
のディレクトリ指定する必要があります。

マスタを手動切替したい場合
 MHA マネージャが落ちていてマスタ ( と更新用 VIP) を
手動切替したい場合
# masterha_master_switch --master_state=alive
--conf=/etc/app1.cnf
※ ほんとにやっていいか聞かれるので承諾する。 MHA
マネージャが起動してると落とせと怒られる。
　 ( VIP※ は処理を追加しないと切り替わらない )
http://code.google.com/p/mysql-master-
ha/wiki/masterha_master_switch
　もし VIP も切替えたい場合は master_ip_failover スクリ
プトと同じように修正する必要がある

manager 自体の冗長化について
 特に必要ないかも
　 (manager が死んでもサービスに影響しな
いので同じのをほかのサーバにも入れと
くレベルで OK)
　フェイルオーバ後は手動で復旧するのが
問題を大きくしなくていい気がします。
　復旧手順は必要。

さいごに
 MHA 超便利なのでもっと普及すべき！
 perl わからないけど何とかなりました
 ご覧頂きありがとうございました

MHAを検証して導入した話

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à MHAを検証して導入した話

Similaire à MHAを検証して導入した話 (20)

Plus de Yu Komiya

Plus de Yu Komiya (8)

MHAを検証して導入した話