6.2 MySQL InnoDB クラスタ
6.2.8 InnoDB クラスタ のアップグレード
このセクションでは、クラスタをアップグレードする方法について説明します。 InnoDB クラスタ のアップグ レードプロセスの多くは、グループレプリケーションのアップグレード に記載されているのと同じ方法でインス タンスをアップグレードすることで構成されます。 このセクションでは、InnoDB クラスタ のアップグレードに 関するその他の考慮事項に焦点を当てます。 アップグレードを開始する前に、MySQL Shell セクション8.1「アッ プグレードチェッカユーティリティ」 を使用して、インスタンスのアップグレード準備ができていることを確認 できます。
バージョン 8.0.19 から、クラスタに対して MySQL Router をブートストラップしようとしたときに、メタデータ バージョンが 0.0.0 であることが検出された場合、これはメタデータのアップグレードが進行中であることを示 し、ブートストラップは失敗します。 メタデータのアップグレードが完了するまで待ってから、ブートストラッ プを再試行してください。 MySQL Router が正常に (ブートストラップではなく) 動作している場合、メタデータ バージョンが 0.0.0 (アップグレード進行中) であることが検出されても、開始しようとしていたメタデータのリフ レッシュは続行されません。 かわりに、MySQL Router はキャッシュされた最後のメタデータを引き続き使用し ます。 既存のすべてのユーザー接続が維持され、新しい接続はキャッシュされたメタデータに従ってルーティン グされます。 メタデータバージョンが 0.0.0 でなくなると、メタデータのリフレッシュが再開されます。 通常の (ブートストラップではない) モードでは、MySQL Router はバージョン 1.x.x と 2.x.x。メタデータ、およびバー
InnoDB クラスタ のアップグレード
ジョンは TTL リフレッシュ間でバージョンを変更できます。 これにより、クラスタのアップグレード中にルー ティングが続行されます。
バージョン 5.7 や 8.0 など、複数の MySQL バージョンを実行するクラスタ内にインスタンスを含めることはでき ますが、このような混在は長時間使用する場合にはお薦めしません。 たとえば、バージョンが混在するクラスタ では、バージョン 5.7 を実行しているインスタンスがクラスタから離れ、リカバリ操作に MySQL クローンが使 用される場合、BACKUP_ADMIN 権限が要件になるため、下位バージョンを実行しているインスタンスはクラス タに参加できなくなります。 複数のバージョンでクラスタを実行することは、あるバージョンから別のバージョ ンへの移行を支援する一時的な状況として意図されているため、長期的な使用には依存しないでください。
6.2.8.1 ローリングアップグレード
8.0.19 より前の MySQL Shell バージョンによってデプロイされたクラスタのメタデータスキーマをアップグレー ドする場合、既存の MySQL Router インスタンスのローリングアップグレードが必要です。 このプロセスによ り、アップグレード中のアプリケーションの中断が最小限に抑えられます。 ローリングアップグレード処理は、
次の順序で実行する必要があります:
1. 最新の MySQL Shell バージョンを実行し、グローバルセッションをクラスタに接続し
て、dba.upgradeMetadata() を発行します。 このステップでは、クラスタ用に構成された MySQL Router ア カウントの権限が、新しいバージョンと互換性を持つように変更されていることを確認します。 古い MySQL Router インスタンスが検出されると、アップグレード機能は停止します。この時点で、MySQL Shell でアッ プグレードプロセスを停止して後で再開できます。
2. 検出された最新でない MySQL Router インスタンスを最新バージョンにアップグレードします。 MySQL Shell バージョンと同じ MySQL Router バージョンを使用することをお薦めします。
3.
dba.upgradeMetadata() 操作を続行または再起動して、メタデータのアップグレードを完了します。
6.2.8.2 InnoDB クラスタ メタデータのアップグレード
AdminAPI の進化に伴い、一部のリリースでは、既存のクラスタのメタデータをアップグレードして、新しい バージョンの MySQL Shell との互換性を確保する必要がある場合があります。 たとえば、バージョン 8.0.19 に InnoDB ReplicaSet を追加することは、メタデータスキーマがバージョン 2.0 にアップグレードされていることを 意味します。 InnoDB ReplicaSet を使用するかどうかに関係なく、以前のバージョンの MySQL Shell を使用して デプロイされたクラスタで MySQL Shell 8.0.19 以降を使用するには、クラスタのメタデータをアップグレードす る必要があります。
警告
メタデータをアップグレードしないと、MySQL Shell 8.0.19 を使用して、以前の バージョンで作成されたクラスタの構成を変更できません。 たとえば、読取り操作 は、Cluster.status()、Cluster.describe()、Cluster.options() などのクラスタに対してのみ 実行できます。
この dba.upgradeMetadata() 操作では、クラスタ MySQL Shell で現在接続されているメタデータスキーマのバー ジョンが、この MySQL Shell バージョンでサポートされているメタデータスキーマのバージョンと比較されま す。 インストールされているメタデータのバージョンが低い場合は、アップグレードプロセスが開始されます。
その後、dba.upgradeMetadata() 操作によって、自動的に作成された MySQL Router ユーザーが適切な権限を 持つようにアップグレードされます。 mysql_router_で始まらない名前で手動で作成された MySQL Router ユー ザーは、自動的にはアップグレードされません。 これは、クラスタをアップグレードする際の重要なステップ であり、MySQL Router アプリケーションのみをアップグレードできます。 クラスタに登録されている MySQL Router インスタンスのうち、メタデータのアップグレードが必要なものに関する情報を取得するには、次のコマ ンドを発行します:
cluster.listRouters({'onlyUpgradeRequired':'true'}) { "clusterName": "mycluster",
"routers": { "example.com::": {
"hostname": "example.com", "lastCheckIn": "2019-11-26 10:10:37", "roPort": 6447,
"roXPort": 64470, "rwPort": 6446, "rwXPort": 64460, "version": "8.0.18"
} } }
InnoDB クラスタ のアップグレード
警告
新しいメタデータを使用しているクラスタは、以前の MySQL Shell バージョンでは管理 できません。たとえば、バージョン 8.0.19 にアップグレードすると、バージョン 8.0.18 以前を使用してクラスタを管理できなくなります。
クラスタメタデータをアップグレードするには、MySQL Shell グローバルセッションをクラスタに接続 し、dba.upgradeMetadata() 操作を使用してクラスタメタデータを新しいメタデータにアップグレードします。
例:
mysql-js> \connect [email protected]:3306 mysql-js> dba.upgradeMetadata()
InnoDB Cluster Metadata Upgrade
The cluster you are connected to is using an outdated metadata schema version 1.0.1 and needs to be upgraded to 2.0.0.
Without doing this upgrade, no AdminAPI calls except read only operations will be allowed.
The grants for the MySQL Router accounts that were created automatically when bootstrapping need to be updated to match the new metadata version's requirements.
Updating router accounts...
NOTE: 2 router accounts have been updated.
Upgrading metadata at 'example.com:3306' from version 1.0.1 to version 2.0.0.
Creating backup of the metadata schema...
Step 1 of 1: upgrading from 1.0.1 to 2.0.0...
Removing metadata backup...
Upgrade process successfully finished, metadata schema is now on version 2.0.0
権限のないクラスタ管理ユーザーに関連するエラーが発生した場合は、更新オプションを指定して
Cluster.setupAdminAccount() 操作を使用し、ユーザーに正しい権限を付与します。 AdminAPI のユーザーの構
成を参照してください。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 の値を設定することです。