GTID 取代了以前用于确定开始、停止或恢复源和副本之间数据流的点所需的文件偏移量对。使用 GTID 时，副本与源同步所需的所有信息都直接从复制数据流中获取。

要使用基于 GTID 的复制启动副本，您不要在用于指示副本从给定源复制的语句中包含MASTER_LOG_FILE或 MASTER_LOG_POS选项 。CHANGE MASTER TO这些选项指定日志文件的名称和文件中的起始位置，但使用 GTID，副本不需要此非本地数据。相反，您需要启用该 MASTER_AUTO_POSITION选项。有关使用基于 GTID 的复制配置和启动源和副本的完整说明，请参阅 第 16.1.3.4 节，“使用 GTID 设置复制”。

MASTER_AUTO_POSITION默认情况下禁用 该选项。如果在副本上启用了多源复制，则需要为每个适用的复制通道设置选项。再次禁用该MASTER_AUTO_POSITION 选项会使副本恢复为基于文件的复制，在这种情况下，您还必须指定一个或两个 MASTER_LOG_FILE选项 MASTER_LOG_POS。

当副本启用 GTID（GTID_MODE=ON或 ON_PERMISSIVE,） OFF_PERMISSIVE并 MASTER_AUTO_POSITION启用该选项时，将激活自动定位以连接到源。必须GTID_MODE=ON设置源才能使连接成功。在初始握手中，副本发送一个 GTID 集，其中包含它已经接收、提交或两者都包含的事务。这个 GTID 集合等于 gtid_executed系统变量 ( ) 中的 GTID 集合和作为接收事务 @@GLOBAL.gtid_executed记录在 Performance Schema 表中的 GTID 集合的并集（语句的结果）。 replication_connection_statusSELECT RECEIVED_TRANSACTION_SET FROM PERFORMANCE_SCHEMA.replication_connection_status

源通过发送记录在其二进制日志中的所有事务来响应，这些事务的 GTID 不包含在副本发送的 GTID 集中。为此，源首先通过检查 Previous_gtids_log_event每个二进制日志文件的标头（从最新的开始）来确定要开始使用的适当的二进制日志文件。当源找到第一个Previous_gtids_log_event 它不包含副本丢失的事务，它从那个二进制日志文件开始。如果副本落后于源大量二进制日志文件，则此方法非常有效并且只需要花费大量时间。然后，源读取该二进制日志文件和后续文件中的事务，直到当前文件，发送带有副本丢失的 GTID 的事务，并跳过副本发送的 GTID 集中的事务。副本收到第一个丢失的事务之前经过的时间取决于它在二进制日志文件中的偏移量。此交换确保源仅发送具有副本尚未接收或提交的 GTID 的事务。

如果应由源发送的任何事务已从源的二进制日志中清除，或已gtid_purged通过其他方法添加到系统变量中的 GTID 集，则源将错误发送 ER_MASTER_HAS_PURGED_REQUIRED_GTIDS 到副本，并且复制不会开始. 丢失的清除事务的 GTID 被识别并列在警告消息的源错误日志中 ER_FOUND_MISSING_GTIDS。副本无法从此错误中自动恢复，因为赶上源所需的部分事务历史记录已被清除。尝试重新连接而不 MASTER_AUTO_POSITION选项启用只会导致副本上清除的事务丢失。从这种情况中恢复的正确方法是让副本 ER_FOUND_MISSING_GTIDS从另一个来源复制消息中列出的缺失事务，或者用从更新的备份创建的新副本替换副本。考虑修改source上的binary log过期时间，确保情况不会再次发生。

如果在事务交换期间发现副本已经接收或提交了 GTID 中源的 UUID 的事务，但源本身没有它们的记录，则源向 ER_SLAVE_HAS_MORE_GTIDS_THAN_MASTER 副本发送错误并且复制不会开始. 如果源没有 sync_binlog=1set 遇到电源故障或操作系统崩溃，并丢失尚未同步到二进制日志文件但已被副本接收的已提交事务。如果任何客户端在源重新启动后在源上提交事务，则源和副本可能会发生分歧，这可能导致源和副本对不同事务使用相同的 GTID 的情况。从这种情况中恢复的正确方法是手动检查源和副本是否已经分离。如果相同的 GTID 现在用于不同的事务，则您需要根据需要为各个事务执行手动冲突解决，或者从复制拓扑中删除源或副本。