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

18.7.3.3 グループレプリケーションのオンラインアップグレード方法

グループレプリケーショングループをアップグレードするには、次のいずれかの方法を選択します:

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

この方法は、新しいバージョンを実行しているサーバーがグループにワークロードを生成せず、古いバージョンのサーバーが存在する場合にサポートされます。 つまり、新しいバージョンのサーバーは、セカンダリとしてのみグループに参加できます。 この方法では、1 つのグループのみが存在し、各サーバーインスタンスがグループから削除され、アップグレードされてグループに再度参加します。

この方法は、単一プライマリグループに適しています。 グループがシングルプライマリモードで動作しているときに、プライマリを全体で同じにしておく必要がある場合 (アップグレードされる場合を除く)、アップグレードされる最後のメンバーである必要があります。 プライマリは、グループ内で最も低い MySQL Server バージョンを実行していないかぎり、プライマリとして残すことはできません。 プライマリがアップグレードされた後、group_replication_set_as_primary() UDF を使用してプライマリとして再サポートできます。 どのメンバーがプライマリであるかわからない場合は、任意の順序でメンバーをアップグレードできます。 グループは、セクション18.1.3.1「シングルプライマリモード」 で説明されている選択ポリシーに従って、MySQL Server の最低バージョンを実行しているメンバーの中から必要に応じて新しいプライマリを選択します。

マルチプライマリモードで動作するグループの場合、ローリングアップグレード中にプライマリの数が減り、書込み可用性が低下します。 これは、既存のグループメンバーが実行されている最下位バージョンより上位の MySQL Server バージョンを実行している場合、メンバーがグループに参加すると、自動的に読取り専用モード (super_read_only=ON) のままになるためです。 MySQL 8.0.17 以上を実行しているメンバーは、これをチェックするときにリリースのパッチバージョンを考慮しますが、MySQL 8.0.16 以下または MySQL 5.7 を実行しているメンバーはメジャーバージョンのみを考慮します。 すべてのメンバーが MySQL 8.0.17 から同じリリースにアップグレードされると、読取り/書込みモードに自動的に戻ります。 以前のリリースでは、アップグレード後にプライマリとして機能する必要がある各メンバーで super_read_only=OFF を手動で設定する必要があります。

グループ内のバージョンの互換性、およびこれがアップグレードプロセス中にグループの動作に与える影響の詳細は、セクション18.7.1「グループ内の異なるメンバーバージョンの組合せ」 を参照してください。

ローリング移行のアップグレード

この方法では、グループからメンバーを削除し、アップグレードしたメンバーを使用して別のグループを作成します。 マルチプライマリモードで動作するグループの場合、このプロセス中にプライマリの数が減り、書込み可用性が低下します。 これは、シングルプライマリモードで動作するグループには影響しません。

古いバージョンを実行しているグループは、メンバーのアップグレード中にオンラインであるため、メンバーのアップグレード中に実行されたトランザクションを捕捉するには、新しいバージョンを実行しているグループが必要です。 したがって、新しいグループ内のいずれかのサーバーは、古いグループのプライマリのレプリカとして構成されます。 これにより、新しいグループが古いグループに追いつくようになります。 この方法は、あるグループから別のグループへのデータのレプリケートに使用される非同期レプリケーションチャネルに依存するため、非同期ソースレプリケーションレプリケーションと同じ前提および要件でサポートされます。第17章「レプリケーション」 を参照してください。 シングルプライマリモードで動作するグループの場合、古いグループへの非同期レプリケーション接続では、新しいグループのプライマリにデータを送信する必要があります。マルチプライマリグループの場合、非同期レプリケーションチャネルは任意のプライマリに接続できます。

プロセスは次のとおりです:

• 古いサーバーバージョンを実行している元のグループからメンバーを削除します。セクション18.7.3.2「グループレプリケーションメンバーのアップグレード」 を参照してください

• メンバーで実行されているサーバーバージョンをアップグレードします。セクション2.11「MySQL のアップグレード」 を参照してください。 インプレースまたはプロビジョニングのアプローチに従ってアップグレードできます。

