オンラインアップグレード手順中に、グループがシングルプライマリモードの場合、アップグレード用に現在オフラインになっていないすべてのサーバーは、以前と同様に機能します。 グループは、セクション18.1.3.1「シングルプライマリモード」 で説明されている選択ポリシーに従って、必要に応じて新しいプライマリを選択します。 プライマリを全体で同じに保つ必要がある場合 (アップグレード時を除く)、最初にすべてのセカンダリをターゲットプライマリメンバーバージョン以上のバージョンにアップグレードしてから、プライマリを最後にアップグレードする必要があります。 プライマリは、グループ内で最も低い MySQL Server バージョンを実行していないかぎり、プライマリとして残すことはできません。 プライマリがアップグレードされた後、group_replication_set_as_primary() UDF を使用してプライマリとして再サポートできます。

グループがマルチプライマリモードの場合、アップグレードされたメンバーはアップグレード後に読取り専用モードで結合されるため、アップグレード手順中に書込みを実行できるオンラインメンバーは少なくなります。 MySQL 8.0.17 から、これはパッチバージョン間のアップグレードに適用され、以前のリリースではメジャーバージョン間のアップグレードにのみ適用されます。 すべてのメンバーが MySQL 8.0.17 から同じリリースにアップグレードされると、読取り/書込みモードに自動的に戻ります。 以前のリリースでは、アップグレード後にプライマリとして機能する各メンバーで、super_read_only を OFF に手動で設定する必要があります。

アップグレードをロールバックする必要がある場合や緊急時にグループに容量を追加する必要がある場合など、問題の状況に対処するために、他のグループメンバーが使用している最低バージョンより低い MySQL Server バージョンを実行していても、メンバーがオンライングループに参加できるようにすることができます。 Group Replication システム変数 group_replication_allow_local_lower_version_join は、このような状況で通常の互換性ポリシーをオーバーライドするために使用できます。 オプションを ON に設定しても、新しいメンバーはグループと互換性がなく、既存のメンバーによる互換性のない動作から保護せずにグループに参加できることに注意してください。 したがって、このオプションは特定の状況でのみ慎重に使用する必要があり、通常のグループアクティビティが原因で新しいメンバーが失敗しないように、追加の注意事項を講じる必要があります。 これらの注意事項の詳細は、group_replication_allow_local_lower_version_join の説明を参照してください。