グループレプリケーションには、次の既知の制限事項があります。 マルチプライマリモードグループについて説明されている制限事項と問題は、フェイルオーバーイベント中にシングルプライマリモードクラスタにも適用できますが、新しく選択されたプライマリは古いプライマリからアプライヤキューをフラッシュします。
グループレプリケーションは GTID ベースのレプリケーション上に構築されるため、セクション17.1.3.7「GTID ベースレプリケーションの制約」 にも注意する必要があります。
--upgrade=MINIMALオプション. レプリケーション内部が依存するシステムテーブルをアップグレードしない MINIMAL オプション (--upgrade=MINIMAL) を使用する MySQL Server のアップグレード後は、グループレプリケーションを開始できません。-
ギャップロック. ギャップロックに関する情報は
InnoDBの外部では使用できないため、同時トランザクションのグループレプリケーション動作保証プロセスでは gap locks は考慮されません。 詳しくはギャップロックをご覧ください。注記マルチプライマリモードのグループの場合、アプリケーションで
REPEATABLE READセマンティクスに依存しないかぎり、グループレプリケーションでREAD COMMITTED分離レベルを使用することをお薦めします。 InnoDB では、READ COMMITTEDのギャップロックは使用されません。これにより、InnoDB 内のローカル競合検出が、グループレプリケーションによって実行される分散競合検出に位置合せされます。 シングルプライマリモードのグループの場合、プライマリのみが書込みを受け入れるため、READ COMMITTED分離レベルはグループレプリケーションにとって重要ではありません。 テーブルロックおよび名前付きロック. 証明プロセスでは、テーブルロック (セクション13.3.6「LOCK TABLES および UNLOCK TABLES ステートメント」 を参照) または名前付きロック (
GET_LOCK()を参照) は考慮されません。-
バイナリログチェックサム. MySQL 8.0.20 まで、グループレプリケーションはチェックサムを使用できず、バイナリログでのチェックサムの存在をサポートしないため、サーバーインスタンスがグループメンバーになるように構成するときに
binlog_checksum=NONEを設定する必要があります。 MySQL 8.0.21 からは、グループレプリケーションでチェックサムがサポートされるため、グループメンバーはデフォルト設定のbinlog_checksum=CRC32を使用できます。binlog_checksumの設定は、グループのすべてのメンバーで同じである必要はありません。チェックサムが使用可能な場合、Group Replication はそれらを使用して
group_replication_applierチャネル上の着信イベントを検証しません。これは、イベントが複数のソースからそのリレーログに書き込まれ、実際に元のサーバーのバイナリログに書き込まれる前 (チェックサムが生成されるとき) であるためです。 チェックサムは、group_replication_recoveryチャネルおよびグループメンバー上の他のレプリケーションチャネルでイベントの整合性を検証するために使用されます。 SERIALIZABLE 分離レベル.
SERIALIZABLE分離レベルは、マルチプライマリグループではデフォルトでサポートされていません。 トランザクション分離レベルをSERIALIZABLEに設定すると、トランザクションのコミットを拒否するようにグループレプリケーションが構成されます。同時 DDL 操作と DML 操作. マルチプライマリモードを使用している場合、同じオブジェクトに対して実行されるが異なるサーバーで実行される同時データ定義ステートメントおよびデータ操作ステートメントはサポートされません。 オブジェクトに対するデータ定義言語 (DDL) ステートメントの実行中に、同じオブジェクトで異なるサーバーインスタンスで同時データ操作言語 (DML) を実行すると、異なるインスタンスで競合する DDL が検出されないリスクがあります。
-
カスケード制約のある外部キー. マルチプライマリモードグループ (すべて
group_replication_single_primary_mode=OFFで構成されたメンバー) は、マルチレベルの外部キー依存性を持つテーブル (特にCASCADINGforeign key constraints を定義したテーブル) をサポートしていません。 これは、マルチプライマリモードグループによってカスケード操作が実行される外部キー制約により、競合が検出されず、グループのメンバー間でデータの一貫性がなくなる可能性があるためです。 したがって、検出されない競合を回避するために、マルチプライマリモードグループで使用されるサーバーインスタンスにgroup_replication_enforce_update_everywhere_checks=ONを設定することをお薦めします。シングルプライマリモードでは、グループの複数のメンバーへの同時書込みが許可されないため、これは問題ではありません。したがって、検出されない競合のリスクはありません。
マルチプライマリモードのデッドロック. グループがマルチプライマリモードで動作している場合、
SELECT .. FOR UPDATEステートメントによってデッドロックが発生する可能性があります。 これは、ロックがグループのメンバー間で共有されていないため、このようなステートメントの期待に到達しない可能性があるためです。レプリケーションフィルタ. グループレプリケーション用に構成された MySQL サーバーインスタンスでは、グローバルレプリケーションフィルタを使用できません。これは、一部のサーバーでトランザクションをフィルタすると、グループが一貫性のある状態で承諾に到達できなくなるためです。 グループメンバーがグループ外のソースへのレプリカとしても機能する場合など、グループレプリケーションに直接関与しないレプリケーションチャネルでチャネル固有のレプリケーションフィルタを使用できます。
group_replication_applierまたはgroup_replication_recoveryチャネルでは使用できません。-
暗号化接続. TLSv1.3 プロトコルのサポートは、MySQL 8.0.16 の MySQL Server で使用できます (MySQL が OpenSSL 1.1.1 以上を使用してコンパイルされている場合)。 MySQL 8.0.16 および MySQL 8.0.17 では、サーバーが TLSv1.3 をサポートしている場合、プロトコルはグループ通信エンジンではサポートされず、Group Replication では使用できません。 グループレプリケーションでは、MySQL 8.0.18 からの TLSv1.3 がサポートされており、グループ通信接続および分散リカバリ接続に使用できます。
MySQL 8.0.18 では、TLSv1.3 を分散リカバリ接続のグループレプリケーションで使用できますが、
group_replication_recovery_tls_versionおよびgroup_replication_recovery_tls_ciphersuitesシステム変数は使用できません。 したがって、ドナーサーバーでは、セクション6.3.2「暗号化された接続 TLS プロトコルおよび暗号」 にリストされているように、デフォルトで有効になっている TLSv1.3 暗号スイートを少なくとも 1 つ使用できる必要があります。 MySQL 8.0.19 から、オプションを使用して、必要に応じてデフォルト以外の暗号スイートのみを含む任意の暗号スイートのクライアントサポートを構成できます。 クローニング操作. グループレプリケーションは分散リカバリのクローニング操作を開始および管理しますが、クローニングをサポートするように設定されているグループメンバーは、ユーザーが手動で開始するクローニング操作にも関与する場合があります。 MySQL 8.0.20 より前のリリースでは、操作にグループレプリケーションが実行されているグループメンバーが含まれる場合、クローニング操作を手動で開始することはできません。 クローニング操作で受信者のデータが削除および置換されない場合は、MySQL 8.0.20 からこれを実行できます。 したがって、Group Replication が実行されている場合は、クローニング操作を開始するステートメントに
DATA DIRECTORY句を含める必要があります。 セクション18.4.3.2.4「その他の目的でのクローニング」を参照してください。
単一のレプリケーショングループのメンバーにできる MySQL サーバーの最大数は 9 です。 さらにメンバーがグループに参加しようとすると、そのリクエストは拒否されます。 この制限は、安定したローカルエリアネットワーク上でグループが確実に実行される安全な境界としてのテストおよびベンチマークから特定されています。
個々のトランザクションの結果、5 秒以内にメッセージをネットワーク上のグループメンバー間でコピーできない十分な大きさのメッセージコンテンツが生成された場合、メンバーはトランザクションの処理にビジー状態であるため、失敗した疑いがあります。 また、トランザクションが大きいと、メモリー割当ての問題が原因でシステムが遅くなる可能性があります。 これらの問題を回避するには、次の軽減策を使用します:
大量のメッセージが原因で不要な削除が発生した場合は、システム変数
group_replication_member_expel_timeoutを使用して、失敗した疑いがあるメンバーが削除されるまでの追加時間を許可します。 疑わしいメンバーがグループから削除されるまで、最初の 5 秒間の検出期間の 1 時間以内に許可できます。 MySQL 8.0.21 からは、デフォルトで追加の 5 秒が許可されます。可能な場合は、グループレプリケーションによって処理される前に、トランザクションのサイズを試行して制限してください。 たとえば、
LOAD DATAで使用されるファイルを小さいチャンクに分割します。システム変数
group_replication_transaction_size_limitを使用して、グループが受け入れる最大トランザクションサイズを指定します。 MySQL 8.0 では、このシステム変数はデフォルトで 150000000 バイト (約 143 MB) の最大トランザクションサイズに設定されます。 このサイズを超えるトランザクションはロールバックされ、グループへの配布のために Group Replication Group Communication System (GCS) に送信されません。 トランザクションの処理にかかる時間はそのサイズに比例することに注意して、グループが許容する必要がある最大メッセージサイズに応じて、この変数の値を調整します。システム変数
group_replication_compression_thresholdを使用して、圧縮が適用されるメッセージサイズを指定します。 このシステム変数のデフォルトは 1000000 バイト (1 MB) であるため、大きなメッセージは自動的に圧縮されます。 圧縮は、group_replication_transaction_size_limit設定で許可されたがgroup_replication_compression_threshold設定を超えたメッセージを受信したときに、Group Replication Group Communication System (GCS) によって実行されます。 詳細は、セクション18.6.3「メッセージ圧縮」を参照してください。システム変数
group_replication_communication_max_message_sizeを使用して、メッセージが断片化されるメッセージサイズを指定します。 このシステム変数のデフォルトは 10485760 バイト (10 MiB) であるため、大きなメッセージは自動的に断片化されます。 GCS は、圧縮されたメッセージがgroup_replication_communication_max_message_size制限を超えたままである場合、圧縮後に断片化を実行します。 レプリケーショングループで断片化を使用するには、すべてのグループメンバーが MySQL 8.0.16 以上であり、グループで使用されている Group Replication 通信プロトコルバージョンで断片化が許可されている必要があります。 詳細は、セクション18.6.4「メッセージの断片化」を参照してください。
関連するシステム変数にゼロ値を指定すると、最大トランザクションサイズ、メッセージ圧縮およびメッセージの断片化をすべて非アクティブ化できます。 これらすべての保護を非アクティブ化した場合、レプリケーショングループのメンバーの適用者スレッドで処理できるメッセージの上限サイズは、デフォルト値および最大値 1073741824 バイト (1 GB) のメンバー slave_max_allowed_packet システム変数の値です。 この制限を超えるメッセージは、受信側メンバーが処理しようとすると失敗します。 グループメンバーが送信できるメッセージの上限サイズは 4294967295 バイト (約 4 GB) です。 これは、GCS が処理した後にメッセージを受信するグループレプリケーション (XCom、Paxos バリアント) のためにグループ通信エンジンによって受け入れられるパケットサイズの強い制限です。 この制限を超えるメッセージは、元のメンバーがブロードキャストしようとすると失敗します。