MHA を検証する、という話で最初に「どうしよう」と思ったのは MHA Manager をどこに置き、どう信頼性を確保するか、という点だった。 MHA Manager 自身は、MySQL のサービスには一切介在しないので、MHA Manager が例え落ちていたところでサービス影響はない。しかし、それはサービス影響がないというだけの話であって、Manager が担当している MySQL マスタが故障したまさにそのときに MHA Manager が死んでいたのでは元も子もない。 べき論で言うと、おそらくは MHA Manager は冗長化すべきであって、あとはそのべき論と「MHA Manager」が落ちるというレアなイベントに対するリスクに、どこまで工数を投資できるかという話になる。
MHA の公式ページの FAQ には、この問題について既に言及されていて、
Google Code Archive - Long-term storage for Google Code Project Hosting.> How to make MHA Manager node itself Highly Available ?
Currently monitoring the same master from multiple MHA Manager is NOT supported. So if the MHA Manager goes down, automated master failover can not be started. MHA Manager down does not result in master down, so it's much less serious, but you may want to make MHA Manager highly available as long as possible. Current recommended MHA Manager HA solution is using common active/standby solutions like Pacemaker.
(抄訳) どうやって MHA Manager 自身の信頼性をあげるんですか
複数の MHA Manager から一つの MySQL マスタを同時並行して監視するのはサポートされていません。このため、MHA Manager がダウンした場合、自動的なマスタフェイルオーバは開始されないことになります。MHA Manager のダウンそのものは MySQL マスタのダウンを意味しないので、深刻な問題ではありません。ただ、可能な限り MHA Manager を冗長化したいと思うこともあるでしょう。現時点での推奨は、Pacemaker のような一般的な active /standby のソリューションを使用することでしょう << Active/Active で MHA Manager を使用することはできず、Active/Standby で置いておけ、ということになる。 そこまでするのが大変、という場合は、Daemontools あるいは supervisord あたりで、プロセスレベルのダウンに対する対策だけはしておこうという発想で良さそう。 -ref: Google Code Archive - Long-term storage for Google Code Project Hosting.
さらに、どこに MHA Manager 置こうか問題としては、UseCases としても言及がある。 当然ながら + MHA Manager の専用ノードを用意する + どっかのサーバに MHA Manager を載せる という選択肢があるわけだけれど、
Google Code Archive - Long-term storage for Google Code Project Hosting.> Where to deploy Manager
Dedicated Manager server and multiple MySQL (master,slaves) servers
Since MHA Manager uses very little CPU/Memory resources, you can manage lots of (master, slaves) pairs from single MHA Manager. It is even possible to manage 100+ pairs from single manager server.
Running MHA Manager on one of MySQL slaves
If you have only one (master, slaves) pair, you may not like allocating dedicated hardware for MHA Manager because it adds relatively high costs. In such cases, running MHA Manager on one of slaves makes sense. Note that current version of MHA Manager connects to MySQL slave server via SSH even though the MySQL server is located on the same host as MHA Manager, so you need to enable SSH public key authentication from the same host.
(抄訳) ■MySQL スレーブサーバの一つで MHA Manager を動かす
もし (master, slave) のペア 1 つだけを動かす場合、わりと高くなるから、MHA Manager 専用のハードウェアを用意しなくて良い。そういう場合は、MHA Manager を slave サーバの 1 つで動かすっていうのは妥当な選択になる。(後略) << そもそもとして、MHA Manager はパフォーマンスを必要としないため、どっかのサーバ上で動かしておけば良いだろうという結論とした。
