#### 17.1.3.3 GTID自动定位

[](<>)

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

要使用基于GTID的复制启动复制副本，需要启用`震源自动位置`\|`主自动位置`中的选项[`将复制源更改为`](change-replication-source-to.html)语句（来自MySQL 8.0.23）或[`将主机更改为`](change-master-to.html)语句（MySQL 8.0.23之前）。替代方案`源日志文件`\|`主日志文件`和`来源_日志_位置`\|`主日志位置`选项指定日志文件的名称和文件中的起始位置，但使用GTID复制副本不需要此非本地数据。。有关使用基于GTID的复制配置和启动源和副本的完整说明，请参阅[第17.1.3.4节，“使用GTID设置复制”](replication-gtids-howto.html).

这个`震源自动位置`\|`主自动位置`默认情况下，选项处于禁用状态。如果在复制副本上启用了多源复制，则需要为每个适用的复制通道设置选项。禁用`震源自动位置`\|`主自动位置`选项再次使复制副本恢复为基于文件的复制，在这种情况下，还必须指定一个或两个选项`源日志文件` \| `主日志文件`或`来源_日志_位置` \| `主日志位置`选项。

当副本启用了GTID时([`GTID_模式=开启`](replication-options-gtids.html#sysvar_gtid_mode), `在允许的情况下，`或`不允许的`)还有`主自动位置`启用选项后，将激活自动定位以连接到源。消息来源肯定有[`GTID_模式=开启`](replication-options-gtids.html#sysvar_gtid_mode)设置以使连接成功。在初始握手中，复制副本发送一个GTID集，其中包含它已经接收、提交或同时提交的事务。此GTID集等于中GTID集的并集[`gtid_已执行`](replication-options-gtids.html#sysvar_gtid_executed)系统变量(`@@全球。gtid_已执行`)，以及性能模式中记录的GTID集[`复制\u连接\u状态`](performance-schema-replication-connection-status-table.html)表A收到的交易记录（报表结果）`从性能模式中选择已接收的事务集。复制\u连接\u状态`).

源通过发送二进制日志中记录的所有事务进行响应，这些事务的GTID不包括在副本发送的GTID集中。为此，源代码首先通过检查`上一次_gtids_log_事件`在每个二进制日志文件的头中，从最新的开始。当源找到第一个`上一次_gtids_log_事件`它不包含复制副本丢失的事务，它从该二进制日志文件开始。这种方法是有效的，并且仅当复制副本在源后面有大量二进制日志文件时，才会占用大量时间。然后，源读取该二进制日志文件中的事务以及当前文件之前的后续文件，发送带有复制副本丢失的GTID的事务，并跳过复制副本发送的GTID集中的事务。复制副本收到第一个丢失事务之前所用的时间取决于其在二进制日志文件中的偏移量。此交换可确保源仅发送副本尚未接收或提交的带有GTID的事务。如果复制副本从多个源接收事务（如菱形拓扑），自动跳过功能将确保不会应用两次事务。

如果源应发送的任何事务已从源的二进制日志中清除，或添加到[`gtid_`](replication-options-gtids.html#sysvar_gtid_purged)系统变量通过另一种方法，源发送错误[`ER_MASTER_已清除_所需的_GTID`](https://dev.mysql.com/doc/mysql-errors/8.0/en/server-error-reference.html#error_er_master_has_purged_required_gtids)复制到复制副本，复制不会启动。丢失的已清除事务的GTID已识别，并在警告消息中的源错误日志中列出[`呃，你找到了失踪的证件`](https://dev.mysql.com/doc/mysql-errors/8.0/en/server-error-reference.html#error_er_found_missing_gtids)。复制副本无法从该错误中自动恢复，因为追上源所需的部分事务历史记录已被清除。正在尝试在没有`主自动位置`启用选项只会导致复制副本上清除的事务丢失。从这种情况恢复的正确方法是复制副本复制中列出的丢失事务[`ER\u发现\u缺少GTID`](https://dev.mysql.com/doc/mysql-errors/8.0/en/server-error-reference.html#error_er_found_missing_gtids)来自另一个源的消息，或将副本替换为从最近备份创建的新副本。考虑修改二进制日志过期期([`binlog\u过期\u日志\u秒`](replication-options-binary-log.html#sysvar_binlog_expire_logs_seconds))在来源上确保情况不会再次发生。

如果在事务交换期间发现复制副本已接收到或提交了GTID中源的UUID事务，但源本身没有记录，则源发送错误[`ER_USlave_U拥有的GTID比\u MASTER多`](https://dev.mysql.com/doc/mysql-errors/8.0/en/server-error-reference.html#error_er_slave_has_more_gtids_than_master)到复制副本和复制未启动。如果没有[`同步\u binlog=1`](replication-options-binary-log.html#sysvar_sync_binlog)set会遇到电源故障或操作系统崩溃，并且丢失尚未同步到二进制日志文件但已被副本接收的提交事务。如果任何客户端在源上提交事务，则源和副本在重新启动后可能会发生分歧，这可能导致源和副本在不同事务中使用相同的GTID。从这种情况中恢复的正确方法是手动检查源和副本是否已偏离。如果同一GTID现在用于不同的事务，则需要根据需要对单个事务执行手动冲突解决，或者从复制拓扑中删除源或副本。如果问题只是源上缺少事务，那么可以将源改为复制副本，允许它与复制拓扑中的其他服务器同步，然后在需要时再次将其作为源。

对于菱形拓扑中的多源副本（其中副本从两个或多个源复制，然后从公共源复制），在使用基于GTID的复制时，确保多源副本上的所有通道上的任何复制筛选器或其他通道配置相同。使用基于GTID的复制，筛选器仅应用于事务数据，GTID不会被筛选出。这样做是为了使副本的GTID集与源的一致，这意味着可以使用GTID自动定位，而不必每次重新获取筛选出的事务。如果下游副本是多源的，并且从菱形拓扑中的多个源接收相同的事务，则下游副本现在具有多个事务版本，结果取决于哪个通道首先应用事务。第二个尝试使用GTID自动跳过事务的通道，因为事务的GTID已添加到[`gtid\u已执行`](replication-options-gtids.html#sysvar_gtid_executed)由第一个频道设置。在通道上进行相同的筛选，没有问题，因为事务的所有版本都包含相同的数据，因此结果是相同的。但是，在通道上进行不同的过滤后，数据库可能会变得不一致，复制可能挂起。
