GTID は、ソースとレプリカ間のデータフローを開始、停止、または再開するためのポイントを決定するために以前に必要だったファイルオフセットペアを置き換えます。 GTID が使用されている場合、レプリカがソースと同期するために必要なすべての情報は、レプリケーションデータストリームから直接取得されます。

GTID ベースのレプリケーションを使用してレプリカを開始するには、CHANGE REPLICATION SOURCE TO ステートメント (MySQL 8.0.23 から) または CHANGE MASTER TO ステートメント (MySQL 8.0.23 より前) で SOURCE_AUTO_POSITION | MASTER_AUTO_POSITION オプションを有効にする必要があります。 代替の SOURCE_LOG_FILE | MASTER_LOG_FILE および SOURCE_LOG_POS | MASTER_LOG_POS オプションでは、ログファイルの名前とファイル内の開始位置を指定しますが、GTID ではレプリカにこの非ローカルデータは必要ありません。 GTID ベースのレプリケーションを使用してソースおよびレプリカを構成および起動する完全な手順については、セクション17.1.3.4「GTID を使用したレプリケーションのセットアップ」 を参照してください。

SOURCE_AUTO_POSITION | MASTER_AUTO_POSITION オプションはデフォルトで無効になっています。 レプリカでマルチソースレプリケーションが有効になっている場合は、該当するレプリケーションチャネルごとにオプションを設定する必要があります。 SOURCE_AUTO_POSITION | MASTER_AUTO_POSITION オプションを再度無効にすると、レプリカはファイルベースレプリケーションに戻ります。この場合、SOURCE_LOG_FILE | MASTER_LOG_FILE または SOURCE_LOG_POS | MASTER_LOG_POS オプションのいずれかまたは両方も指定する必要があります。

レプリカで GTID が有効 (GTID_MODE=ON、ON_PERMISSIVE,または OFF_PERMISSIVE) で MASTER_AUTO_POSITION オプションが有効になっている場合、ソースへの接続に対して自動配置がアクティブ化されます。 接続を成功させるには、ソースに GTID_MODE=ON が設定されている必要があります。 初期ハンドシェークでは、レプリカは、すでに受信、コミット、またはその両方を行ったトランザクションを含む GTID セットを送信します。 この GTID セットは、gtid_executed システム変数 (@@GLOBAL.gtid_executed) 内の GTID のセットの結合、および受信したトランザクションとしてパフォーマンススキーマ replication_connection_status テーブルに記録された GTID のセット (SELECT RECEIVED_TRANSACTION_SET FROM PERFORMANCE_SCHEMA.replication_connection_status ステートメントの結果) と等しくなります。

ソースは、GTID がレプリカによって送信される GTID セットに含まれていないバイナリログに記録されたすべてのトランザクションを送信することによって応答します。 これを行うには、ソースはまず、各バイナリログファイルのヘッダーにある Previous_gtids_log_event を最新のものからチェックして、作業を開始する適切なバイナリログファイルを識別します。 ソースは、レプリカが欠落しているトランザクションを含まない最初の Previous_gtids_log_event を検出すると、そのバイナリログファイルから始まります。 この方法は効率的で、大量のバイナリログファイルによってレプリカがソースの背後にある場合にのみかなりの時間がかかります。 次に、ソースはそのバイナリログファイル内のトランザクションとそれ以降のファイルを現在のファイルまで読み取り、レプリカが欠落している GTID を含むトランザクションを送信し、レプリカによって送信された GTID セット内のトランザクションをスキップします。 レプリカが最初に欠落しているトランザクションを受信するまでの経過時間は、バイナリログファイル内のオフセットによって異なります。 この交換により、レプリカがまだ受信またはコミットしていない GTID を持つトランザクションのみがソースから送信されるようになります。 ダイヤモンドトポロジの場合と同様に、レプリカが複数のソースからトランザクションを受信する場合、自動スキップ機能によってトランザクションが 2 回適用されないようにします。

