InnoDB ストレージエンジン.  データは、InnoDB トランザクションストレージエンジンに格納する必要があります。 トランザクションはオプティミスティックに実行され、コミット時に競合がないかチェックされます。 競合がある場合、グループ間の一貫性を維持するために、一部のトランザクションがロールバックされます。 つまり、トランザクションストレージエンジンが必要です。 さらに、InnoDB には、グループレプリケーションと連携して動作する場合の競合の管理および処理を向上させる追加機能がいくつか用意されています。 一時的な MEMORY ストレージエンジンを含むほかのストレージエンジンを使用すると、Group Replication でエラーが発生する可能性があります。 グループメンバーに disabled_storage_engines システム変数を設定することで、ほかのストレージエンジンの使用を防止できます。次に例を示します:

disabled_storage_engines="MyISAM,BLACKHOLE,FEDERATED,ARCHIVE,MEMORY"

主キー.  グループによってレプリケートされるすべてのテーブルには、定義済の主キー、または同等の主キー (同等のものが NULL 以外の一意キー) が必要です。 このようなキーは、テーブル内のすべての行の一意の識別子として必要です。これにより、各トランザクションが変更された行を正確に識別することで、競合するトランザクションをシステムで判別できます。 Group Replication には、主キーまたは主キーに相当するチェックの独自の組込みセットがあり、sql_require_primary_key システム変数によって実行されるチェックは使用されません。 Group Replication が実行されているサーバーインスタンスに対して sql_require_primary_key=ON を設定でき、Group Replication チャネルに対して CHANGE REPLICATION SOURCE TO|CHANGE MASTER TO ステートメントの REQUIRE_TABLE_PRIMARY_KEY_CHECK オプションを ON に設定できます。 ただし、グループレプリケーションの組込みチェックで許可されている一部のトランザクションは、sql_require_primary_key=ON または REQUIRE_TABLE_PRIMARY_KEY_CHECK=ON の設定時に実行されるチェックでは許可されない場合があることに注意してください。

ネットワークパフォーマンス.  MySQL Group Replication は、サーバーインスタンスが相互に非常に近いクラスタ環境にデプロイされるように設計されています。 グループのパフォーマンスと安定性は、ネットワーク待機時間とネットワーク帯域幅の両方の影響を受ける可能性があります。 双方向通信は、すべてのグループメンバー間で常に維持する必要があります。 インバウンド通信またはアウトバウンド通信のいずれかがサーバーインスタンスでブロックされている場合 (ファイアウォールや接続の問題など)、メンバーはグループ内で機能できず、グループメンバー (問題のあるメンバーを含む) は影響を受けるサーバーインスタンスの正しいメンバーステータスをレポートできない可能性があります。

MySQL 8.0.14 からは、リモートグループレプリケーションサーバー間の TCP 通信に IPv4 または IPv6 ネットワークインフラストラクチャを使用することも、これらの組合せを使用することもできます。 また、グループレプリケーションが仮想プライベートネットワーク (VPN) 上で動作しなくなることもありません。

また、グループレプリケーションサーバーインスタンスが同じ場所に配置され、ローカルグループ通信エンジン (XCom) インスタンスを共有する MySQL 8.0.14 から、TCP ソケットではなく可能なかぎり、通信にオーバーヘッドの低い専用の入力チャネルが使用されます。 グループへの参加など、リモートの XCom インスタンス間の通信を必要とする特定のグループレプリケーションタスクでは、TCP ネットワークが引き続き使用されるため、ネットワークパフォーマンスがグループのパフォーマンスに影響します。

一意のサーバー識別子.  レプリケーショントポロジのすべてのサーバーで必要に応じて、server_id システム変数を使用して一意のサーバー ID でサーバーを構成します。 サーバー ID は、1 から (2 ³²)−1 までの正の整数である必要があり、レプリケーショントポロジ内の他のサーバーで使用されている他のすべてのサーバー ID とは異なる必要があります。

バイナリログアクティブ.  --log-bin[=log_file_name]を設定します。 MySQL Group Replication はバイナリログの内容をレプリケートするため、バイナリログを操作するにはバイナリログがオンになっている必要があります。 このオプションはデフォルトで有効となっています。 セクション5.4.4「バイナリログ」を参照してください。

記録されたレプリカ更新.  --log-slave-updates を設定します。 このオプションはデフォルトで有効となっています。 グループメンバーは、参加時にドナーから受信し、レプリケーションアプライアンスを介して適用されるトランザクションをログに記録し、グループから受信して適用するすべてのトランザクションをログに記録する必要があります。 これにより、グループレプリケーションは、既存のグループメンバーバイナリログから状態転送による分散リカバリを実行できます。

