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

要使用基于 GTID 的复制启动副本，您需要启用SOURCE_AUTO_POSITION| MASTER_AUTO_POSITION语句中的选项 CHANGE REPLICATION SOURCE TO （来自 MySQL 8.0.23）或CHANGE MASTER TO语句（MySQL 8.0.23 之前）。替代品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系统变量 ( ) 中的 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 expiration period ( binlog_expire_logs_seconds) 确保情况不会再次发生。

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

对于菱形拓扑中的多源副本（其中副本从两个或多个源复制，而这些源又从公共源复制），当使用基于 GTID 的复制时，确保任何复制过滤器或其他通道配置是在多源副本上的所有通道上都相同。使用基于 GTID 的复制，过滤器仅应用于事务数据，而不会过滤掉 GTID。发生这种情况是为了使副本的 GTID 集与源的保持一致，这意味着可以使用 GTID 自动定位而无需每次都重新获取过滤掉的事务。在下游副本是多源并且从菱形拓扑中的多个源接收相同事务的情况下，下游副本现在有多个版本的事务，结果取决于哪个通道先应用事务。第二个尝试使用 GTID auto-skip 跳过事务的通道，因为事务的 GTID 被添加到gtid_executed由第一个通道设置。在通道上进行相同的过滤，没有问题，因为交易的所有版本都包含相同的数据，所以结果是相同的。但是，如果对通道进行不同的过滤，数据库可能会变得不一致并且复制可能会挂起。