MySQLレプリケーションは、高可用性データベースレイヤーを構築するための非常に一般的な方法です。それは非常によく知られており、テストされ、堅牢です。ただし、制限がないわけではありません。そのうちの1つは、間違いなく、1つの「エントリポイント」のみを使用するという事実です。トポロジ内に専用サーバーであるマスターがあり、クラスター内で書き込みを発行できる唯一のノードです。これは深刻な結果につながります。マスターは単一障害点であり、失敗した場合、アプリケーションは書き込みを実行できません。マスターロスの影響を減らすツールの開発に多くの作業が費やされたことは驚くことではありません。確かに、このトピックにアプローチする方法についての議論があります。自動フェイルオーバーは手動フェイルオーバーよりも優れているかどうかです。最終的には、これはビジネス上の決定ですが、自動化パスに従うことを決定した場合は、それを達成するのに役立つツールを探すことになります。まだ非常に人気のあるツールの1つは、MHA（マスター高可用性）です。おそらくそれはもはや積極的に維持されていませんが、それでも安定した形であり、その絶大な人気により、高可用性MySQLレプリケーションセットアップのバックボーンとなっています。しかし、MHA自体が利用できなくなったらどうなるでしょうか。単一障害点になる可能性はありますか？それを防ぐ方法はありますか？このブログ投稿では、いくつかのシナリオを見ていきます。
まず最初に、MHAを使用する場合は、リポジトリの最新バージョンを使用していることを確認してください。バイナリリリースにはすべての修正が含まれていないため、使用しないでください。インストールはかなり簡単です。 MHAは、マネージャーとノードの2つの部分で構成されます。ノードはデータベースサーバーにデプロイされます。 Managerは、ノードとともに別のホストにデプロイされます。つまり、データベースサーバー：ノード、管理ホスト：マネージャーとノード。
MHAのコンパイルは非常に簡単です。 GitHubに移動し、リポジトリのクローンを作成します。
https://github.com/yoshinorim/mha4mysql-manager
https://github.com/yoshinorim/mha4mysql-node
次に、それはすべてです：
perl Makefile.PL
make
make install必要なすべてのパッケージがまだインストールされていない場合は、いくつかのperl依存関係をインストールする必要があるかもしれません。私たちの場合、Ubuntu 16.04では、次のものをインストールする必要がありました：
perl -MCPAN -e "install Config::Tiny"
perl -MCPAN -e "install Log::Dispatch"
perl -MCPAN -e "install Parallel::ForkManager"
perl -MCPAN -e "install Module::Install"MHAをインストールしたら、それを構成する必要があります。ここでは詳細については説明しません。インターネット上には、この部分をカバーする多くのリソースがあります。サンプル構成（間違いなく非実稼働構成）は次のようになります：
[email protected]:~# cat /etc/app1.cnf
[server default]
user=cmon
password=pass
ssh_user=root
# working directory on the manager
manager_workdir=/var/log/masterha/app1
# working directory on MySQL servers
remote_workdir=/var/log/masterha/app1
[server1]
hostname=node1
candidate_master=1
[server2]
hostname=node2
candidate_master=1
[server3]
hostname=node3
no_master=1次のステップは、すべてが機能するかどうか、およびMHAがレプリケーションをどのように認識するかを確認することです。
[email protected]:~# masterha_check_repl --conf=/etc/app1.cnf
Tue Apr 9 08:17:04 2019 - [warning] Global configuration file /etc/masterha_default.cnf not found. Skipping.
Tue Apr 9 08:17:04 2019 - [info] Reading application default configuration from /etc/app1.cnf..
Tue Apr 9 08:17:04 2019 - [info] Reading server configuration from /etc/app1.cnf..
Tue Apr 9 08:17:04 2019 - [info] MHA::MasterMonitor version 0.58.
Tue Apr 9 08:17:05 2019 - [error][/usr/local/share/perl/5.22.1/MHA/MasterMonitor.pm, ln427] Error happened on checking configurations. Redundant argument in sprintf at /usr/local/share/perl/5.22.1/MHA/NodeUtil.pm line 195.
Tue Apr 9 08:17:05 2019 - [error][/usr/local/share/perl/5.22.1/MHA/MasterMonitor.pm, ln525] Error happened on monitoring servers.
Tue Apr 9 08:17:05 2019 - [info] Got exit code 1 (Not master dead).さて、それは墜落しました。これは、MHAがMySQLバージョンを解析しようとし、ハイフンを予期していないためです。幸い、修正は簡単に見つかります：https://github.com/yoshinorim/mha4mysql-manager/issues/116。
これで、MHAの準備が整いました。
[email protected]:~# masterha_manager --conf=/etc/app1.cnf
Tue Apr 9 13:00:00 2019 - [warning] Global configuration file /etc/masterha_default.cnf not found. Skipping.
Tue Apr 9 13:00:00 2019 - [info] Reading application default configuration from /etc/app1.cnf..
Tue Apr 9 13:00:00 2019 - [info] Reading server configuration from /etc/app1.cnf..
Tue Apr 9 13:00:00 2019 - [info] MHA::MasterMonitor version 0.58.
Tue Apr 9 13:00:01 2019 - [info] GTID failover mode = 1
Tue Apr 9 13:00:01 2019 - [info] Dead Servers:
Tue Apr 9 13:00:01 2019 - [info] Alive Servers:
Tue Apr 9 13:00:01 2019 - [info] node1(10.0.0.141:3306)
Tue Apr 9 13:00:01 2019 - [info] node2(10.0.0.142:3306)
Tue Apr 9 13:00:01 2019 - [info] node3(10.0.0.143:3306)
Tue Apr 9 13:00:01 2019 - [info] Alive Slaves:
Tue Apr 9 13:00:01 2019 - [info] node2(10.0.0.142:3306) Version=5.7.25-28-log (oldest major version between slaves) log-bin:enabled
Tue Apr 9 13:00:01 2019 - [info] GTID ON
Tue Apr 9 13:00:01 2019 - [info] Replicating from 10.0.0.141(10.0.0.141:3306)
Tue Apr 9 13:00:01 2019 - [info] Primary candidate for the new Master (candidate_master is set)
Tue Apr 9 13:00:01 2019 - [info] node3(10.0.0.143:3306) Version=5.7.25-28-log (oldest major version between slaves) log-bin:enabled
Tue Apr 9 13:00:01 2019 - [info] GTID ON
Tue Apr 9 13:00:01 2019 - [info] Replicating from 10.0.0.141(10.0.0.141:3306)
Tue Apr 9 13:00:01 2019 - [info] Not candidate for the new Master (no_master is set)
Tue Apr 9 13:00:01 2019 - [info] Current Alive Master: node1(10.0.0.141:3306)
Tue Apr 9 13:00:01 2019 - [info] Checking slave configurations..
Tue Apr 9 13:00:01 2019 - [info] Checking replication filtering settings..
Tue Apr 9 13:00:01 2019 - [info] binlog_do_db= , binlog_ignore_db=
Tue Apr 9 13:00:01 2019 - [info] Replication filtering check ok.
Tue Apr 9 13:00:01 2019 - [info] GTID (with auto-pos) is supported. Skipping all SSH and Node package checking.
Tue Apr 9 13:00:01 2019 - [info] Checking SSH publickey authentication settings on the current master..
Tue Apr 9 13:00:02 2019 - [info] HealthCheck: SSH to node1 is reachable.
Tue Apr 9 13:00:02 2019 - [info]
node1(10.0.0.141:3306) (current master)
+--node2(10.0.0.142:3306)
+--node3(10.0.0.143:3306)
Tue Apr 9 13:00:02 2019 - [warning] master_ip_failover_script is not defined.
Tue Apr 9 13:00:02 2019 - [warning] shutdown_script is not defined.
Tue Apr 9 13:00:02 2019 - [info] Set master ping interval 3 seconds.
Tue Apr 9 13:00:02 2019 - [warning] secondary_check_script is not defined. It is highly recommended setting it to check master reachability from two or more routes.
Tue Apr 9 13:00:02 2019 - [info] Starting ping health check on node1(10.0.0.141:3306)..
Tue Apr 9 13:00:02 2019 - [info] Ping(SELECT) succeeded, waiting until MySQL doesn't respond..ご覧のとおり、MHAはレプリケーショントポロジを監視し、マスターノードが使用可能かどうかを確認しています。いくつかのシナリオを考えてみましょう。
シナリオ1-MHAがクラッシュしました
MHAが利用できないと仮定しましょう。これは環境にどのように影響しますか？明らかに、MHAはマスターの状態を監視し、フェイルオーバーをトリガーする責任があるため、MHAがダウンしている場合はこれは発生しません。マスターのクラッシュは検出されず、フェイルオーバーは発生しません。問題は、実際には複数のMHAインスタンスを同時に実行できないことです。技術的には、MHAはロックファイルについて文句を言いますが、それは可能です：
[email protected]:~# masterha_manager --conf=/etc/app1.cnf
Tue Apr 9 13:05:38 2019 - [warning] Global configuration file /etc/masterha_default.cnf not found. Skipping.
Tue Apr 9 13:05:38 2019 - [info] Reading application default configuration from /etc/app1.cnf..
Tue Apr 9 13:05:38 2019 - [info] Reading server configuration from /etc/app1.cnf..
Tue Apr 9 13:05:38 2019 - [info] MHA::MasterMonitor version 0.58.
Tue Apr 9 13:05:38 2019 - [warning] /var/log/masterha/app1/app1.master_status.health already exists. You might have killed manager with SIGKILL(-9), may run two or more monitoring process for the same application, or use the same working directory. Check for details, and consider setting --workdir separately.ただし、起動し、環境の監視を試みます。問題は、両方がクラスターでアクションの実行を開始したときです。最悪の場合は、マスター候補として異なるスレーブを使用することを決定し、フェイルオーバーが同時に実行される場合です（MHAは、後続のフェイルオーバーが発生しないようにするロックファイルを使用しますが、すべてが同時に発生し、それがテストでは、このセキュリティ対策では不十分です。
残念ながら、可用性の高い方法でMHAを実行する組み込みの方法はありません。最も簡単な解決策は、MHAが実行されているかどうかをテストし、実行されていない場合は起動するスクリプトを作成することです。このようなスクリプトは、cronから実行するか、1分間のcronの粒度では不十分な場合は、デーモンの形式で作成する必要があります。
シナリオ2-MHAマネージャーノードがマスターへのネットワーク接続を失いました
正直に言うと、これは本当に悪い状況です。 MHAがマスターに接続できなくなるとすぐに、フェイルオーバーの実行を試みます。唯一の例外は、secondary_check_scriptが定義されていて、マスターが動作していることを確認した場合です。マスターのステータスを確認するためにMHAが実行する必要のあるアクションを正確に定義するのはユーザーの責任です。これはすべて、環境と正確なセットアップによって異なります。定義するもう1つの非常に重要なスクリプトは、master_ip_failover_scriptです。これはフェイルオーバー時に実行され、特に、古いマスターが表示されないようにするために使用する必要があります。古いマスターに到達して停止するための追加の方法にアクセスできる場合、それは本当に素晴らしいことです。 Integrated Lights-outのようなリモート管理ツール、管理可能な電源ソケット（サーバーの電源を切るだけ）、クラウドプロバイダーのCLIにアクセスできるため、仮想インスタンスを停止できます。 。古いマスターを停止することが最も重要です-そうしないと、ネットワークの問題がなくなった後、システムに2つの書き込み可能なノードができてしまう可能性があります。これは、スプリットブレインの完璧なソリューションです。同じクラスターの2つの部分の間でデータが分岐しました。
ご覧のとおり、MHAはMySQLフェイルオーバーを非常にうまく処理できます。それは間違いなく注意深い設定を必要とし、あなたは古いマスターを殺し、スプリットブレインが起こらないことを確実にするために利用される外部スクリプトを書かなければならないでしょう。そうは言っても、OrchestratorやClusterControlなどのより高度なフェイルオーバー管理ツールを使用することをお勧めします。これらのツールはレプリケーショントポロジの状態のより高度な分析を実行でき（たとえば、スレーブまたはプロキシを利用してマスターの可用性を評価することにより）、将来的に維持されます。 ClusterControlがフェイルオーバーを実行する方法について知りたい場合は、ClusterControlのフェイルオーバープロセスに関するこのブログ投稿をお読みください。また、ClusterControlがProxySQLと相互作用して、アプリケーションにスムーズで透過的なフェイルオーバーを提供する方法についても学ぶことができます。 ClusterControlは、無料でダウンロードすることでいつでもテストできます。