バイナリログ行の形式.  --binlog-format=row を設定します。 グループレプリケーションは、行ベースのレプリケーション形式に依存して、グループ内のサーバー間で一貫して変更を伝播します。 グループ内の異なるサーバーで同時に実行されるトランザクション間の競合を検出するために必要な情報を抽出できるように、行ベースのインフラストラクチャに依存します。 MySQL 8.0.19 から、REQUIRE_ROW_FORMAT 設定がグループレプリケーションチャネルに自動的に追加され、トランザクションの適用時に行ベースのレプリケーションの使用が強制されます。 セクション17.2.1「レプリケーション形式」 および セクション17.3.3「レプリケーション権限チェック」 を参照してください。

バイナリログチェックサムオフ (MySQL 8.0.20).  MySQL 8.0.20 まで、およびそれを含めて、--binlog-checksum=NONE を設定します。 これらのリリースでは、Group Replication はチェックサムを使用できず、バイナリログ内でのチェックサムの存在をサポートしていません。 MySQL 8.0.21 からは、グループレプリケーションでチェックサムがサポートされるため、グループメンバーはデフォルト設定を使用できます。

グローバルトランザクション識別子オン.  gtid_mode=ON および enforce_gtid_consistency=ON を設定します。 グループレプリケーションでは、グローバルトランザクション識別子を使用して、すべてのサーバーインスタンスでコミットされたトランザクションを正確に追跡するため、すでにコミットされているトランザクションと競合する可能性のあるトランザクションを実行したサーバーを推測できます。 つまり、明示的なトランザクション識別子は、競合する可能性のあるトランザクションを判別できるフレームワークの基本的な部分です。 セクション17.1.3「グローバルトランザクション識別子を使用したレプリケーション」を参照してください。

レプリケーション情報リポジトリ.  master_info_repository=TABLE および relay_log_info_repository=TABLE を設定します。 MySQL 8.0 では、この設定はデフォルトであり、FILE 設定は非推奨です。 MySQL 8.0.23 では、これらのシステム変数の使用は非推奨であるため、システム変数を省略してデフォルトをそのまま使用します。 Group Replication プラグインがレプリケーションメタデータの一貫したリカバリ可能性とトランザクション管理を持つように、レプリケーションアプライアンスは mysql.slave_master_info および mysql.slave_relay_log_info システムテーブルにレプリケーションメタデータを書き込む必要があります。 セクション17.2.4.2「レプリケーションメタデータリポジトリ」を参照してください。

トランザクション書込みセット抽出.  行を収集してバイナリログに記録するときに、サーバーが書き込みセットも収集するように --transaction-write-set-extraction=XXHASH64 を設定します。 書込みセットは各行の主キーに基づいており、変更された行を一意に識別するタグの簡略化されたコンパクトなビューです。 このタグは、競合の検出に使用されます。 このオプションはデフォルトで有効となっています。

バイナリログの依存性トラッキング.  binlog_transaction_dependency_tracking=WRITESET_SESSION を設定すると、グループワークロードに応じて、グループメンバーのパフォーマンスを向上させることができます。 Group Replication は、binlog_transaction_dependency_tracking に設定された値とは関係なく、リレーログからトランザクションを適用するときに、証明後に独自のパラレル化を実行します。 ただし、binlog_transaction_dependency_tracking の値は、グループレプリケーションメンバーのバイナリログへのトランザクションの書込み方法に影響します。 これらのログ内の依存関係情報は、メンバーがグループに参加または再参加するたびに発生する分散リカバリのドナーバイナリログからの状態転送プロセスを支援するために使用されます。

デフォルトのテーブル暗号化.  すべてのグループメンバーで --default-table-encryption を同じ値に設定します。 デフォルトのスキーマおよびテーブルスペースの暗号化は、設定がすべてのメンバーで同じであるかぎり、有効 (ON) または無効 (OFF、デフォルト) のいずれかにできます。

小文字のテーブル名.  すべてのグループメンバーで --lower-case-table-names を同じ値に設定します。 グループレプリケーションに必要な InnoDB ストレージエンジンを使用するには、1 の設定が適切です。 この設定は、すべてのプラットフォームでデフォルトであるわけではありません。

マルチスレッドアプライアンス.  グループレプリケーションメンバーはマルチスレッドレプリカとして構成できるため、トランザクションをパラレルに適用できます。 slave_parallel_workers にゼロ以外の値を指定すると、メンバーのマルチスレッドアプライアンスが有効になり、最大 1024 のパラレルアプライヤスレッドを指定できます。 slave_preserve_commit_order=1 を設定すると、パラレルトランザクションの最終コミットは、グループレプリケーションに必要な元のトランザクションと同じ順序で行われます。これは、すべての参加メンバーがコミットされたトランザクションを同じ順序で受信および適用することを保証するために構築された一貫性メカニズムに依存します。 最後に、レプリカでパラレルに実行できるトランザクションを決定するために使用されるポリシーを指定する slave_parallel_type=LOGICAL_CLOCK の設定が、slave_preserve_commit_order=1 で必要です。 slave_parallel_workers=0 を設定すると、パラレル実行が無効になり、レプリカに単一のアプライヤスレッドが付与され、コーディネータスレッドは付与されません。 この設定では、slave_parallel_type および slave_preserve_commit_order オプションは効果がなく、無視されます。