GTID ベースレプリケーションはトランザクションに依存しているため、そうでなければ MySQL で使用できるいくつかの機能が、それを使用するときにサポートされません。 このセクションでは、GTID ベースレプリケーションの制約と制限についての情報を提供します。

非トランザクションストレージエンジンに関係する更新.  GTID を使用する場合、MyISAM などの非トランザクションストレージエンジンを使用するテーブルへの更新は、InnoDB などのトランザクションストレージエンジンを使用するテーブルへの更新と同じステートメントまたはトランザクションで実行できません。

この制約は、非トランザクションストレージエンジンを使用するテーブルへの更新とトランザクションストレージエンジンを使用するテーブルへの更新が、同じトランザクション内に混在していると、複数の GTID が同じトランザクションに割り当てられる可能性があるためです。

このような問題は、一方のストレージエンジンがトランザクショナルで、もう一方がトランザクショナルでない場合に、ソースとレプリカがそれぞれのバージョンの同じテーブルに対して異なるストレージエンジンを使用している場合にも発生することがあります。 また、非トランザクションテーブルで動作するように定義されているトリガーが、これらの問題の原因になる可能性があることにも注意してください。

今挙げたいずれの場合も、トランザクションと GTID との間の 1 対 1 対応が壊れていて、GTID ベースレプリケーションは正しく機能できません。

CREATE TABLE ... SELECT ステートメント.  MySQL 8.0.21 より前では、GTID ベースのレプリケーションを使用する場合、CREATE TABLE ... SELECT ステートメントは許可されません。 binlog_format が STATEMENT に設定されている場合、CREATE TABLE ... SELECT ステートメントはバイナリログに 1 つの GTID を持つ 1 つのトランザクションとして記録されますが、ROW 形式が使用されている場合、ステートメントは 2 つの GTID を持つ 2 つのトランザクションとして記録されます。 ソースが STATEMENT 形式を使用し、レプリカが ROW 形式を使用した場合、レプリカはトランザクションを正しく処理できないため、GTID で CREATE TABLE ... SELECT ステートメントを使用してこのシナリオを回避することはできません。 この制限は、アトミック DDL をサポートするストレージエンジン上の MySQL 8.0.21 で解除されています。 この場合、CREATE TABLE ... SELECT はバイナリログに 1 つのトランザクションとして記録されます。 詳細は、セクション13.1.1「アトミックデータ定義ステートメントのサポート」を参照してください。

一時テーブル.  binlog_format が STATEMENT に設定されている場合、GTID がサーバーで使用されているとき (enforce_gtid_consistency システム変数が ON に設定されているとき) は、トランザクション、プロシージャ、関数およびトリガー内で CREATE TEMPORARY TABLE および DROP TEMPORARY TABLE ステートメントを使用できません。 GTID が使用されている場合、autocommit=1 が設定されていれば、これらのコンテキストの外部で使用できます。 MySQL 8.0.13 から、binlog_format が ROW または MIXED に設定されている場合、GTID が使用されているときに、CREATE TEMPORARY TABLE および DROP TEMPORARY TABLE ステートメントをトランザクション、プロシージャ、関数またはトリガー内で使用できます。 ステートメントはバイナリログに書き込まれないため、複製に複製されません。 行ベースのレプリケーションを使用することは、一時テーブルをレプリケートする必要なく、レプリカの同期が維持されることを意味します。 トランザクションからこれらのステートメントを削除した結果、空のトランザクションが発生した場合、そのトランザクションはバイナリログに書き込まれません。

サポートされないステートメントの実行の回避.  GTID ベースのレプリケーションが失敗する原因となるステートメントの実行を防ぐには、GTID を有効にするときに --enforce-gtid-consistency オプションを使用してすべてのサーバーを起動する必要があります。 これにより、このセクションですでに説明したタイプのステートメントはエラーで失敗します。

--enforce-gtid-consistency が有効になるのは、ステートメントに対してバイナリロギングが行われる場合だけです。 バイナリロギングがサーバーで無効になっている場合、またはステートメントがフィルタによって削除されたためにバイナリログに書き込まれない場合、GTID の整合性は、ログに記録されていないステートメントに対してチェックまたは適用されません。

GTID を有効にするときに必要なほかの起動オプションについては、セクション17.1.3.4「GTID を使用したレプリケーションのセットアップ」を参照してください。

トランザクションのスキップ.  GTID ベースのレプリケーションを使用している場合、sql_slave_skip_counter は使用できません。 トランザクションをスキップする必要がある場合は、かわりにソース gtid_executed 変数の値を使用します。 CHANGE REPLICATION SOURCE TO ステートメントの ASSIGN_GTIDS_TO_ANONYMOUS_TRANSACTIONS オプションを使用してレプリケーションチャネルで GTID 割当てを有効にした場合、sql_slave_skip_counter を使用できます。 詳細は、セクション17.1.7.3「トランザクションのスキップ」を参照してください。

サーバーの無視.  GTID を使用している場合、CHANGE REPLICATION SOURCE TO | CHANGE MASTER TO ステートメントの「The IGNORE_SERVER_IDS」オプションは非推奨です。すでに適用されているトランザクションは自動的に無視されるためです。 GTID ベースのレプリケーションを開始する前に、関係するサーバーで以前に設定されたすべての無視されたサーバー ID リストを確認してクリアします。 個々のチャネルに対して発行できる SHOW REPLICA | SLAVE STATUS ステートメントには、無視されたサーバー ID のリストが表示されます (存在する場合)。 リストがない場合、Replicate_Ignore_Server_Ids フィールドは空白です。

GTID モードと mysql_upgrade.  MySQL 8.0.16 より前では、グローバルトランザクション識別子 (GTID) を有効にして (gtid_mode=ON) サーバーを実行している場合、mysql_upgrade (--write-binlog オプション) によるバイナリロギングを有効にしないでください。 MySQL 8.0.16 の時点では、サーバーは MySQL アップグレード手順全体を実行しますが、アップグレード中はバイナリロギングを無効にするため、問題はありません。