GTIDベースのコピーは、初期化フェーズでは、スレーブノードは、受信されたとGTIDは、マスターノードに提出された情報を設定します。これはGTID、@@ GLOBAL.gtid_executed + performance_schema.replication_connection_status.RECEIVED_TRANSACTION_SET二組の背後にあるユニオンセットGTIDに相当します。
GTIDスレーブノードに設定情報を比較することにより、マスタノードによって送信され、その後、既存のバイナリ・ログ・ファイル内のすべてのレコード、ノードがスレーブに送信し、セットGTIDスレーブノード上で実行されていません。
だから、マスターノードスレーブノード比較はGTIDは、情報の収集から送信された方法ですか？
マスターノードは、いくつかの主題独自のUUIDによると、分類の設定GTIDますが同様のGTIDコレクションのセットの差異を算出しました。UUIDに自分自身よりもGTID UUIDカテゴリ、タイプのセットと、よりによって送られたマスターノードスレーブノードの発見は、マスターノードがケースを無視する場合は、このリンクは、ロジックが続行されますコピーします。
下記の具体例として、このような状況は、通常のレプリケーションです。
マスターノード上の情報の収集GTID：
[[email protected]] [DB1]>ショーのマスターステータス\ G
*************************** 1行******************** *******
ファイル：bin.000002
ポジション：796
Binlog_Do_DB：
Binlog_Ignore_DB：
Executed_Gtid_Set：0c34233d-b2e1-11e9-85cf-080027f22add：1-2、
4fdc13e1-b59e-11e9-b5e0-080027f22add：1-2
セット内の1行（0.01秒）
スレーブ・ノード上の情報の収集GTID：
[[email protected]] [LG]>ショーのマスターステータス\ G
*************************** 1行******************** *******
ファイル：bin.000004
ポジション：832
Binlog_Do_DB：
Binlog_Ignore_DB：
Executed_Gtid_Set：32a0c858-b59f-11e9-b069-0800270c3d91：1-2、
447e96e1-b59f-11e9-95fe-0800270c3d91：1-2、
b8282f18-b59e-11e9-83b0-0800270c3d91：1-5
セット内の1行（0.00秒）
レプリケーション関係が確立された後、スレーブ・ノード上の情報の収集：
[[email protected]] [LG]>ショーのマスターステータス\ G
*************************** 1行******************** *******
ファイル：bin.000004
ポジション：1763
Binlog_Do_DB：
Binlog_Ignore_DB：
Executed_Gtid_Set：0c34233d-b2e1-11e9-85cf-080027f22add：1-2、
32a0c858-b59f-11e9-b069-0800270c3d91：1-2、
447e96e1-b59f-11e9-95fe-0800270c3d91：1-2、
4fdc13e1-b59e-11e9-b5e0-080027f22add：1-2、
b8282f18-b59e-11e9-83b0-0800270c3d91：1-5
セット内の1行（0.00秒）
ノードは、同じUUIDマスタースレーブGTIDに対応するノード自体よりGTIDを発見した場合、ノードは、スレーブノード・エラーにER_SLAVE_HAS_MORE_GTIDS_THAN_MASTERマスターを送信します。
具体例を以下に挙げます：
Last_IO_Errno：1236（MySQLエラーコード1236（ER_MASTER_FATAL_ERROR_READING_BINLOG）：マスターから取得した致命的なエラー％dのバイナリログからデータを読み出す： '％ - 320S'）
Last_IO_Error：「スレーブは、マスタのSERVER_UUIDを使用して、マスターが持っているよりも多くのGTIDsを持っていますバイナリログからデータを読み取る際に、マスターから致命的なエラー1236を手に入れました。これは！= 1をsync_binlog時にマスターがまたはすでに複製されたトランザクションをロールバックされていない可能性があり、電源やディスク障害が発生した後、例えば、バイナリログの末尾が切り捨てられたことや、最後のバイナリログファイルが失われたことを示してもよいです"
Last_SQL_Errno：0
マスタノード発見や濃度差が同じUUIDのGTIDセットを計算し、GTIDが削除されたが、その後、マスターノードはエラーER_MASTER_HAS_PURGED_REQUIRED_GTIDSスレーブノードを送信します。
具体例を以下に挙げます：
Last_IO_Errno 1236
Last_IO_Error：バイナリログからデータを読み出すときにマスタから致命的なエラー1236得た：「スレーブMASTER_AUTO_POSITION = 1に変更マスタを使用して接続されているが、マスタはスレーブが必要GTIDsを含むバイナリログをパージしました。」
Last_SQL_Errno：0
上記のロジックの後、そして最終的に我々はGTIDのコレクションを介して送信する必要がマスターノードのノードをスレーブにできた、その方法を開始したコピー。