Group Replication は、Group Replication プラグインがバンドルされている MySQL Server のバージョンに従ってバージョン管理されます。 たとえば、メンバーが MySQL 5.7.26 を実行している場合、これは Group Replication プラグインのバージョンです。 グループメンバーの MySQL Server のバージョンを確認するには、次のコマンドを発行します:
SELECT MEMBER_HOST,MEMBER_PORT,MEMBER_VERSION FROM performance_schema.replication_group_members;
+-------------+-------------+----------------+
| member_host | member_port | member_version |
+-------------+-------------+----------------+
| example.com | 3306 | 8.0.13 |
+-------------+-------------+----------------+MySQL Server のバージョンの理解およびバージョンの選択に関するガイダンスは、セクション2.1.2「インストールする MySQL のバージョンと配布の選択」 を参照してください。
最適な互換性とパフォーマンスを得るには、グループのすべてのメンバーが同じバージョンの MySQL Server を実行する必要があるため、グループレプリケーションを実行する必要があります。 ただし、オンライングループのアップグレード中は、可用性を最大化するために、異なる MySQL Server バージョンのメンバーを同時に実行する必要がある場合があります。 MySQL のバージョン間で行われた変更によっては、この状況で非互換性が発生する可能性があります。 たとえば、メジャーバージョン間で機能が非推奨になっている場合、グループ内のバージョンを組み合せると、非推奨機能に依存するメンバーで障害が発生する可能性があります。 逆に、古い MySQL バージョンを実行しているグループに読取り/書込みメンバーが存在する間に、新しい MySQL バージョンを実行しているメンバーに書き込むと、新しいリリースで導入された関数がないメンバーで問題が発生する可能性があります。
これらの問題を回避するために、グループレプリケーションには、同じグループ内で異なるバージョンの MySQL を実行しているメンバーを安全に結合できる互換性ポリシーが含まれています。 メンバーはこれらのポリシーを適用して、グループに通常参加するか、読取り専用モードで参加するか、またはグループに参加しないかを決定します。どちらを選択すると、参加メンバーおよびグループの既存のメンバーの安全な操作が行われます。 アップグレードシナリオでは、各サーバーはグループを離れてアップグレードし、新しいサーバーバージョンでグループに再度参加する必要があります。 この時点で、メンバーは新しいサーバーバージョンにポリシーを適用します。これは、最初にグループに参加したときに適用したポリシーから変更された可能性があります。
管理者は、サーバーを適切に構成して START GROUP_REPLICATION ステートメントを発行することで、任意のグループへの参加を試行するようにサーバーに指示できます。 グループに参加するかどうか、または読取り専用モードでグループに参加するかどうかは、グループにメンバーを追加しようとした後に結合メンバー自体によって決定および実装されます。 参加メンバーは、現在のグループメンバーの MySQL Server バージョンに関する情報を受け取り、それらのメンバーとの独自の互換性を評価して、互換性があるかどうかを判断するために (既存のメンバーで使用されるポリシーではなく) 独自の MySQL Server バージョンで使用されるポリシーを適用します。
グループに参加しようとしたときに参加メンバーが適用される互換性ポリシーは次のとおりです:
既存のグループメンバーが実行されている最下位バージョンより下位の MySQL Server バージョンを実行している場合、メンバーはグループに参加しません。
メンバーは、既存のグループメンバーが実行されている最下位バージョンと同じ MySQL Server バージョンを実行している場合、通常、グループに参加します。
メンバーはグループに参加しますが、既存のグループメンバーが実行されている最下位バージョンより上位の MySQL Server バージョンを実行している場合、読取り専用モードのままです。 この動作は、グループがマルチプライマリモードで実行されている場合にのみ異なります。これは、シングルプライマリモードで実行されているグループでは、新しく追加されたメンバーはデフォルトで読取り専用になるためです。
MySQL 8.0.17 以上を実行しているメンバーは、互換性をチェックするときにリリースのパッチバージョンを考慮します。 MySQL 8.0.16 以下または MySQL 5.7 を実行しているメンバーには、メジャーバージョンのみが考慮されます。 たとえば、すべてのメンバーが MySQL バージョン 8.0.13 を実行しているグループがある場合は、次のようにします:
MySQL バージョン 5.7 を実行しているメンバーは結合されません。
MySQL 8.0.16 を実行しているメンバーは正常に結合されます (メジャーバージョンを考慮しているため)。
MySQL 8.0.17 を実行しているメンバーは結合されますが、読取り専用モードのままです (パッチバージョンが考慮されるため)。
MySQL 5.7.27 より前のリリースを実行しているメンバーを結合すると、すべてのグループメンバーがチェックされ、独自の MySQL Server メジャーバージョンが低いかどうかが確認されます。 したがって、いずれかのメンバーが MySQL 8.0 リリースを実行しているグループに対してこのチェックが失敗し、MySQL 5.7 を実行している他のメンバーがすでに存在する場合でもグループに参加できません。 MySQL 5.7.27 から、メンバーを結合すると、最下位メジャーバージョンを実行しているグループメンバーのみがチェックされるため、他の MySQL 5.7 サーバーが存在する混合バージョングループに参加できます。
異なる MySQL Server バージョンを使用するメンバーを持つマルチプライマリモードグループでは、グループレプリケーションは、MySQL 8.0.17 以上を実行しているメンバーの読取り/書込みおよび読取り専用ステータスを自動的に管理します。 メンバーがグループから離れると、現在最も低いバージョンを実行しているメンバーは自動的に読取り/書込みモードに設定されます。 シングルプライマリモードで実行されていたグループをマルチプライマリモードで実行するように変更すると、group_replication_switch_to_multi_primary_mode() UDF を使用して、グループレプリケーションによって自動的にメンバーが正しいモードに設定されます。 メンバーは、グループに存在する最低バージョンより上位の MySQL サーバーバージョンを実行しており、最低バージョンを実行しているメンバーが読取り/書込みモードになっている場合、自動的に読取り専用モードになります。