このページは機械翻訳したものです。

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 クラスタ メタデータを含むインスタンスに接続でき、そのインスタンスがクラスタのリストアに使用する他のインスタンスに接続できることを前提としています。

重要

この操作は、不適切に使用された場合にスプリットブレインシナリオが作成される可能性があり、最後の手段とみなす必要があるため、危険になる可能性があります。 ネットワーク内のどこかで動作しているが、自分の場所からアクセスできないこのグループのパーティションがないことを絶対に確認してください。

クラスタメタデータを含むインスタンスに接続し、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 スーパーセットを含むインスタンスが不明な場合は、任意のインスタンスに接続し、接続しているインスタンスに 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 ディクショナリでは、次のものがサポートされています:

• interactive: コマンド実行でウィザードを無効または有効にするために使用されるブール値。 プロンプトと確認を提供するかどうかを制御します。 デフォルト値は、shell.options.useWizards で指定された MySQL Shell ウィザードモードと同じです。

• addInstances: メタデータに追加する新しいアクティブインスタンスの接続データを含むリスト、または欠落しているインスタンスをメタデータに自動的に追加する 「auto」。 値 「auto」 では、大/小文字は区別されません。

  • リストで指定されたインスタンスは、確認を求められることなくメタデータに追加されます

  • 対話モードでは、addInstances オプションに含まれていない新しく検出されたインスタンスの追加を確認するプロンプトが表示されます

  • 非対話型モードでは、addInstances オプションに含まれていない新しく検出されたインスタンスが出力にレポートされますが、追加を求めるプロンプトは表示されません

• removeInstances: メタデータから削除する廃止されたインスタンスの接続データを含むリスト、またはメタデータから不要なインスタンスを自動的に削除する 「auto」。

  • リストで指定されたインスタンスは、確認を求められることなくメタデータから削除されます

  • 対話型モードでは、removeInstances オプションに含まれていない不要なインスタンスの削除を確認するプロンプトが表示されます

  • 非対話型モードでは、removeInstances オプションに含まれていない廃止されたインスタンスは出力にレポートされますが、削除を求めるプロンプトは表示されません

• updateTopologyMode: メタデータのトポロジモード (単一プライマリまたはマルチプライマリ) を、クラスタで使用されているトポロジモードと一致するように更新する (true) か更新しない (false) かを示すために使用されるブール値。 デフォルトでは、メタデータは更新されません (false)。

  • 値が true の場合、InnoDB クラスタ メタデータはグループレプリケーションで使用されている現在のモードと比較され、必要に応じてメタデータが更新されます。 このオプションを使用して、AdminAPI 外部のクラスタのトポロジモードを変更した後にメタデータを更新します。

  • 値が false の場合、クラスタトポロジモードに関する InnoDB クラスタ メタデータは、クラスタグループレプリケーショングループで使用されるトポロジと異なる場合でも更新されません

  • このオプションが指定されておらず、メタデータのトポロジモードがクラスタグループレプリケーショングループで使用されるトポロジと異なる場合は、次のようになります:

    • 対話モードでは、メタデータのトポロジモードの更新を確認するプロンプトが表示されます

    • 非対話型モードでは、クラスタグループレプリケーショングループで使用されるトポロジと InnoDB クラスタ メタデータに違いがある場合、それがレポートされ、メタデータは変更されません

  • メタデータトポロジモードがグループレプリケーションモードと一致するように更新されると、InnoDB クラスタ および自動増分 で説明されているように、すべてのインスタンスの自動増分設定が更新されます。