マルチプライマリモード (group_replication_single_primary_mode=OFF) では、メンバーに特別なロールはありません。 他のグループメンバーと互換性のあるメンバーは、グループへの参加時に読取り/書込みモードに設定され、同時に発行された場合でも書込みトランザクションを処理できます。
たとえば、予期しないサーバーの終了時に書込みトランザクションの受入れを停止したメンバーに接続されているクライアントは、読取り/書込みモードの他のメンバーにリダイレクトまたはフェイルオーバーできます。 グループレプリケーションはクライアント側フェイルオーバー自体を処理しないため、MySQL Router 8.0、プロキシ、コネクタまたはアプリケーション自体などのミドルウェアフレームワークを使用してこれを調整する必要があります。図18.5「クライアントフェイルオーバー」 は、メンバーがグループを離れた場合に、クライアントが代替グループメンバーに再接続する方法を示します。
グループレプリケーションは、最終的な一貫性システムです。 つまり、受信トラフィックの速度が低下または停止するとすぐに、すべてのグループメンバーのデータコンテンツが同じになります。 トラフィックが流れている間、特に一部のメンバーの書込みスループットが他のメンバーより低い場合、トランザクションを他のメンバーの前に外部化でき、失効した読取りの可能性があります。 マルチプライマリモードでは、低速なメンバーがトランザクションの過剰なバックログを構築して認証および適用することもでき、競合および証明の失敗のリスクが高くなります。 これらの問題を制限するには、グループレプリケーションのフロー制御メカニズムをアクティブ化およびチューニングして、高速メンバーと低速メンバーの違いを最小限に抑えることができます。 フロー制御の詳細は、セクション18.6.2「フロー制御」 を参照してください。
MySQL 8.0.14 から、グループ内のすべてのトランザクションに対してトランザクションの一貫性を保証する場合は、group_replication_consistency システム変数を使用してこれを実行できます。 一貫性の向上に必要な同期のパフォーマンスへの影響を考慮して、グループのワークロードおよびデータの読取りおよび書込みの優先度に適した設定を選択できます。 また、個々のセッションのシステム変数を設定して、特に同時実行に注意の必要なトランザクションを保護することもできます。 トランザクションの一貫性の詳細は、セクション18.4.2「トランザクション一貫性保証」 を参照してください。
グループがマルチプライマリモードでデプロイされている場合、トランザクションはモードと互換性があることを確認するためにチェックされます。 グループレプリケーションがマルチプライマリモードでデプロイされると、次の厳密な整合性チェックが行われます:
SERIALIZABLE 分離レベルでトランザクションが実行されると、トランザクション自体をグループと同期するときにコミットが失敗します。
カスケード制約を持つ外部キーを持つテーブルに対してトランザクションが実行される場合、トランザクション自体をグループと同期するとコミットは失敗します。
チェックは、group_replication_enforce_update_everywhere_checks システム変数によって制御されます。 マルチプライマリモードでは、システム変数は通常 ON に設定する必要がありますが、システム変数を OFF に設定することで、オプションでチェックを非アクティブ化できます。 シングルプライマリモードでデプロイする場合は、システム変数を OFF に設定する必要があります。
マルチプライマリモードのグループレプリケーショントポロジでは、一般にデータ定義言語 (DDL) とも呼ばれるデータ定義ステートメントの実行時に注意する必要があります。
MySQL 8.0 では、完全な DDL ステートメントが単一のアトミックトランザクションとしてコミットまたはロールバックされるアトミックデータ定義言語 (DDL) ステートメントのサポートが導入されています。 ただし、DDL ステートメント (アトミックまたはそれ以外) は、ステートメントを実行する前に COMMIT を実行したかのように、現在のセッションでアクティブなトランザクションを暗黙的に終了します。 つまり、DDL ステートメントは、別のトランザクション内、START TRANSACTION ... COMMIT などのトランザクション制御ステートメント内、または同じトランザクション内の他のステートメントと組み合せることはできません。
グループレプリケーションはオプティミスティックレプリケーションパラダイムに基づいており、必要に応じてステートメントがオプティミスティックに実行され、後でロールバックされます。 各サーバーは、最初にグループ承諾を保護せずに実行されます。 したがって、マルチプライマリモードで DDL ステートメントをレプリケートする場合は、より注意する必要があります。 (DDL を使用して) スキーマを変更し、同じオブジェクトに対してオブジェクトに含まれるデータを (DML を使用して) 変更する場合は、スキーマ操作がまだ完了しておらず、どこにもレプリケートされていない間に、同じサーバーを介して変更を処理する必要があります。 そうしないと、操作が中断されたとき、または部分的にしか完了しなかったときに、データの不整合が発生する可能性があります。 グループがシングルプライマリモードでデプロイされている場合、この問題は発生しません。これは、すべての変更が同じサーバー (プライマリ) を介して実行されるためです。
MySQL 8.0 でのアトミック DDL のサポート、および特定のステートメントのレプリケーションの動作の変更の詳細は、セクション13.1.1「アトミックデータ定義ステートメントのサポート」 を参照してください。
最適な互換性とパフォーマンスを得るには、グループのすべてのメンバーが同じバージョンの MySQL Server を実行する必要があるため、グループレプリケーションを実行する必要があります。 マルチプライマリモードでは、通常、すべてのメンバーが読取り/書込みモードでグループに参加するため、これはより重要です。 グループに複数の MySQL Server バージョンを実行しているメンバーが含まれている場合、一部のメンバーは他のメンバーがサポートしていないか、他のメンバーが持っている関数がないため、他のメンバーと互換性がない可能性があります。 これを防ぐために、新しいメンバー (アップグレードおよび再起動された以前のメンバーを含む) が参加すると、メンバーは残りのグループに対して互換性チェックを実行します。
これらの互換性チェックの結果の 1 つは、マルチプライマリモードで特に重要です。 参加メンバーが、既存のグループメンバーが実行されている最下位バージョンより上位の MySQL Server バージョンを実行している場合、そのメンバーはグループに参加しますが、読取り専用モードのままです。 (単一プライマリモードで実行されているグループでは、新しく追加されたメンバーは、いずれの場合も読取り専用にデフォルト設定されます。) MySQL 8.0.17 以上を実行しているメンバーは、互換性をチェックするときにリリースのパッチバージョンを考慮します。 MySQL 8.0.16 以下または MySQL 5.7 を実行しているメンバーには、メジャーバージョンのみが考慮されます。
異なる MySQL Server バージョンを使用するメンバーを持つマルチプライマリモードで実行されているグループでは、グループレプリケーションは、MySQL 8.0.17 以上を実行しているメンバーの読取り/書込みおよび読取り専用ステータスを自動的に管理します。 メンバーがグループから離れると、現在最も低いバージョンを実行しているメンバーは自動的に読取り/書込みモードに設定されます。 シングルプライマリモードで実行されていたグループをマルチプライマリモードで実行するように変更すると、group_replication_switch_to_multi_primary_mode() UDF を使用して、グループレプリケーションによって自動的にメンバーが正しいモードに設定されます。 メンバーは、グループに存在する最低バージョンより上位の MySQL サーバーバージョンを実行しており、最低バージョンを実行しているメンバーが読取り/書込みモードになっている場合、自動的に読取り専用モードになります。
グループ内のバージョンの互換性、およびこれがアップグレードプロセス中にグループの動作に与える影響の詳細は、セクション18.7.1「グループ内の異なるメンバーバージョンの組合せ」 を参照してください。