• アップグレードしたメンバーで新しいグループを作成します。第18章「グループレプリケーション」 を参照してください。 この場合、(古いグループがまだ実行中で古い名前を使用しているため) 各メンバーに新しいグループ名を構成し、最初にアップグレードしたメンバーをブートストラップしてから、残りのアップグレード済メンバーを追加する必要があります。

• 古いグループと新しいグループの間に非同期レプリケーションチャネルを設定します。セクション17.1.3.4「GTID を使用したレプリケーションのセットアップ」 を参照してください。 古いプライマリが非同期レプリケーションソースサーバーとして機能し、新しいグループメンバーが GTID ベースのレプリカとして機能するように構成します。

アプリケーションを新しいグループにリダイレクトする前に、グループがメンバーの障害を処理できるように、新しいグループに適切な数のメンバーがあることを確認する必要があります。 SELECT * FROM performance_schema.replication_group_members を発行し、初期グループサイズと新しいグループサイズを比較します。 古いグループのすべてのデータが新しいグループに伝播されるまで待機してから、非同期レプリケーション接続を削除し、欠落しているメンバーをアップグレードします。

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

この方法では、新しいバージョンを実行しているメンバーで構成される別のグループを作成し、古いグループから欠落しているデータは新しいグループにレプリケートされます。 これは、両方のグループを同時に実行するのに十分なサーバーがあることを前提としています。 このプロセス中にプライマリの数が減少しないため、マルチプライマリモードで動作するグループの場合、書込み可用性は低下しません。 これにより、ローリングアップグレードはマルチプライマリモードで動作するグループに適しています。 これは、シングルプライマリモードで動作するグループには影響しません。

新しいグループのメンバーをプロビジョニングしている間、古いバージョンを実行しているグループはオンラインであるため、メンバーのプロビジョニング中に実行されたトランザクションを捕捉するには、新しいバージョンを実行しているグループが必要です。 したがって、新しいグループ内のいずれかのサーバーは、古いグループのプライマリのレプリカとして構成されます。 これにより、新しいグループが古いグループに追いつくようになります。 この方法は、あるグループから別のグループへのデータのレプリケートに使用される非同期レプリケーションチャネルに依存するため、非同期ソースレプリケーションレプリケーションと同じ前提および要件でサポートされます。第17章「レプリケーション」 を参照してください。 シングルプライマリモードで動作するグループの場合、古いグループへの非同期レプリケーション接続では、新しいグループのプライマリにデータを送信する必要があります。マルチプライマリグループの場合、非同期レプリケーションチャネルは任意のプライマリに接続できます。

プロセスは次のとおりです:

• 新しいバージョンを実行しているグループがメンバーの障害を処理できるように、適切な数のメンバーをデプロイ

• グループのメンバーから既存のデータのバックアップを取得

• 古いメンバーのバックアップを使用して、新しいグループのメンバーをプロビジョニングします。方法については、セクション18.7.3.4「mysqlbackup を使用したグループレプリケーションアップグレード」 を参照してください。

  注記

  バックアップは、バックアップ元と同じバージョンの MySQL にリストアしてから、インプレースアップグレードを実行する必要があります。 その手順は、セクション2.11「MySQL のアップグレード」を参照してください。

• アップグレードしたメンバーで新しいグループを作成します。第18章「グループレプリケーション」 を参照してください。 この場合、(古いグループがまだ実行中で古い名前を使用しているため) 各メンバーに新しいグループ名を構成し、最初にアップグレードしたメンバーをブートストラップしてから、残りのアップグレード済メンバーを追加する必要があります。

• 古いグループと新しいグループの間に非同期レプリケーションチャネルを設定します。セクション17.1.3.4「GTID を使用したレプリケーションのセットアップ」 を参照してください。 古いプライマリが非同期レプリケーションソースサーバーとして機能し、新しいグループメンバーが GTID ベースのレプリカとして機能するように構成します。

新しいグループから欠落している進行中のデータが、迅速に転送できるほど小さい場合は、書込み操作を新しいグループにリダイレクトする必要があります。 古いグループのすべてのデータが新しいグループに伝播されるまで待機してから、非同期レプリケーション接続を削除します。