GTID 替换了以前确定开始、停止或恢复源和副本之间数据流的点所需的文件偏移对。在使用 GTID 时，副本与源同步所需的所有信息都直接从复制数据流中获取。
要使用基于 GTID 的复制启动副本，您需要启用SOURCE_AUTO_POSITION| 语句（来自 MySQL 8.0.23）或语句（在 MySQL 8.0.23 之前）MASTER_AUTO_POSITION中的选项 。替代方案| 和 | 选项指定日志文件的名称和文件中的起始位置，但使用 GTID 副本不需要此非本地数据。有关使用基于 GTID 的复制配置和启动源和副本的完整说明，请参阅 第 17.1.3.4 节，“使用 GTID 设置复制”。 CHANGE REPLICATION SOURCE TOCHANGE MASTER TOSOURCE_LOG_FILE``MASTER_LOG_FILE``SOURCE_LOG_POS``MASTER_LOG_POS
该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系统变量 ( ) 中的 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从另一个源复制消息中列出的缺失事务，或者将副本替换为从更新的备份创建的新副本。考虑修改源上的二进制日志过期时间（binlog_expire_logs_seconds），以确保这种情况不会再次发生。
如果在事务交换过程中发现副本已经接收或提交了 GTID 中具有源 UUID 的事务，但源本身没有它们的记录，则源将错误发送 ER_SLAVE_HAS_MORE_GTIDS_THAN_MASTER 到副本并且复制不会启动. 如果源没有 sync_binlog=1set 遇到电源故障或操作系统崩溃，并丢失尚未同步到二进制日志文件但已被副本接收的已提交事务。如果任何客户端在重新启动后在源上提交事务，则源和副本可能会发生分歧，这可能导致源和副本对不同事务使用相同的 GTID 的情况。从这种情况中恢复的正确方法是手动检查源和副本是否已经分歧。如果相同的 GTID 现在用于不同的事务，您需要根据需要为各个事务执行手动冲突解决，或者从复制拓扑中删除源或副本。
对于菱形拓扑中的多源副本（其中副本从两个或多个源复制，而后者又从公共源复制），当使用基于 GTID 的复制时，请确保任何复制过滤器或其他通道配置是在多源副本上的所有通道上相同。使用基于 GTID 的复制，过滤器仅应用于事务数据，而 GTID 不会被过滤掉。发生这种情况是为了使副本的 GTID 集与源的保持一致，这意味着可以使用 GTID 自动定位，而无需每次都重新获取过滤掉的事务。在下游副本是多源的并且在菱形拓扑中从多个源接收相同事务的情况下，下游副本现在有多个版本的事务，结果取决于哪个通道首先应用事务。尝试使用 GTID 自动跳过的第二个通道跳过事务，因为事务的 GTID 已添加到gtid_executed由第一个通道设置。在通道上进行相同的过滤，没有问题，因为所有版本的事务都包含相同的数据，所以结果是相同的。但是，如果对通道进行不同的过滤，数据库可能会变得不一致，并且复制可能会挂起。
