このページは機械翻訳したものです。

17.1.3.6 GTID のないソースから GTID のあるレプリカへのレプリケーション

MySQL 8.0.23 から、GTID がまだないレプリケートされたトランザクションに GTID を割り当てるようにレプリケーションチャネルを設定できます。 この機能により、GTID が有効になっておらず GTID ベースのレプリケーションを使用しないソースサーバーから GTID が有効になっているレプリカへのレプリケーションが可能になります。 セクション17.1.4「オンラインサーバーでの GTID モードの変更」 で説明されているように、レプリケーションソースサーバーで GTID を有効にできる場合は、代わりにそのアプローチを使用します。 この機能は、GTID を有効にできないレプリケーションソースサーバー用に設計されています。

CHANGE REPLICATION SOURCE TO ステートメントの ASSIGN_GTIDS_TO_ANONYMOUS_TRANSACTIONS オプションを使用して、レプリケーションチャネルで GTID 割当てを有効にできます。 LOCAL は、レプリカ独自の UUID (server_uuid 設定) を含む GTID を割り当てます。uuid は、レプリケーションソースサーバーの server_uuid 設定など、指定された UUID を含む GTID を割り当てます。 非ローカル UUID を使用すると、レプリカで発生したトランザクションと、ソースで発生したトランザクション、およびマルチソースレプリカの場合は異なるソースで発生したトランザクションを区別できます。 ソースによって送信されたトランザクションのいずれかに GTID がすでにある場合、その GTID は保持されます。

重要

フェイルオーバーが必要な場合、どのチャネルでも ASSIGN_GTIDS_TO_ANONYMOUS_TRANSACTIONS を使用して設定されたレプリカを昇格させてレプリケーションサーバーを置き換えることはできず、レプリカから作成されたバックアップを使用してレプリケーションサーバーをリストアすることはできません。 同じ制限が、任意のチャネルで ASSIGN_GTIDS_TO_ANONYMOUS_TRANSACTIONS を使用する他のレプリカの置換またはリストアにも適用されます。

レプリカには gtid_mode=ON セットが必要であり、後で変更することはできません。 GTID を有効にせずにレプリカサーバーを起動し、レプリケーションチャネルに ASSIGN_GTIDS_TO_ANONYMOUS_TRANSACTIONS を設定した場合、設定は変更されませんが、状況の変更方法を説明する警告メッセージがエラーログに書き込まれます。

マルチソースレプリカの場合、ASSIGN_GTIDS_TO_ANONYMOUS_TRANSACTIONS を使用するチャネルと使用しないチャネルを混在させることができます。 Group Replication に固有のチャネルでは ASSIGN_GTIDS_TO_ANONYMOUS_TRANSACTIONS を使用できませんが、Group Replication グループメンバーであるサーバーインスタンス上の別のソースの非同期レプリケーションチャネルでは使用できます。 Group Replication グループメンバー上のチャネルの場合、GTID を作成するための UUID として Group Replication グループ名を指定しないでください。

レプリケーションチャネルで ASSIGN_GTIDS_TO_ANONYMOUS_TRANSACTIONS を使用することは、チャネルに GTID ベースのレプリケーションを導入することとは異なります。 ASSIGN_GTIDS_TO_ANONYMOUS_TRANSACTIONS で設定されたレプリカセットから GTID セット (gtid_executed) を別のサーバーに転送したり、別のサーバー gtid_executed セットと比較したりしないでください。 匿名トランザクションに割り当てられている GTID と、それらに対して選択する UUID は、そのレプリカ独自の使用にのみ意味があります。

ASSIGN_GTIDS_TO_ANONYMOUS_TRANSACTIONS を使用するレプリケーションチャネルには、GTID ベースのレプリケーションと次の動作の違いがあります:

• GTID は、レプリケートされたトランザクションの適用時に割り当てられます (GTID がすでにある場合を除く)。 GTID は通常、トランザクションのコミット時にレプリケーションソースサーバーに割り当てられ、トランザクションとともにレプリカに送信されます。 マルチスレッドレプリカでは、これは GTID の順序が、slave-preserve-commit-order=1 が設定されている場合でもトランザクションの順序と一致しないことを意味します。

• MASTER_AUTO_POSITION オプションではなく、CHANGE REPLICATION SOURCE TO ステートメントの SOURCE_LOG_FILE および SOURCE_LOG_POS オプションを使用してレプリケーション I/O スレッドを配置します。

• SET GLOBAL sql_slave_skip_counter ステートメントは、CHANGE REPLICATION SOURCE TO ステートメントではなく、ASSIGN_GTIDS_TO_ANONYMOUS_TRANSACTIONS で設定されたレプリケーションチャネルでトランザクションをスキップするために使用されます。 その手順は、セクション17.1.7.3「トランザクションのスキップ」を参照してください。

• START REPLICA ステートメントの UNTIL SQL_BEFORE_GTIDS および UNTIL_SQL_AFTER_GTIDS オプションは、チャネルには使用できません。

• MySQL 8.0.18 から非推奨になった関数 WAIT_UNTIL_SQL_THREAD_AFTER_GTIDS() は、チャネルでは使用できません。 サーバー全体で動作する交換用の WAIT_FOR_EXECUTED_GTID_SET() を使用できます。

「パフォーマンススキーマ」テーブル replication_applier_configuration は、GTID がレプリケーションチャネル上の匿名トランザクションに割り当てられているかどうか、UUID とは何か、およびそれがレプリカサーバー (LOCAL) とユーザー指定 UUID (MANUAL) のどちらであるかを示します。 この情報は、アプライヤメタデータリポジトリにも記録されます。 RESET SLAVE ALL ステートメントは ASSIGN_GTIDS_TO_ANONYMOUS_TRANSACTIONS 設定をリセットしますが、RESET SLAVE ステートメントはリセットしません。