![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 つ目のスレーブが落ちてもマスタが落ちたら
切り替えたい場合に無視していいスレーブに指定](https://image.slidesharecdn.com/mha-130423085107-phpapp01/85/MHA-15-320.jpg)
MHAを検証して導入した話
- 1.
- 2. MHA とは MHAとは MySQL のマスタ障害時に最新のス レーブをマスタとして他のスレーブの差分を 補完しマスタの向き先を変えてくれるプロダ クト。 replication の復旧を自動的にしてくれ るもの。 VIP を移動するのは自己責任。 MHA for MySQL は Master High Availability Manager and tools for MySQL の略らしいです。 作者の日本語スライド http://www.slideshare.net/matsunobu/mha-for-mysqlden
- 3. 検証のきっかけ じつは MHAはきっと使いたいと要望が出 るに違いないと思って、産休直前に松信 さんの英語の .ppt を英語講習の先生とマ ンツーの時間に一緒に訳してた。 そして育休から復帰するのを待ってたか のようにお客様要望が複数きてるので検 証せよとご依頼が。 だってサービスレベルあがるもんね、そ うよね。
- 4. DB の負荷分散と冗長化の構成 Before LVS で分散してHertbeatV1+mon+mysql で冗長 化 LVS1LVS DB Master Hertbeat1 +mon DB Slave2 DB Slave1 Hertbeat1 VIP webwebwebwebwebweb write read repl read repl
- 5. DB の負荷分散と冗長化の構成 Before Failover すると、マスタ1 台になってしまう 。 LVS1LVS DB Master Hertbeat1 +mon DB Slave DB newMaster Hertbeat1 VIP webwebwebwebwebweb write read repl read repl × × × ×
- 6. DB の負荷分散と冗長化の構成 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
- 7. DB の負荷分散と冗長化の構成 After Failoverすると、 replicaiton も再構成され る LVS1 DB Master MHAnode Admin MHA manager DB newMaster MHAnode DB Slave MHAnode VIP webwebwebwebwebweb write read repl read LVS ※ 切り替えた後に 、 manager も落ちま す
- 8. そのたの構成（余談） HertbeatV3+DRBD+mysql → 1台無駄 ( 共有ディスクで排他制御 ) でスケールしないのがヤ ダって言われることがおおい RDS →値段が高いっていわれることがおおい、 DC 越しに chk してる せいか無駄に切り替わることが多い ( 規模にもよる ) 多段 replication →昔社内の某案件で大障害がおきたきっかけが多段 replication で あって、その復旧のために色々な人が寝る間もなかったことは 忘れ難い。 (GTID が有効な場合に中間ノード障害の復旧が難しいかはよ くわかりません！知ってたらおしえてほしいです）
- 9. 何が問題だったか、何が嬉しいのか 問題だったのは フェイルオーバすると、 VIPの移動だけで replication の整合性 までは保障できず、マスタのみのシングル構成になってしまい 負荷に耐えられないのと、 slave の復旧の際は再度マスタを止めて dump をとる必要があ り、 復旧のための計画停止が必要になってしまっていたこと。 サービス停止時間はデータ量に依存し dump 時間が異なる。 嬉しいことは、 MHA をつかうとフェイルオーバーしても 3 台以上 (slave ２台 以上 ) あれば replication まで再構成されてシングルになること を防げて負荷耐性が向上したこと。 また３台以上あれば slave 復旧のために dump でサービス停止 する必要がない
- 10. MHA 導入時の制限事項 mysql5.0以上、 SBR( ステートメントベー スレプリケーション ) の場合 LOAD DATA INFILE を使えない。 MySQL-5.6 の GTID と違って MyISAM つか えないとか Create..Select できないとかはな い。 GTID が有効な場合に動作するかは確かめ ていない。
- 11. 注意したほうがいいところ ( 監視 等）物理は大丈夫だけど仮想でコア数が少ない CPU パワーが 貧弱なサーバだと挙動がおかしかった mysqld をチェックする頻度の調整は可能だが、同じよう に mysqld を chk する lvs 等と同じサーバに相乗りをする と host が db から拒否されるので要注意。 デーモンではないためバックグラウンドで起動したのと 同じターミナルでログを tail でみると固まることがあっ た 仮想 IP に対する監視と manager に対するプロセス監視 は別途必要 slave が死んでも反応しないので、別途検知できる必要 がある 通常切り戻しはしない運用になると思われる ( マスタ切 替るなら念のためメンテ入れることになると思う ) ので どちらがマスタかややわかりづらいのでつど確認するの と、リレーログパージの cron の有効無効化を忘れないよ うに注意必要。
- 12. どういう動きをするのか動作フェーズ 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..
- 13. どういう動きをするのか動作フェーズ 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 を停止する
- 14. 入れ方とか使い方 日本語だとこの辺が一番わかりやすいかと。 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 を停止、再度起動、 ９．切り替えテスト、切り戻しをテスト項目に応じ繰り返す
- 15. 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 つ目のスレーブが落ちてもマスタが落ちたら 切り替えたい場合に無視していいスレーブに指定
- 16. master_ip_failover スクリプトが 要修正 めんどくさいからVIP は Heartbeat でいい じゃないと思ったらお客さんに拒否され てしまった 拾ってきたやつを修正しました （ https://gist.github.com/2310502 ）（ダサ くてすみま ry やりたいことは、更新用の VIP を旧マス タから新マスタに移すのと LVS の参照分 散の重みを変えること、旧マスタを落と すこと
- 17. 参照分散との連携の拡張 system コマンドでperl(master_ip_failover スクリプト ) からシェルを呼び出すように しました。（ダサくてすみま ry system("/usr/local/bin/mod_lvs_weight.sh"); 参照 VIP がついてるほうを確かめてついて るほうの重みを変える処理をします。 (force reload で強制的に設定変更します )
- 18. リレーログを定期的にパージする必 要がある (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 とかマウントしてるならハードリンク先 のディレクトリ指定する必要があります。
- 19. マスタを手動切替したい場合 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 スクリ プトと同じように修正する必要がある
- 20. manager 自体の冗長化について 特に必要ないかも (manager が死んでもサービスに影響しな いので同じのをほかのサーバにも入れと くレベルで OK) フェイルオーバ後は手動で復旧するのが 問題を大きくしなくていい気がします。 復旧手順は必要。
- 21. さいごに MHA 超便利なのでもっと普及すべき！ perl わからないけど何とかなりました ご覧頂きありがとうございました