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

6.2.8 InnoDB クラスタ のアップグレード

6.2.8.1 ローリングアップグレード

6.2.8.2 InnoDB クラスタ メタデータのアップグレード

6.2.8.3 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。メタデータ、およびバージョンは TTL リフレッシュ間でバージョンを変更できます。 これにより、クラスタのアップグレード中にルーティングが続行されます。

バージョン 5.7 や 8.0 など、複数の MySQL バージョンを実行するクラスタ内にインスタンスを含めることはできますが、このような混在は長時間使用する場合にはお薦めしません。 たとえば、バージョンが混在するクラスタでは、バージョン 5.7 を実行しているインスタンスがクラスタから離れ、リカバリ操作に MySQL クローンが使用される場合、BACKUP_ADMIN 権限が要件になるため、下位バージョンを実行しているインスタンスはクラスタに参加できなくなります。 複数のバージョンでクラスタを実行することは、あるバージョンから別のバージョンへの移行を支援する一時的な状況として意図されているため、長期的な使用には依存しないでください。