6.2 MySQL InnoDB クラスタ
6.2.7 InnoDB クラスタ のトラブルシューティング
このセクションでは、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() を使用してインスタンスを手動でクラスタに追加しなおします。
InnoDB クラスタ のトラブルシューティング
リストアされたクラスタは、クラスタを構成していたすべての元のインスタンスで構成されている場合があり、必ず しも構成されている必要はありません。 たとえば、元のクラスタが次の 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 を対話型モードで実行している場合、ウィザードが実行され、現在アクセス可能なクラスタのインス タンスがチェックされ、検出されたインスタンスを再起動されたクラスタに再結合するかどうかが尋ねられます。
• 同様に、対話型モードでも、ウィザードは現在到達できないインスタンスを検出し、再起動されたクラスタからそ のようなインスタンスを削除するかどうかを尋ねます。
このページは機械翻訳したものです。
InnoDB クラスタ のトラブルシューティング
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」。
• リストで指定されたインスタンスは、確認を求められることなくメタデータから削除されます