SlideShare a Scribd company logo
~育休開け検証第一弾~
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
DB の負荷分散と冗長化の構成
Before
Failover すると、マスタ 1 台になってしまう
。
LVS1LVS
DB
Master
Hertbeat1
+mon
DB
Slave
DB
newMaster
Hertbeat1
VIP
webwebwebwebwebweb
write
read
repl
read
repl
×
×
×
×
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
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 も落ちま
す
そのたの構成(余談)
 HertbeatV3+DRBD+mysql
 → 1 台無駄 ( 共有ディスクで排他制御 ) でスケールしないのがヤ
ダって言われることがおおい
 RDS
 →値段が高いっていわれることがおおい、 DC 越しに chk してる
せいか無駄に切り替わることが多い ( 規模にもよる )
 多段 replication
 →昔社内の某案件で大障害がおきたきっかけが多段 replication で
あって、その復旧のために色々な人が寝る間もなかったことは
忘れ難い。
   (GTID が有効な場合に中間ノード障害の復旧が難しいかはよ
くわかりません!知ってたらおしえてほしいです)
何が問題だったか、何が嬉しいのか
問題だったのは
 フェイルオーバすると、 VIP の移動だけで replication の整合性
までは保障できず、マスタのみのシングル構成になってしまい
負荷に耐えられないのと、
 slave の復旧の際は再度マスタを止めて dump をとる必要があ
り、
  復旧のための計画停止が必要になってしまっていたこと。
サービス停止時間はデータ量に依存し dump 時間が異なる。
嬉しいことは、
 MHA をつかうとフェイルオーバーしても 3 台以上 (slave 2台
以上 ) あれば replication まで再構成されてシングルになること
を防げて負荷耐性が向上したこと。
 また3台以上あれば 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
1.通常通りレプリケーションを組み、
2.ノードとマネージャにそれぞれ必要なパッケージを入れ、
3.設定ファイルとスクリプトを設置し、
4. ssh のカギ認証を設定し、付属コマンドで ssh 接続を Chk 、
5.付属コマンドでレプリケーション chk 、
6. Manager を起動、
7. Manager のステータスを確認、
8. Manager を停止、再度起動、
9.切り替えテスト、切り戻しをテスト項目に応じ繰り返す
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 わからないけど何とかなりました
 ご覧頂きありがとうございました

More Related Content

MHAを検証して導入した話

  • 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 2台 以上 ) あれば replication まで再構成されてシングルになること を防げて負荷耐性が向上したこと。  また3台以上あれば 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 1.通常通りレプリケーションを組み、 2.ノードとマネージャにそれぞれ必要なパッケージを入れ、 3.設定ファイルとスクリプトを設置し、 4. ssh のカギ認証を設定し、付属コマンドで ssh 接続を Chk 、 5.付属コマンドでレプリケーション chk 、 6. Manager を起動、 7. Manager のステータスを確認、 8. Manager を停止、再度起動、 9.切り替えテスト、切り戻しをテスト項目に応じ繰り返す
  • 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 わからないけど何とかなりました  ご覧頂きありがとうございました