ソースによって送信されるべきトランザクションのいずれかがソースバイナリログからパージされているか、別の方法で gtid_purged システム変数の GTID セットに追加されている場合、ソースはエラー ER_MASTER_HAS_PURGED_REQUIRED_GTIDS をレプリカに送信し、レプリケーションは開始しません。 欠落しているパージ済トランザクションの GTID が識別され、警告メッセージ ER_FOUND_MISSING_GTIDS のソースエラーログにリストされます。 ソースのキャッチアップに必要なトランザクション履歴の一部がパージされているため、レプリカはこのエラーから自動的にリカバリできません。 MASTER_AUTO_POSITION オプションを有効にせずに再接続しようとすると、レプリカ上のパージされたトランザクションが失われます。 この状況からリカバリする正しいアプローチは、レプリカが ER_FOUND_MISSING_GTIDS メッセージにリストされている欠落トランザクションを別のソースからレプリケートするか、レプリカをより新しいバックアップから作成された新しいレプリカに置き換えることです。 状況が再度発生しないように、ソースでバイナリログの有効期限 (binlog_expire_logs_seconds) を変更することを検討してください。

トランザクションの交換中に、GTID 内のソース UUID を持つトランザクションをレプリカが受信またはコミットしたが、ソース自体にそれらのレコードがないことが判明した場合、ソースはレプリカにエラー ER_SLAVE_HAS_MORE_GTIDS_THAN_MASTER を送信し、レプリケーションは開始しません。 この状況は、sync_binlog=1 セットを持たないソースで電源障害またはオペレーティングシステムクラッシュが発生し、まだバイナリログファイルに同期されていないがレプリカによって受信されたコミット済トランザクションが失われた場合に発生する可能性があります。 再起動後にクライアントがソースでトランザクションをコミットすると、ソースとレプリカが相違する可能性があります。これは、ソースとレプリカが異なるトランザクションに同じ GTID を使用している状況につながる可能性があります。 この状況からリカバリする正しい方法は、ソースとレプリカが相違しているかどうかを手動で確認することです。 同じ GTID が異なるトランザクションに使用されている場合は、必要に応じて個々のトランザクションに対して手動による競合解決を実行するか、レプリケーショントポロジからソースまたはレプリカを削除する必要があります。 問題がソースで欠落しているトランザクションのみである場合は、かわりにソースをレプリカにし、レプリケーショントポロジ内の他のサーバーで捕捉できるようにしてから、必要に応じて再度ソースにすることができます。

ダイヤモンドトポロジ内のマルチソースレプリカ (レプリカが複数のソースからレプリケートされ、共通ソースからレプリケートされる) の場合、GTID ベースのレプリケーションが使用されているときは、マルチソースレプリカ上のすべてのチャネルでレプリケーションフィルタまたはその他のチャネル構成が同一であることを確認してください。 GTID ベースのレプリケーションでは、フィルタはトランザクションデータにのみ適用され、GTID はフィルタで除外されません。 これは、レプリカの GTID セットがソースと一貫性が保たれるようにするためです。つまり、毎回フィルタで除外されたトランザクションを再取得せずに GTID 自動配置を使用できます。 ダウンストリームレプリカがマルチソースで、ダイアモンドトポロジの複数のソースから同じトランザクションを受信する場合、ダウンストリームレプリカには複数のバージョンのトランザクションが含まれるようになり、結果はトランザクションを最初に適用するチャネルによって異なります。 トランザクションの GTID が最初のチャネルによって gtid_executed セットに追加されたため、GTID 自動スキップを使用してトランザクションをスキップしようとする 2 つ目のチャネル。 チャネルのフィルタリングが同一の場合、トランザクションのすべてのバージョンに同じデータが含まれているため、結果は同じであるため、問題はありません。 ただし、チャネルのフィルタリングが異なると、データベースに一貫性がなくなる可能性があり、レプリケーションがハングする可能性があります。