6.2 MySQL InnoDB クラスタ
6.2.7 InnoDB クラスタ のトラブルシューティング
このセクションでは、InnoDB クラスタ のトラブルシューティング方法について説明します。
• クラスタへのインスタンスの再参加
• クォーラム損失からのクラスタのリストア
• メジャーな停止からのクラスタの再起動
• クラスタの再スキャン
クラスタへのインスタンスの再参加
たとえば、接続が失われ、なんらかの理由で自動的にクラスタに再参加できなかったために、インスタンスがク ラスタを離れた場合は、後でクラスタに再参加する必要がある場合があります。 インスタンスをクラスタに再結 合するには、Cluster.rejoinInstance(instance) を発行します。
ヒント
インスタンスに super_read_only=ON がある場合は、AdminAPI で
super_read_only=OFF を設定できることを確認する必要がある場合があります。 詳し
くはスーパー読取り専用およびインスタンスをご覧ください。インスタンスの構成が永続化されていない場合 (設定の永続化 を参照)、インスタンスの再起動時にクラスタ に自動的に再参加しません。 解決策は、インスタンスがクラスタに再度追加され、変更が永続化されるよう に、cluster.rejoinInstance() を発行することです。 InnoDB クラスタ 構成がインスタンスオプションファイルに永 続化されると、クラスタに自動的に再結合されます。
なんらかの方法で変更されたインスタンスを再結合する場合は、再結合プロセスが正しく機能するようにインス タンスを変更する必要がある場合があります。 たとえば、MySQL Enterprise Backup バックアップをリストアす ると、server_uuid が変更されます。 このようなインスタンスを再結合しようとすると、InnoDB クラスタ イン スタンスが server_uuid 変数によって識別されるため、失敗します。 このような状況では、古いインスタンスの
server_uuid に関する情報を InnoDB クラスタ メタデータから削除してから、Cluster.rescan() を実行し、新しい server_uuid を使用してインスタンスをメタデータに追加する必要があります。 例:
cluster.removeInstance("root@instanceWithOldUUID:3306", {force: true}) cluster.rescan()
この場合、インスタンスはクラスタの観点からアクセスできず、InnoDB クラスタ メタデータから削除する必要 があるため、force オプションを Cluster.removeInstance() メソッドに渡す必要があります。
クォーラム損失からのクラスタのリストア
インスタンスに障害が発生すると、クラスタのクォーラムが失われる可能性があります。これは、新しいプライ マリで投票する機能です。 これは、グループレプリケーション操作で投票するクラスタを構成するインスタン スの大部分がなくなった場合に発生する可能性があります。 Fault-toleranceを参照してください。 クラスタが クォーラムを失うと、インスタンスの追加、再参加、削除などによって、クラスタとの書込みトランザクショ ンを処理したり、クラスタトポロジを変更することはできなくなります。 ただし、InnoDB クラスタ メタデー タを含むオンラインのインスタンスがある場合は、クォーラムを使用してクラスタをリストアできます。 これ は、InnoDB クラスタ メタデータを含むインスタンスに接続でき、そのインスタンスがクラスタのリストアに使 用する他のインスタンスに接続できることを前提としています。
InnoDB クラスタ のトラブルシューティング
重要
この操作は、不適切に使用された場合にスプリットブレインシナリオが作成される可能 性があり、最後の手段とみなす必要があるため、危険になる可能性があります。 ネット ワーク内のどこかで動作しているが、自分の場所からアクセスできないこのグループの パーティションがないことを絶対に確認してください。
クラスタメタデータを含むインスタンスに接続し、Cluster.forceQuorumUsingPartitionOf(instance) 操作を使用し て instance のメタデータに基づいてクラスタをリストアし、指定されたインスタンス定義の観点から ONLINE で あるすべてのインスタンスがリストアされたクラスタに追加されます。
mysql-js> cluster.forceQuorumUsingPartitionOf("icadmin@ic-1:3306")
Restoring replicaset 'default' from loss of quorum, by using the partition composed of [icadmin@ic-1:3306]
Please provide the password for 'icadmin@ic-1:3306': ******
Restoring the InnoDB cluster ...
The InnoDB cluster was successfully restored using the partition from the instance 'icadmin@ic-1:3306'.
WARNING: To avoid a split-brain scenario, ensure that all other members of the replicaset are removed or joined back to the group that was restored.
インスタンスがクラスタに自動的に追加されない場合 (設定が永続化されていない場合など) は、Cluster.rejoinInstance() を使用してインスタンスを手動でクラスタに追加しなおします。
リストアされたクラスタは、クラスタを構成していたすべての元のインスタンスで構成されている場合があり、
必ずしも構成されている必要はありません。 たとえば、元のクラスタが次の 5 つのインスタンスで構成されてい るとします:
•
ic-1
•
ic-2
•
ic-3
•
ic-4
•
ic-5
クラスタでは、ic-1、ic-2 および ic-3 があるパーティションを形成し、ic-4 および ic-5 が 別のパーティションを形成するスプリットブレインシナリオが発生します。 ic-1 に接続
し、Cluster.forceQuorumUsingPartitionOf('icadmin@ic-1:3306') を発行してクラスタをリストアする場合、結果の クラスタは次の 3 つのインスタンスで構成されます:
•
ic-1
•
ic-2
•
ic-3
これは、ic-1 では、ic-2 および ic-3 が ONLINE として認識され、ic-4 および ic-5 が表示されないためです。
メジャーな停止からのクラスタの再起動
クラスタで完全な停止が発生した場合、dba.rebootClusterFromCompleteOutage() を使用してクラスタが正しく再 構成されていることを確認できます。 この操作では、MySQL Shell が現在接続しているインスタンスを取得し、
そのメタデータを使用してクラスタをリカバリします。 クラスタインスタンスが完全に停止している場合は、イ ンスタンスを起動してからクラスタを起動できるようにする必要があります。 たとえば、サンドボックスクラス タが実行されていたマシンが再起動され、インスタンスがポート 3310、3320 および 3330 にあった場合は、次を 発行します:
mysql-js> dba.startSandboxInstance(3310) mysql-js> dba.startSandboxInstance(3320) mysql-js> dba.startSandboxInstance(3330)
これにより、サンドボックスインスタンスが確実に実行されます。 本番デプロイメントの場合は、MySQL Shell の外部でインスタンスを起動する必要があります。 インスタンスが起動したら、GTID スーパーセット (停止前 に最も多くのトランザクションを適用したインスタンス) を使用してインスタンスに接続する必要があります。
GTID スーパーセットを含むインスタンスが不明な場合は、任意のインスタンスに接続し、接続しているインスタ
InnoDB クラスタ のトラブルシューティング
ンスに GTID スーパーセットが含まれているかどうかを検出する dba.rebootClusterFromCompleteOutage() 操作 からの対話型メッセージに従います。 次を発行して、クラスタを再起動します:
mysql-js> var cluster = dba.rebootClusterFromCompleteOutage();
その後、dba.rebootClusterFromCompleteOutage() 操作は次のステップに従って、クラスタが正しく再構成されて いることを確認します:
• MySQL Shell が現在接続されているインスタンスで見つかった InnoDB クラスタ メタデータがチェックさ れ、GTID スーパーセット (つまり、クラスタによって適用されたトランザクション) が含まれているかどうか が確認されます。 現在接続されているインスタンスに GTID スーパーセットが含まれていない場合、操作はそ の情報で中止されます。 詳細は、後続の段落を参照してください。
• インスタンスに GTID スーパーセットが含まれている場合、クラスタはインスタンスのメタデータに基づいて リカバリされます。
• MySQL Shell を対話型モードで実行している場合、ウィザードが実行され、現在アクセス可能なクラスタのイ ンスタンスがチェックされ、検出されたインスタンスを再起動されたクラスタに再結合するかどうかが尋ねら れます。
• 同様に、対話型モードでも、ウィザードは現在到達できないインスタンスを検出し、再起動されたクラスタか らそのようなインスタンスを削除するかどうかを尋ねます。
MySQL Shell 対話型モードを使用していない場合は、rejoinInstances および removeInstances オプションを使用 して、クラスタの再起動時に結合または削除する必要があるインスタンスを手動で構成できます。
「アクティブセッションインスタンスは、クラスタメタデータの ONLINE インスタンスと比較して最も更新され ません。」などのエラーが発生した場合、接続しているインスタンスには、クラスタによって適用される GTID
スーパーセットのトランザクションがありません。 この状況では、MySQL Shell をエラーメッセージに示された インスタンスに接続し、そのインスタンスから dba.rebootClusterFromCompleteOutage() を発行します。ヒント
対話型ウィザードを使用するのではなく GTID スーパーセットを持つインスタンスを手 動で検出するには、各インスタンスの gtid_executed 変数を確認します。 たとえば、次 のコマンドを発行します:
mysql-sql> SHOW VARIABLES LIKE 'gtid_executed';
トランザクションの最大「GTID セット」を適用したインスタンスに GTID スーパー セットが含まれています。
このプロセスが失敗し、クラスタメタデータが不正に破損した場合は、メタデータを削除し、クラスタを最初か ら再度作成する必要がある場合があります。 dba.dropMetadataSchema() を使用してクラスタメタデータを削除 できます。
警告
dba.dropMetadataSchema() メソッドは、クラスタをリストアできない場合に、最後の
手段としてのみ使用してください。 元に戻すことはできません。クラスタで MySQL Router を使用している場合、メタデータを削除すると、現在のすべての接続が切断され、新 しい接続は禁止されます。 これにより、完全な停止が発生します。
クラスタの再スキャン
構成の問題を解決するためにインスタンス構成を手動で変更するなどして、AdminAPI コマンドの外部でクラス タに構成変更を加えた場合、またはインスタンスの損失後に、InnoDB クラスタ メタデータがインスタンスの現 在の構成と一致するように更新する必要があります。 このような場合は、Cluster.rescan() 操作を使用します。
これにより、InnoDB クラスタ メタデータを手動で更新するか、対話型ウィザードを使用して更新できます。
Cluster.rescan() 操作では、メタデータに登録されていない新しいアクティブインスタンスを検出して追加した
り、メタデータにまだ登録されている (アクティブでなくなった) 古いインスタンスを検出して削除できます。 コ マンドで検出されたインスタンスに応じてメタデータを自動的に更新することも、メタデータに追加またはメタ データから削除するインスタンスアドレスのリストを指定することもできます。 メタデータに格納されているト ポロジモードを更新することもできます。たとえば、AdminAPI の外部で単一プライマリモードからマルチプライ マリモードに変更した後などです。コマンドの構文は Cluster.rescan([options]) です。 options ディクショナリでは、次のものがサポートされていま す: