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

6.2.8.3 InnoDB クラスタ のアップグレードのトラブルシューティング

このセクションでは、アップグレードプロセスのトラブルシューティングについて説明します。

ホスト名の変更の処理

MySQL Shell は、指定された接続パラメータのホスト値を、AdminAPI 操作、つまりメタデータへのインスタンスの登録 (dba.createCluster() および Cluster.addInstance() 操作) に使用されるターゲットホスト名として使用します。 ただし、接続パラメータに使用される実際のホストは、Group Replication によって使用または報告される hostname と一致しない可能性があります。この場合は、定義時に report_host システム変数の値が使用されます (つまり、NULL ではありません)。それ以外の場合は、hostname の値が使用されます。 したがって、AdminAPI は、インスタンス接続パラメータのホスト値を使用するかわりに、同じロジックに従ってメタデータにターゲットインスタンスを登録し、インスタンスの group_replication_local_address 変数のデフォルト値として登録するようになりました。 report_host 変数が空に設定されている場合、グループレプリケーションではホストに空の値が使用されますが、AdminAPI では (dba.checkInstanceConfiguration(), dba.configureInstance(), dba.createCluster() などのコマンドで) ホスト名が使用された値としてレポートされ、これは Group Replication によって報告された値と矛盾しています。 report_host システム変数に空の値が設定されている場合、エラーが生成されます。 (Bug #28285389)

8.0.16 より前のバージョンの MySQL Shell を使用して作成されたクラスタの場合、バージョン 8.0.16 以上を使用して実行された完全な停止からクラスタを再起動しようとすると、このエラーが発生します。 これは、メタデータ値がインスタンスによって報告された report_host または hostname 値と一致しないことが原因です。 回避策は次のとおりです:

1. 「seed」 であるインスタンス、つまり最新の GTID セットを持つインスタンスを識別します。 dba.rebootClusterFromCompleteOutage() 操作は、インスタンスがシードであるかどうかを検出し、現行のセッションが最新のインスタンスに接続されていない場合はエラーを生成します。

2. report_host システム変数を、ターゲットインスタンスのメタデータスキーマに格納されている値に設定します。 この値は、クラスタ作成時にインスタンス定義で使用される hostname:port ペアです。 この値は、mysql_innodb_cluster_metadata.instances テーブルをクエリーすることで参照できます。

   たとえば、次の一連のコマンドを使用してクラスタが作成されたとします:

   mysql-js> \c clusterAdmin@localhost:3306
   mysql-js> dba.createCluster("myCluster")

   したがって、メタデータに格納されるホスト名の値は 「localhost」 であり、そのため、シードで report_host を 「localhost」 に設定する必要があります。

3. シードインスタンスのみを使用してクラスタを再起動します。 対話型プロンプトでは、残りのインスタンスはクラスタに追加されません。

4. Cluster.rescan() を使用して、他のインスタンスをクラスタに追加します。

5. クラスタからシードインスタンスを削除

6. シードインスタンスで mysqld を停止し、強制 report_host 設定を削除するか (ステップ 2)、メタデータ値に以前格納されていた値で置き換えます。

7. シードインスタンスを再起動し、Cluster.addInstance() を使用してクラスタに追加しなおします

これにより、クラスタを最新の MySQL Shell バージョンにスムーズかつ完全にアップグレードできます。 ユースケースに依存する別の可能性は、クラスタの作成時にメタデータスキーマに登録されているものと一致するように、すべてのクラスタメンバーで report_host の値を設定することです。