~育休開け検証第一弾~
MHA とは MHA とは MySQL のマスタ障害時に最新のスレーブをマスタとして他のスレーブの差分を補完しマスタの向き先を変えてくれるプロダクト。 replication の復旧を自動的にしてくれるもの。 VIP を移動するのは自己責任...
検証のきっかけ じつは MHA はきっと使いたいと要望が出るに違いないと思って、産休直前に松信さんの英語の .ppt を英語講習の先生とマンツーの時間に一緒に訳してた。 そして育休から復帰するのを待ってたかのようにお客様要望が複数きてるので...
DB の負荷分散と冗長化の構成BeforeLVS で分散して HertbeatV1+mon+mysql で冗長化LVS1LVSDBMasterHertbeat1+monDBSlave2DBSlave1Hertbeat1VIPwebwebwebw...
DB の負荷分散と冗長化の構成BeforeFailover すると、マスタ 1 台になってしまう。LVS1LVSDBMasterHertbeat1+monDBSlaveDBnewMasterHertbeat1VIPwebwebwebwebweb...
DB の負荷分散と冗長化の構成AfterLVS で分散して MHA+mysql で冗長化※manager は Admin サーバと相乗りLVS1DBMasterMHAnodeAdminMHAmanagerDBSlaveMHAnodeDBSlav...
DB の負荷分散と冗長化の構成After Failover すると、 replicaiton も再構成されるLVS1DBMasterMHAnodeAdminMHAmanagerDBnewMasterMHAnodeDBSlaveMHAnodeV...
そのたの構成(余談) HertbeatV3+DRBD+mysql → 1 台無駄 ( 共有ディスクで排他制御 ) でスケールしないのがヤダって言われることがおおい RDS →値段が高いっていわれることがおおい、 DC 越しに chk してる...
何が問題だったか、何が嬉しいのか問題だったのは フェイルオーバすると、 VIP の移動だけで replication の整合性までは保障できず、マスタのみのシングル構成になってしまい負荷に耐えられないのと、 slave の復旧の際は再度マス...
MHA 導入時の制限事項 mysql5.0 以上、 SBR( ステートメントベースレプリケーション ) の場合 LOAD DATAINFILE を使えない。 MySQL-5.6 の GTID と違って MyISAM つかえないとか Crea...
注意したほうがいいところ ( 監視等) 物理は大丈夫だけど仮想でコア数が少ない CPU パワーが貧弱なサーバだと挙動がおかしかった mysqld をチェックする頻度の調整は可能だが、同じように mysqld を chk する lvs 等と同...
どういう動きをするのか動作フェーズ1 ログをみるとかいてあるよ ( 作者のスライドの P.8 に図があります )# grep Phase manager.log |head -20|grep -v completed* Phase 1: Co...
どういう動きをするのか動作フェーズ2 フェイルオーバ時の動作は以下のとおり。(ログから追った動き) ※ SQL 処理のスレッド実行が終わった後①config(/etc/app1.cnf) から各ノード情報を読み込む②newMaster の V...
入れ方とか使い方 日本語だとこの辺が一番わかりやすいかと。http://tech-sketch.jp/2012/12/mysql-mha.html英語ですが公式サイトにもチュートリアルがあります。https://code.google.com...
manager の設定ファイル  # vi /etc/app1.cnf---------------------------------[server default]# mysql user and passworduser=rootpass...
master_ip_failover スクリプトが要修正 めんどくさいから VIP は Heartbeat でいいじゃないと思ったらお客さんに拒否されてしまった 拾ってきたやつを修正しました( https://gist.github.com...
参照分散との連携の拡張 system コマンドで perl(master_ip_failoverスクリプト ) からシェルを呼び出すようにしました。(ダサくてすみま rysystem("/usr/local/bin/mod_lvs_weigh...
リレーログを定期的にパージする必要がある (cron 登録 ) slave ごとに時差があったほうが復旧できるデータが残ってる確立が上がります。   mysql> set global relay_log_purge=0;   # cront...
マスタを手動切替したい場合 MHA マネージャが落ちていてマスタ ( と更新用 VIP) を手動切替したい場合# masterha_master_switch --master_state=alive--conf=/etc/app1.cnf※...
manager 自体の冗長化について 特に必要ないかも  (manager が死んでもサービスに影響しないので同じのをほかのサーバにも入れとくレベルで OK) フェイルオーバ後は手動で復旧するのが問題を大きくしなくていい気がします。 復旧手順...
さいごに MHA 超便利なのでもっと普及すべき! perl わからないけど何とかなりました ご覧頂きありがとうございました
Upcoming SlideShare
Loading in...5
×

MHAを検証して導入した話

6,398

Published on

詳しくはこちら。
http://devlab.isao.co.jp/mha_install/

1 Comment
19 Likes
Statistics
Notes
  • https://twitter.com/matsunobu/statuses/335249816760246273
    開発者様がこのようにおっしゃってるようです「5.6のbinlog checksumをサポートしたものはGitHubに上げています。あとまだ上げていませんがGTIDもサポートします。と言うことで5.6でも使えるようになるでしょう。 」
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
No Downloads
Views
Total Views
6,398
On Slideshare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
1
Comments
1
Likes
19
Embeds 0
No embeds

No notes for slide

Transcript of "MHAを検証して導入した話"

  1. 1. ~育休開け検証第一弾~
  2. 2. MHA とは MHA とは MySQL のマスタ障害時に最新のスレーブをマスタとして他のスレーブの差分を補完しマスタの向き先を変えてくれるプロダクト。 replication の復旧を自動的にしてくれるもの。 VIP を移動するのは自己責任。 MHA for MySQL は Master High AvailabilityManager and tools for MySQL の略らしいです。 作者の日本語スライドhttp://www.slideshare.net/matsunobu/mha-for-mysqlden
  3. 3. 検証のきっかけ じつは MHA はきっと使いたいと要望が出るに違いないと思って、産休直前に松信さんの英語の .ppt を英語講習の先生とマンツーの時間に一緒に訳してた。 そして育休から復帰するのを待ってたかのようにお客様要望が複数きてるので検証せよとご依頼が。 だってサービスレベルあがるもんね、そうよね。
  4. 4. DB の負荷分散と冗長化の構成BeforeLVS で分散して HertbeatV1+mon+mysql で冗長化LVS1LVSDBMasterHertbeat1+monDBSlave2DBSlave1Hertbeat1VIPwebwebwebwebwebwebwritereadreplreadrepl
  5. 5. DB の負荷分散と冗長化の構成BeforeFailover すると、マスタ 1 台になってしまう。LVS1LVSDBMasterHertbeat1+monDBSlaveDBnewMasterHertbeat1VIPwebwebwebwebwebwebwritereadreplreadrepl××××
  6. 6. DB の負荷分散と冗長化の構成AfterLVS で分散して MHA+mysql で冗長化※manager は Admin サーバと相乗りLVS1DBMasterMHAnodeAdminMHAmanagerDBSlaveMHAnodeDBSlaveMHAnodeVIPwebwebwebwebwebwebwritereadreplreplreadLVSchk
  7. 7. DB の負荷分散と冗長化の構成After Failover すると、 replicaiton も再構成されるLVS1DBMasterMHAnodeAdminMHAmanagerDBnewMasterMHAnodeDBSlaveMHAnodeVIPwebwebwebwebwebwebwritereadreplreadLVS※ 切り替えた後に、manager も落ちます
  8. 8. そのたの構成(余談) HertbeatV3+DRBD+mysql → 1 台無駄 ( 共有ディスクで排他制御 ) でスケールしないのがヤダって言われることがおおい RDS →値段が高いっていわれることがおおい、 DC 越しに chk してるせいか無駄に切り替わることが多い ( 規模にもよる ) 多段 replication →昔社内の某案件で大障害がおきたきっかけが多段 replication であって、その復旧のために色々な人が寝る間もなかったことは忘れ難い。   (GTID が有効な場合に中間ノード障害の復旧が難しいかはよくわかりません!知ってたらおしえてほしいです)
  9. 9. 何が問題だったか、何が嬉しいのか問題だったのは フェイルオーバすると、 VIP の移動だけで replication の整合性までは保障できず、マスタのみのシングル構成になってしまい負荷に耐えられないのと、 slave の復旧の際は再度マスタを止めて dump をとる必要があり、  復旧のための計画停止が必要になってしまっていたこと。サービス停止時間はデータ量に依存し dump 時間が異なる。嬉しいことは、 MHA をつかうとフェイルオーバーしても 3 台以上 (slave 2台以上 ) あれば replication まで再構成されてシングルになることを防げて負荷耐性が向上したこと。 また3台以上あれば slave 復旧のために dump でサービス停止する必要がない
  10. 10. MHA 導入時の制限事項 mysql5.0 以上、 SBR( ステートメントベースレプリケーション ) の場合 LOAD DATAINFILE を使えない。 MySQL-5.6 の GTID と違って MyISAM つかえないとか Create..Select できないとかはない。  GTID が有効な場合に動作するかは確かめていない。
  11. 11. 注意したほうがいいところ ( 監視等) 物理は大丈夫だけど仮想でコア数が少ない CPU パワーが貧弱なサーバだと挙動がおかしかった mysqld をチェックする頻度の調整は可能だが、同じように mysqld を chk する lvs 等と同じサーバに相乗りをすると host が db から拒否されるので要注意。 デーモンではないためバックグラウンドで起動したのと同じターミナルでログを tail でみると固まることがあった 仮想 IP に対する監視と manager に対するプロセス監視は別途必要 slave が死んでも反応しないので、別途検知できる必要がある 通常切り戻しはしない運用になると思われる ( マスタ切替るなら念のためメンテ入れることになると思う ) のでどちらがマスタかややわかりづらいのでつど確認するのと、リレーログパージの cron の有効無効化を忘れないように注意必要。
  12. 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 Masters 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. 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. 14. 入れ方とか使い方 日本語だとこの辺が一番わかりやすいかと。http://tech-sketch.jp/2012/12/mysql-mha.html英語ですが公式サイトにもチュートリアルがあります。https://code.google.com/p/mysql-master-ha/wiki/Tutorial1.通常通りレプリケーションを組み、2.ノードとマネージャにそれぞれ必要なパッケージを入れ、3.設定ファイルとスクリプトを設置し、4. ssh のカギ認証を設定し、付属コマンドで ssh 接続を Chk 、5.付属コマンドでレプリケーション chk 、6. Manager を起動、7. Manager のステータスを確認、8. Manager を停止、再度起動、9.切り替えテスト、切り戻しをテスト項目に応じ繰り返す
  15. 15. manager の設定ファイル  # vi /etc/app1.cnf---------------------------------[server default]# mysql user and passworduser=rootpassword=ssh_user=root# working directory on the managermanager_workdir=/var/log/masterha/app1manager_log=/var/log/masterha/app1/manager.log# working directory on MySQL serversremote_workdir=/var/log/masterha/app1# master binlog dirmaster_binlog_dir=/usr/local/mysql/varmaster_ip_failover_script=/usr/local/bin/master_ip_failoverping_interval=3[server1]hostname=192.168.100.1port=3306[server2]hostname=192.168.100.2port=3306candidate_master=1[server3]hostname=192.168.100.3port=3306no_master=1----------------------------------メイン設定パラメータ詳細は以下参照のことhttp://code.google.com/p/mysql-master-ha/wiki/Parameters※ 他にあったほうがいいかもしれないパラメータsecondary_check_script  2 つ目のインターフェースからもチェックしてくれるスクリプトとホストを指定ignore_fail  2 つ目のスレーブが落ちてもマスタが落ちたら切り替えたい場合に無視していいスレーブに指定
  16. 16. master_ip_failover スクリプトが要修正 めんどくさいから VIP は Heartbeat でいいじゃないと思ったらお客さんに拒否されてしまった 拾ってきたやつを修正しました( https://gist.github.com/2310502 )(ダサくてすみま ry やりたいことは、更新用の VIP を旧マスタから新マスタに移すのと LVS の参照分散の重みを変えること、旧マスタを落とすこと
  17. 17. 参照分散との連携の拡張 system コマンドで perl(master_ip_failoverスクリプト ) からシェルを呼び出すようにしました。(ダサくてすみま rysystem("/usr/local/bin/mod_lvs_weight.sh");参照 VIP がついてるほうを確かめてついてるほうの重みを変える処理をします。  (force reload で強制的に設定変更します )
  18. 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. 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. 20. manager 自体の冗長化について 特に必要ないかも  (manager が死んでもサービスに影響しないので同じのをほかのサーバにも入れとくレベルで OK) フェイルオーバ後は手動で復旧するのが問題を大きくしなくていい気がします。 復旧手順は必要。
  21. 21. さいごに MHA 超便利なのでもっと普及すべき! perl わからないけど何とかなりました ご覧頂きありがとうございました

×