MHAに関する主な一般的な問題とその修正方法

以前のブログでは、MySQLマスタースレーブセットアップで使用されるフェイルオーバーツールとしてMHAについて説明しました。先月、クラッシュしたときのMHAの処理方法についてもブログを書きました。本日は、DBAがMHAで通常遭遇する主な問題と、それらを修正する方法について説明します。

MHA（マスター高可用性）の簡単な紹介

MHAは（Master High Availability）の略で、今日でも関連性があり、広く使用されています。特に、非GTIDレプリケーションに基づくマスタースレーブセットアップで使用されています。 MHAはフェイルオーバーまたはマスタースイッチを適切に実行しますが、いくつかの落とし穴と制限があります。 MHAがマスターフェイルオーバーとスレーブプロモーションを実行すると、データベースフェイルオーバー操作を最大30秒以内に自動的に完了できます。これは、実稼働環境で許容できます。 MHAは、データの一貫性を確保できます。これはすべてパフォーマンスの低下がなく、既存の展開やセットアップに追加の調整や変更を加える必要はありません。これとは別に、MHAはPerl上に構築されており、オープンソースのHAソリューションです。そのため、必要な設定に従ってヘルパーを作成したり、ツールを拡張したりするのは比較的簡単です。詳細については、このプレゼンテーションをご覧ください。

MHAソフトウェアは2つのコンポーネントで構成されており、トポロジの役割に応じて次のパッケージのいずれかをインストールする必要があります。

MHAマネージャーノード=MHAマネージャー（マネージャー）/ MHAノード（データノード）

マスター/スレーブノード=MHAノード（データノード）

MHA Managerは、フェイルオーバー（自動または手動）を管理し、フェイルオーバーのタイミングと場所を決定し、差動リレーログを適用するための候補マスターの昇格中にスレーブリカバリを管理するソフトウェアです。マスターデータベースが停止した場合、MHAマネージャーはMHAノードエージェントと調整します。これは、マスターからの最新のbinlogイベントがないスレーブに差分リレーログを適用するためです。 MHAノードソフトウェアは、MySQLインスタンスを監視し、MHAマネージャーがスレーブからリレーログをコピーできるようにするローカルエージェントです。典型的なシナリオは、フェイルオーバーの候補マスターが現在遅れており、MHAが最新のリレーログを持っていないことを検出した場合です。したがって、binlogイベントを含む最新のスレーブを検索し、scpを使用してスレーブから欠落しているイベントをコピーし、それらを自身に適用するときに、MHAマネージャーからの委任を待ちます。

MHAは現在積極的に保守されていませんが、現在のバージョン自体は安定しており、本番環境には「十分」である可能性があることに注意してください。 githubを介して音声をエコーし、いくつかの問題に対処したり、ソフトウェアにパッチを提供したりすることもできます。

よくある問題

次に、MHAを使用するときにDBAが遭遇する最も一般的な問題を見てみましょう。

スレーブが遅れており、非対話型/自動フェイルオーバーに失敗しました！

これは、自動フェイルオーバーが中止または失敗する原因となる一般的な問題です。これは単純に聞こえるかもしれませんが、特定の問題を1つだけ指摘しているわけではありません。スレーブラグにはさまざまな理由が考えられます：

候補マスターのディスクの問題により、読み取りと書き込みを処理するためのディスクI/Oバウンドになります。軽減しないと、データの破損につながる可能性もあります。
不正なクエリは、特に主キーやクラスター化インデックスを持たないテーブルで複製されます。
サーバーの負荷が高い。
コールドサーバーとサーバーはまだウォームアップされていません
サーバーリソースが不足しています。集中的な書き込みまたは読み取りを複製しているときに、スレーブのメモリまたはサーバーリソースが少なすぎる可能性があります。

データベースを適切に監視していれば、これらを事前に軽減できます。 MHAのスレーブラグに関する1つの例は、大きなバイナリログファイルをダンプするときのメモリ不足です。以下の例では、マスターはデッドとしてマークされており、非対話型/自動フェイルオーバーを実行する必要があります。ただし、候補マスターが遅れており、レプリケーションスレッドによってまだ実行されていないログを適用する必要があるため、MHAは、最も古いスレーブに対してスレーブを回復しようとするため、最新または最新のスレーブを検索します。もの。したがって、以下に示すように、スレーブリカバリを実行しているときに、メモリが少なくなりすぎました。

