MySQL
MHA

MySQL MHAの仕組みについて解説してみる

More than 1 year has passed since last update.

このポストでは、思いつく限りMHAの解説記事として書いてみようと思います。

MHAについて

Master High Availability Managerの略でMHAです。MySQL High Availabilityだと最初思った人は私だけではないはず。わざわざ説明もいらないかと思いますが、松信嘉範さんがDeNA時代に作ったといったものになるかと思います。

公式資料は以下です。
https://github.com/yoshinorim/mha4mysql-manager/wiki
https://www.slideshare.net/matsunobu/mha-for-mysqldena

MHAが広く使用されている理由は、Slaveが多くぶら下がっている環境においてbinlogのポジションがバラバラになっていると仮定した状況でも、可能な限りMasterのbinlogを回収し、slaveに送ってくれて、さらに最新マスターとその他のslaveとのポジションを整えてくれることがまず1つの理由かと思います。

MHAがなかったときつらい

仮定の話としてですが、MHAがない場合でMasterに障害が発生し多数のSlaveからMasterを昇格させなければならない場合を考えます。

この時、まずDBAは最新のデータを持つMasterを選出しなければなりません。GTIDが未導入な環境であれば、バイナリログのポジションを確認していったりなどの方法で一つ一つのMySQLを見て回らなければなりません。

加えて、最新のデータを持つSlaveが確定したあとは、Slaveのポジションを整える必要があります。「ハイパフォーマンスMySQL」のp518の「ログの位置を特定する」という節にある通り、昇格したMasterに対して各Slaveのポジションが遅れている場合には、バイナリログのポジション差を計算して、そこからレプリケーションを開始するなどの非常に手間もかかるし、ミスのリスクがある作業となってしまいます。それか最新のMasterのデータで全てリストアしていくとか。つらいです。

MHAの基本となる構築知識

そんなMHAですが、基本となるアーキテクチャはmanagerノードとmhaノードです。
SSH接続可能にしてあげて動作できるようになります。

セットアップが簡単にできるようになっているのもすごくいいところです。
基本的には上記のgithubのwikiのinstallation通りやれば問題ないでしょう。

managerとmhaの各ノードが設定できたら、
managerのbinにあるmasterha_ssh_checkでSSH接続の設定をまず確認してあげましょう。
その後、masterha_check_replでMaster/Slaveのレプリケーションが正常であることを確認して、masterha_managerで監視を開始したり、masterha_master_switchでフェイルオーバーさせたりしてみるというステップが間違いがないかと思います。

MHAの内部動作についての見方

githubにて公開されているツールですのでPerlが読める方はそれでも良いですが、私は基本的にはgeneral logをONにして内部動作を見たりしながら要件に対して見落としがないかみたりしました。またPerlのコードにデバックにprintを突っ込んで見たり。

MHAのマニュアルは・・・

日本人エンジニアが作ったものですが上述のwikiは英語です。なので日本語でググっていると断片的な情報がたくさんヒットしますが、wiki自体の文量もそこまで多くはないので、英語が苦手な方でもwikiを読むことを強く薦めます。なぜなら、当たり前ですが開発者が書いたマニュアルですので間違いがありませんし、なぜMHAを作ったかとかの背景もしっかり知れるので。

VIPのフェイルオーバーのサンプルスクリプトとかもあるんだよ

MHAを使ったことがある人は常識ですが、MHAにはサンプルスクリプトがいくつか提供されておりMaster障害時のVIPのフェイルオーバーのスクリプトもすぐに実装できます。

ps:流し書きで書いていきましたが説明って難しいですね。。。(てかめんどい) けどアウトプットの練習兼ねて頑張って書いているのでそこは見逃してください。。。