[email protected]:~$ masterha_manager --conf=/etc/app1.cnf --remove_dead_master_conf --ignore_last_failover
Mon May  6 08:43:46 2019 - [warning] Global configuration file /etc/masterha_default.cnf not found. Skipping.
Mon May  6 08:43:46 2019 - [info] Reading application default configuration from /etc/app1.cnf..
Mon May  6 08:43:46 2019 - [info] Reading server configuration from /etc/app1.cnf..
…
Mon May  6 08:43:57 2019 - [info] Checking master reachability via MySQL(double check)...
Mon May  6 08:43:57 2019 - [info]  ok.
Mon May  6 08:43:57 2019 - [info] Alive Servers:
Mon May  6 08:43:57 2019 - [info]   192.168.10.50(192.168.10.50:3306)
Mon May  6 08:43:57 2019 - [info]   192.168.10.70(192.168.10.70:3306)
Mon May  6 08:43:57 2019 - [info] Alive Slaves:
Mon May  6 08:43:57 2019 - [info]   192.168.10.50(192.168.10.50:3306)  Version=5.7.23-23-log (oldest major version between slaves) log-bin:enabled
Mon May  6 08:43:57 2019 - [info]     Replicating from 192.168.10.60(192.168.10.60:3306)
Mon May  6 08:43:57 2019 - [info]     Primary candidate for the new Master (candidate_master is set)
Mon May  6 08:43:57 2019 - [info]   192.168.10.70(192.168.10.70:3306)  Version=5.7.23-23-log (oldest major version between slaves) log-bin:enabled
Mon May  6 08:43:57 2019 - [info]     Replicating from 192.168.10.60(192.168.10.60:3306)
Mon May  6 08:43:57 2019 - [info]     Not candidate for the new Master (no_master is set)
Mon May  6 08:43:57 2019 - [info] Starting Non-GTID based failover.
….
Mon May  6 08:43:59 2019 - [info] * Phase 3.4: New Master Diff Log Generation Phase..
Mon May  6 08:43:59 2019 - [info] 
Mon May  6 08:43:59 2019 - [info] Server 192.168.10.50 received relay logs up to: binlog.000004:106167341
Mon May  6 08:43:59 2019 - [info] Need to get diffs from the latest slave(192.168.10.70) up to: binlog.000005:240412 (using the latest slave's relay logs)
Mon May  6 08:43:59 2019 - [info] Connecting to the latest slave host 192.168.10.70, generating diff relay log files..
Mon May  6 08:43:59 2019 - [info] Executing command: apply_diff_relay_logs --command=generate_and_send --scp_user=vagrant --scp_host=192.168.10.50 --latest_mlf=binlog.000005 --latest_rmlp=240412 --target_mlf=binlog.000004 --target_rmlp=106167341 --server_id=3 --diff_file_readtolatest=/tmp/relay_from_read_to_latest_192.168.10.50_3306_20190506084355.binlog --workdir=/tmp --timestamp=20190506084355 --handle_raw_binlog=1 --disable_log_bin=0 --manager_version=0.58 --relay_dir=/var/lib/mysql --current_relay_log=relay-bin.000007 
Mon May  6 08:44:00 2019 - [info] 
    Relay log found at /var/lib/mysql, up to relay-bin.000007
 Fast relay log position search failed. Reading relay logs to find..
Reading relay-bin.000007
 Binlog Checksum enabled
 Master Version is 5.7.23-23-log
 Binlog Checksum enabled
…
…...
 Target relay log file/position found. start_file:relay-bin.000004, start_pos:106167468.
 Concat binary/relay logs from relay-bin.000004 pos 106167468 to relay-bin.000007 EOF into /tmp/relay_from_read_to_latest_192.168.10.50_3306_20190506084355.binlog ..
 Binlog Checksum enabled
 Binlog Checksum enabled
  Dumping binlog format description event, from position 0 to 361.. ok.
  Dumping effective binlog data from /var/lib/mysql/relay-bin.000004 position 106167468 to tail(1074342689)..Out of memory!
Mon May  6 08:44:00 2019 - [error][/usr/local/share/perl/5.26.1/MHA/MasterFailover.pm, ln1090]  Generating diff files failed with return code 1:0.
Mon May  6 08:44:00 2019 - [error][/usr/local/share/perl/5.26.1/MHA/MasterFailover.pm, ln1584] Recovering master server failed.
Mon May  6 08:44:00 2019 - [error][/usr/local/share/perl/5.26.1/MHA/ManagerUtil.pm, ln178] Got ERROR:  at /usr/local/bin/masterha_manager line 65.
Mon May  6 08:44:00 2019 - [info] 

----- Failover Report -----

app1: MySQL Master failover 192.168.10.60(192.168.10.60:3306)

Master 192.168.10.60(192.168.10.60:3306) is down!

Check MHA Manager logs at testnode20 for details.

Started automated(non-interactive) failover.
Invalidated master IP address on 192.168.10.60(192.168.10.60:3306)
The latest slave 192.168.10.70(192.168.10.70:3306) has all relay logs for recovery.
Selected 192.168.10.50(192.168.10.50:3306) as a new master.
Recovering master server failed.
Got Error so couldn't continue failover from here.

したがって、フェイルオーバーは失敗しました。上記の例は、ノード192.168.10.70に最新のリレーログが含まれていることを示しています。ただし、このシナリオ例では、ノード192.168.10.70のメモリが少ないため、ノード192.168.10.70はno_masterとして設定されています。スレーブ192.168.10.50を回復しようとすると、失敗します！

修正/解決策：

このシナリオは、非常に重要なことを示しています。高度なモニタリング環境を設定する必要があります。たとえば、レプリケーションの状態を監視するバックグラウンドまたはデーモンスクリプトを実行できます。 cronジョブを介してエントリとして追加できます。たとえば、組み込みのスクリプト masterha_check_replを使用してエントリを追加します。：

/usr/local/bin/masterha_check_repl --conf=/etc/app1.cnf

または、このスクリプトを呼び出して一定の間隔で実行するバックグラウンドスクリプトを作成します。 report_scriptオプションを使用して、要件に準拠していない場合にアラート通知を設定できます。たとえば、スレーブが高いピーク負荷時に約100秒間遅れている場合などです。 ClusterControlなどの監視プラットフォームを使用して、監視する指標に基づいて通知を送信するように設定することもできます。

これに加えて、サンプルシナリオでは、メモリ不足エラーが原因でフェイルオーバーが失敗したことに注意してください。スレーブリカバリフェーズでbinlogをダンプする必要があるため、すべてのノードに十分なメモリと適切なサイズのバイナリログがあることを確認することを検討してください。

一貫性のないスレーブ、diffの適用に失敗しました！

スレーブラグに関連して、MHAはリレーログを候補マスターに同期しようとするため、データが同期していることを確認してください。以下の例を見てください：

...
 Concat succeeded.
 Generating diff relay log succeeded. Saved at /tmp/relay_from_read_to_latest_192.168.10.50_3306_20190506054328.binlog .
 scp testnode7:/tmp/relay_from_read_to_latest_192.168.10.50_3306_20190506054328.binlog to [email protected](22) succeeded.
Mon May  6 05:43:53 2019 - [info]  Generating diff files succeeded.
Mon May  6 05:43:53 2019 - [info] 
Mon May  6 05:43:53 2019 - [info] * Phase 3.5: Master Log Apply Phase..
Mon May  6 05:43:53 2019 - [info] 
Mon May  6 05:43:53 2019 - [info] *NOTICE: If any error happens from this phase, manual recovery is needed.
Mon May  6 05:43:53 2019 - [info] Starting recovery on 192.168.10.50(192.168.10.50:3306)..
Mon May  6 05:43:53 2019 - [info]  Generating diffs succeeded.
Mon May  6 05:43:53 2019 - [info] Waiting until all relay logs are applied.
Mon May  6 05:43:53 2019 - [info]  done.
Mon May  6 05:43:53 2019 - [info] Getting slave status..
Mon May  6 05:43:53 2019 - [info] This slave(192.168.10.50)'s Exec_Master_Log_Pos equals to Read_Master_Log_Pos(binlog.000010:161813650). No need to recover from Exec_Master_Log_Pos.
Mon May  6 05:43:53 2019 - [info] Connecting to the target slave host 192.168.10.50, running recover script..
Mon May  6 05:43:53 2019 - [info] Executing command: apply_diff_relay_logs --command=apply --slave_user='cmon' --slave_host=192.168.10.50 --slave_ip=192.168.10.50  --slave_port=3306 --apply_files=/tmp/relay_from_read_to_latest_192.168.10.50_3306_20190506054328.binlog --workdir=/tmp --target_version=5.7.23-23-log --timestamp=20190506054328 --handle_raw_binlog=1 --disable_log_bin=0 --manager_version=0.58 --slave_pass=xxx
Mon May  6 05:43:53 2019 - [info] 
MySQL client version is 5.7.23. Using --binary-mode.
Applying differential binary/relay log files /tmp/relay_from_read_to_latest_192.168.10.50_3306_20190506054328.binlog on 192.168.10.50:3306. This may take long time...
mysqlbinlog: Error writing file 'UNOPENED' (Errcode: 32 - Broken pipe)
FATAL: applying log files failed with rc 1:0!
Error logs from testnode5:/tmp/relay_log_apply_for_192.168.10.50_3306_20190506054328_err.log (the last 200 lines)..
ICwgMmM5MmEwZjkzY2M5MTU3YzAxM2NkZTk4ZGQ1ODM0NDEgLCAyYzkyYTBmOTNjYzkxNTdjMDEz
….
…..
M2QxMzc5OWE1NTExOTggLCAyYzkyYTBmOTNjZmI1YTdhMDEzZDE2NzhiNDc3NDIzNCAsIDJjOTJh
MGY5M2NmYjVhN2EwMTNkMTY3OGI0N2Q0MjMERROR 1062 (23000) at line 72: Duplicate entry '12583545' for key 'PRIMARY'
5ICwgMmM5MmEwZjkzY2ZiNWE3YTAxM2QxNjc4YjQ4
OTQyM2QgLCAyYzkyYTBmOTNjZmI1YTdhMDEzZDE2NzhiNDkxNDI1MSAsIDJjOTJhMGY5M2NmYjVh
N2EwMTNkMTczN2MzOWM3MDEzICwgMmM5MmEwZjkzY2ZiNWE3YTAxM2QxNzM3YzNhMzcwMTUgLCAy
…
--------------

Bye
 at /usr/local/bin/apply_diff_relay_logs line 554.
    eval {...} called at /usr/local/bin/apply_diff_relay_logs line 514
    main::main() called at /usr/local/bin/apply_diff_relay_logs line 121
Mon May  6 05:43:53 2019 - [error][/usr/local/share/perl/5.26.1/MHA/MasterFailover.pm, ln1399]  Applying diffs failed with return code 22:0.
Mon May  6 05:43:53 2019 - [error][/usr/local/share/perl/5.26.1/MHA/MasterFailover.pm, ln1584] Recovering master server failed.
Mon May  6 05:43:53 2019 - [error][/usr/local/share/perl/5.26.1/MHA/ManagerUtil.pm, ln178] Got ERROR:  at /usr/local/bin/masterha_manager line 65.
Mon May  6 05:43:53 2019 - [info]

一貫性のないクラスターは、特に自動フェイルオーバーが有効になっている場合は非常に悪いです。この場合、主キー' 12583545 の重複エントリを検出するため、フェイルオーバーを続行できません。 '。

修正/解決策：

クラスタの状態の不整合を回避するために、ここで実行できることは複数あります。

ロスレス準同期レプリケーションを有効にします。この外部ブログをチェックしてください。これは、標準のMySQLレプリケーション設定で半同期の使用を検討する必要がある理由を学ぶための良い方法です。
マスタースレーブクラスターに対して常にチェックサムを実行します。 pt-table-checksumを使用して、テーブルが更新される頻度に応じて、週に1回または月に1回のように実行できます。 pt-table-checksumは、データベーストラフィックにオーバーヘッドを追加する可能性があることに注意してください。
GTIDベースのレプリケーションを使用します。これは問題自体には影響しませんが。ただし、GTIDベースのレプリケーションは、誤ったトランザクション、特にスレーブで直接実行されたトランザクションを特定するのに役立ちます。これのもう1つの利点は、レプリケーションでマスターホストを切り替える必要がある場合に、GTIDベースのレプリケーションを簡単に管理できることです。

マスターでのハードウェア障害が、スレーブはまだ追いついていない

自動フェイルオーバーに投資する多くの理由の1つは、マスターのハードウェア障害です。一部のセットアップでは、マスターでハードウェア障害が発生した場合にのみ自動フェイルオーバーを実行する方が理想的な場合があります。典型的なアプローチは、アラームを送信して通知することです。これは、夜中にオンコールのops担当者を起こして、その担当者に何をすべきかを決定させることを意味する場合があります。このタイプのアプローチは、GithubまたはFacebookでさえ行われます。ハードウェア障害、特にbinlogsとデータディレクトリが存在するボリュームが影響を受ける場合、特にバイナリログが障害が発生したディスクに保存されていると、フェイルオーバーが混乱する可能性があります。設計上、MHAはクラッシュしたマスターからバイナリログを保存しようとしますが、ディスクに障害が発生した場合、これは不可能です。考えられるシナリオの1つは、SSH経由でサーバーにアクセスできないことです。 MHAはバイナリログを保存できず、クラッシュしたマスターにのみ存在するバイナリログイベントを適用せずにフェールオーバーを実行する必要があります。これにより、特にスレーブがマスターに追いついていない場合、最新のデータが失われます。

修正/解決

MHAのユースケースの1つとして、準同期レプリケーションを使用することをお勧めします。これにより、このようなデータ損失のリスクが大幅に軽減されます。マスターへの書き込みは、ディスクに同期する前に、スレーブが最新のバイナリログイベントを受信していることを確認する必要があることに注意してください。 MHAは、イベントを他のすべてのスレーブに適用できるため、互いに一貫性を保つことができます。

さらに、メインディスクボリュームに障害が発生した場合に備えて、ディザスタリカバリのためにバイナリログのバックアップストリームを実行することもお勧めします。サーバーがSSH経由で引き続きアクセス可能な場合は、バイナリログパスをバイナリログのバックアップパスにポイントすることで引き続き機能するため、フェイルオーバーとスレーブリカバリを進めることができます。このようにして、データの損失を回避できます。

スプリットブレインを引き起こすVIP（仮想IP）フェイルオーバー

MHAは、デフォルトでは、VIP管理を処理しません。ただし、これをMHAの構成に組み込み、フェイルオーバー中にMHAに実行させたい内容に応じてフックを割り当てるのは簡単です。独自のスクリプトを設定して、パラメーターmaster_ip_failover_scriptまたはmaster_ip_online_change_scriptにフックすることができます。 /samples /scripts/ディレクトリにあるサンプルスクリプトもあります。しかし、主な問題に戻りましょう。それはフェイルオーバー中のスプリットブレインです。

自動フェイルオーバー中に、VIP管理を使用したスクリプトが呼び出されて実行されると、MHAは次のことを行います。ステータスを確認し、古いVIPを削除（または停止）してから、新しいVIPを新しいマスターに再割り当てします。スプリットブレインの典型的な例は、ネットワークの問題が原因でマスターが停止していると識別されたが、実際にはスレーブノードがマスターに接続できる場合です。これは誤検知であり、多くの場合、セットアップ内のデータベース間でデータの不整合が発生します。 VIPを使用した着信クライアント接続は、新しいマスターに送信されます。一方、古いマスターでローカル接続が実行されている可能性がありますが、これは停止しているはずです。ローカル接続は、ネットワークホップを減らすためにUNIXソケットまたはローカルホストを使用している可能性があります。これにより、古いマスターからのデータがスレーブに複製されないため、データが新しいマスターとその残りのスレーブに対してドリフトする可能性があります。

修正/解決策：

前に述べたように、マスターが完全にダウンしている（ハードウェア障害など）とチェックで判断されない限り、つまりスレーブノードでさえマスターに到達できない場合を除いて、自動フェイルオーバーを回避することを好む人もいます。誤検知は、MHAノードコントローラーとマスター間のネットワークグリッチによって引き起こされる可能性があるため、この場合、フェイルオーバーするかどうかを決定するのに人間が適している可能性があります。

誤ったアラームを処理する場合、MHAにはsecondary_check_scriptというパラメータがあります。ここに配置する値は、カスタムスクリプトにすることも、組み込みのスクリプト / usr / local / bin / masterha_secondary_checkを使用することもできます。これは、MHAマネージャーパッケージと一緒に出荷されます。これにより、誤検知を回避するために実際に推奨されるアプローチである追加のチェックが追加されます。以下の私自身の設定の例では、組み込みのスクリプト masterha_secondary_checkを使用しています。：

secondary_check_script=/usr/local/bin/masterha_secondary_check -s 192.168.10.50 --user=root --master_host=testnode6 --master_ip=192.168.10.60 --master_port=3306

上記の例では、MHAマネージャーはスレーブノードのリスト（-s引数で指定）に基づいてループを実行し、MySQLマスター（192.168.10.60）ホストに対する接続をチェックします。この例のこれらのスレーブノードは、クラスター内のデータベースノードへの接続を確立できる外部リモートノードである可能性があることに注意してください。これは、MHAManagerがデータベースノードとは異なるデータセンターまたは異なるネットワークで実行されているセットアップに特に推奨されるアプローチです。以下のシーケンスは、チェックがどのように進行するかを示しています。

MHAホストから->1番目のスレーブノード（IP：192.168.10.50）へのTCP接続を確認します。これを接続Aと呼びましょう。次に、スレーブノードからマスターノード（192.168.10.60）へのTCP接続を確認します。これを接続Bと呼びましょう。

「接続A」は成功したが、「接続B」は両方のルートで失敗した場合、 masterha_secondary_check スクリプトはリターンコード0で終了し、MHA ManagerはMySQLマスターが本当に死んでいると判断し、フェイルオーバーを開始します。「接続A」が失敗した場合は、 masterha_secondary_check リターンコード2で終了し、MHA Managerはネットワークに問題があると推測し、フェールオーバーを開始しません。「接続B」が成功した場合、 masterha_secondary_check リターンコード3で終了し、MHA ManagerはMySQLマスターサーバーが実際に稼働していることを理解し、フェイルオーバーを開始しません。

ログに基づくフェイルオーバー中の反応の例

Tue May  7 05:31:57 2019 - [info]  OK.
Tue May  7 05:31:57 2019 - [warning] shutdown_script is not defined.
Tue May  7 05:31:57 2019 - [info] Set master ping interval 1 seconds.
Tue May  7 05:31:57 2019 - [info] Set secondary check script: /usr/local/bin/masterha_secondary_check -s 192.168.10.50 -s 192.168.10.60 -s 192.168.10.70 --user=root --master_host=192.168.10.60 --master_ip=192.168.10.60 --master_port=3306
Tue May  7 05:31:57 2019 - [info] Starting ping health check on 192.168.10.60(192.168.10.60:3306)..
Tue May  7 05:31:58 2019 - [warning] Got error on MySQL connect: 2003 (Can't connect to MySQL server on '192.168.10.60' (110))
Tue May  7 05:31:58 2019 - [warning] Connection failed 1 time(s)..
Tue May  7 05:31:58 2019 - [info] Executing SSH check script: exit 0
Tue May  7 05:31:58 2019 - [info] Executing secondary network check script: /usr/local/bin/masterha_secondary_check -s 192.168.10.50 -s 192.168.10.60 -s 192.168.10.70 --user=root --master_host=192.168.10.60 --master_ip=192.168.10.60 --master_port=3306  --user=vagrant  --master_host=192.168.10.60  --master_ip=192.168.10.60  --master_port=3306 --master_user=cmon [email protected] --ping_type=SELECT
Master is reachable from 192.168.10.50!
Tue May  7 05:31:58 2019 - [warning] Master is reachable from at least one of other monitoring servers. Failover should not happen.
Tue May  7 05:31:59 2019 - [warning] Got error on MySQL connect: 2003 (Can't connect to MySQL server on '192.168.10.60' (110))
Tue May  7 05:31:59 2019 - [warning] Connection failed 2 time(s)..
Tue May  7 05:32:00 2019 - [warning] Got error on MySQL connect: 2003 (Can't connect to MySQL server on '192.168.10.60' (110))
Tue May  7 05:32:00 2019 - [warning] Connection failed 3 time(s)..
Tue May  7 05:32:01 2019 - [warning] Got error on MySQL connect: 2003 (Can't connect to MySQL server on '192.168.10.60' (110))
Tue May  7 05:32:01 2019 - [warning] Connection failed 4 time(s)..
Tue May  7 05:32:03 2019 - [warning] HealthCheck: Got timeout on checking SSH connection to 192.168.10.60! at /usr/local/share/perl/5.26.1/MHA/HealthCheck.pm line 343.
Tue May  7 05:32:03 2019 - [warning] Secondary network check script returned errors. Failover should not start so checking server status again. Check network settings for details.
Tue May  7 05:32:04 2019 - [warning] Got error on MySQL connect: 2003 (Can't connect to MySQL server on '192.168.10.60' (110))
Tue May  7 05:32:04 2019 - [warning] Connection failed 1 time(s)..
Tue May  7 05:32:04 2019 - [info] Executing secondary network check script: /usr/local/bin/masterha_secondary_check -s 192.168.10.50 -s 192.168.10.60 -s 192.168.10.70 --user=root --master_host=192.168.10.60 --master_ip=192.168.10.60 --master_port=3306  --user=vagrant  --master_host=192.168.10.60  --master_ip=192.168.10.60  --master_port=3306 --master_user=cmon [email protected] --ping_type=SELECT
Tue May  7 05:32:04 2019 - [info] Executing SSH check script: exit 0

追加するもう1つのことは、パラメーターshutdown_scriptに値を割り当てることです。このスクリプトは、適切なSTONITHまたはノードフェンシングを実装して、死から立ち上がらないようにする必要がある場合に特に役立ちます。これにより、データの不整合を回避できます。

最後に、ネットワークの停止、特にMHAマネージャーからデータベースノードへの接続の可能性を減らすため、MHAマネージャーがクラスターノードと同じローカルネットワーク内に存在することを確認します。

MHAでのSPOFの回避

MHAはさまざまな理由でクラッシュする可能性がありますが、残念ながら、これを修正するための組み込み機能、つまりMHAの高可用性はありません。ただし、以前のブログ「マスター高可用性マネージャー（MHA）がクラッシュしました！今何をしますか？」で説明したように、MHAのSPOFを回避する方法があります。

修正/解決策：

Pacemakerを利用して、クラスターリソースマネージャー（crm）によって処理されるアクティブ/スタンバイノードを作成できます。または、MHAマネージャーノードの正常性を確認するスクリプトを作成することもできます。たとえば、組み込みのスクリプト masterha_check_status をsshで実行することにより、MHAマネージャーノードをアクティブにチェックするスタンバイノードをプロビジョニングできます。以下のように：

[email protected]:~$ /usr/local/bin/masterha_check_status --conf=/etc/app1.cnf
app1 is stopped(2:NOT_RUNNING).

次に、そのコントローラーが中断されている場合は、ノードフェンシングを実行します。また、cronジョブを介して実行されるヘルパースクリプトを使用してMHAツールを拡張し、masterha_managerスクリプトのシステムプロセスを監視し、プロセスが停止している場合は再生成することもできます。

フェイルオーバー中のデータ損失

MHAは、従来の非同期レプリケーションに依存しています。半同期をサポートしていますが、それでも、半同期は非同期レプリケーションに依存しています。このタイプの環境では、フェイルオーバー後にデータ損失が発生する可能性があります。データベースが適切にセットアップされておらず、昔ながらのレプリケーションアプローチを使用している場合、特にデータの一貫性や失われたトランザクションを処理するときに問題が発生する可能性があります。

MHAでのデータ損失に関して注意すべきもう1つの重要な点は、半同期を有効にせずにGTIDを使用する場合です。 GTIDを使用するMHAは、sshを介してマスターに接続しませんが、ノード回復のためにバイナリログを最初にスレーブと同期しようとします。これにより、セミシンクが有効になっていないMHA非GTIDと比較した場合よりも多くのデータ損失が発生する可能性があります。

修正/解決

自動フェイルオーバーを実行する場合、MHAがフェイルオーバーすると予想されるシナリオのリストを作成します。 MHAはマスタースレーブレプリケーションを処理しているため、データの損失を回避するためのアドバイスは次のとおりです。

ロスレス半同期レプリケーションを有効にします（バージョンMySQL 5.7に存在します）
GTIDベースのレプリケーションを使用します。もちろん、binlogのx座標とy座標を使用して、従来の複製を使用できます。ただし、スレーブに適用されていない特定のバイナリログエントリを見つける必要がある場合は、事態がより困難で時間がかかります。したがって、MySQLのGTIDを使用すると、誤ったトランザクションを簡単に検出できます。
MySQLマスタースレーブレプリケーションのACID準拠については、次の特定の変数を有効にします：sync_binlog =1、innodb_flush_log_at_trx_commit =1。これは、MySQLがコミット時にfsync（）関数を呼び出すときに、より多くの処理能力とパフォーマンスを必要とするため、コストがかかります。書き込み回数が多い場合は、ディスクにバインドできます。ただし、バッテリバックアップキャッシュでRAIDを使用すると、ディスクI/Oを節約できます。さらに、MySQL自体はバイナリロググループコミットで改善されていますが、バックアップキャッシュを使用すると、ディスク同期を節約できます。
並列レプリケーションまたはマルチスレッドスレーブレプリケーションを活用します。これにより、スレーブのパフォーマンスが向上し、マスターに対するスレーブの遅延を回避できます。マスターがsshまたはtcp接続を介してまったく到達できない場合、またはマスターにディスク障害が発生し、スレーブが遅れている場合に、自動フェイルオーバーが発生しないようにする必要があります。データの損失につながる可能性があります。
オンラインまたは手動のフェイルオーバーを実行する場合は、データ損失につながる可能性のある予期しない事故を回避するために、ピーク時以外の期間に実行することをお勧めします。または、多くのアクティビティが実行されているときに、時間のかかる検索がバイナリログを検索するのを避けるためです。

MHAは、APPが実行されていない、またはフェイルオーバーが機能しないと言います。どうすればいいですか？

組み込みスクリプトmasterha_check_statusを使用してチェックを実行すると、mastreha_managerスクリプトが実行されているかどうかがチェックされます。そうしないと、次のようなエラーが発生します：

[email protected]:~$ /usr/local/bin/masterha_check_status --conf=/etc/app1.cnf                                                                                                                       app1 is stopped(2:NOT_RUNNING).

ただし、 masterha_manager の場合でも、NOT_RUNNINGが発生する場合があります。が走っています。これは、設定したssh_userの特権が原因であるか、別のシステムユーザーでmasterha_managerを実行しているか、sshユーザーがアクセス許可の拒否に遭遇したことが原因である可能性があります。

修正/解決策：

MHAはssh_userを使用します指定されている場合は、構成で定義されます。それ以外の場合は、MHAコマンドの呼び出しに使用する現在のシステムユーザーを使用します。スクリプトを実行するときmasterha_check_status たとえば、masterha_managerが ssh_userで指定されているのと同じユーザーで実行されていることを確認する必要があります。構成ファイル内、またはクラスター内の他のデータベースノードとインターフェイスするユーザー。 MHAが監視しているノードへの接続を確立するときに、MHAが問題を起こさないように、パスワードなしでパスフレーズSSHキーがないことを確認する必要があります。

ssh_userが必要であることに注意してください以下にアクセスするには：

MHAが監視しているMySQLノードのバイナリログとリレーログを読み取ることができます
MHA監視ログにアクセスできる必要があります。 MHAで次のパラメーターを確認してください：master_binlog_dir、manager_workdir、およびmanager_log
MHA構成ファイルにアクセスできる必要があります。これも非常に重要です。フェイルオーバー中に、フェイルオーバーが完了すると、構成ファイルを更新し、デッドマスターのエントリを削除しようとします。構成ファイルでssh_userが許可されていない場合または、現在使用しているOSユーザーは、構成ファイルを更新しないため、災害が再び発生した場合に問題がエスカレートします。

キャンディマスターラグ、フェイルオーバーの失敗を強制および回避する方法

MHAのwikiを参照すると、デフォルトでは、スレーブが100MBを超えるリレーログをマスターの背後にある場合（=100MBを超えるリレーログを適用する必要がある）、リカバリに時間がかかりすぎるため、MHAはスレーブを新しいマスターとして選択しません。。

修正/解決

MHAでは、パラメーターcheck_repl_delay=0を設定することでこれをオーバーライドできます。フェイルオーバー中、MHAは新しいマスターを選択するときにレプリケーションの遅延を無視し、欠落しているトランザクションを実行します。このオプションは、特定のホストでcandidate_master =1を設定し、そのホストが新しいマスターになることを確認したい場合に便利です。

pt-heartbeatと統合して、スレーブラグの精度を達成することもできます（この投稿とこれを参照してください）。ただし、これは、MySQL 5.6以降に存在する並列レプリケーションまたはマルチスレッドレプリケーションスレーブ、またはMariaDB 10を使用して、並列レプリケーションおよびマルチスレッドスレーブが10倍向上すると主張して軽減することもできます。これにより、スレーブの複製を高速化できます。

MHAパスワードが公開されます

パスワードの保護または暗号化は、MHAによって処理されるものではありません。 The parameters password or repl_password will be exposed via the configuration file. So your system administrator or security architect must evaluate the grants or privileges of this file as you don’t want to expose valuable database/SSH credentials.

Fixes/Resolution:

MHA has an optional parameter init_conf_load_script. This parameter can be used to have a custom script load your MHA config that will interface to e.g. a database, and retrieve the user/password credentials of your replication setup.

Of course, you can also limit the file attribute of the configuration and the user you are using, and limit the access to the specific Ops/DBA's/Engineers that will handle MHA.

MHA is Not My Choice, What Are the Alternatives for replication failover?

MHA is not a one-size-fits-all solution, it has its limitations and may not fit your desired setup. However, here's a list of variants that you can try.

PRM
Maxscale with Mariadb Monitor or MariaDB Replication Manager (MRM)
Orchestrator
ClusterControl