Documentation Home
MySQL 8.3 Reference Manual
Related Documentation Download this Manual
PDF (US Ltr) - 40.8Mb
PDF (A4) - 40.9Mb
Man Pages (TGZ) - 294.0Kb
Man Pages (Zip) - 409.0Kb
Info (Gzip) - 4.0Mb
Info (Zip) - 4.0Mb
Excerpts from this Manual

19.1.3.3 GTID 自动定位

GTID 取代了以前需要的文件偏移对,以确定源和副本之间的数据流的起点、停止点或恢复点。当 GTID 处于使用状态时,副本从复制数据流中获取所有需要的信息,以便与源同步。

要使用 GTID 基础复制启动副本,需要在 CHANGE REPLICATION SOURCE TO 语句中启用 SOURCE_AUTO_POSITION 选项。备选的 SOURCE_LOG_FILESOURCE_LOG_POS 选项指定日志文件的名称和起始位置,但使用 GTID 时,副本不需要这些非本地数据。有关使用 GTID 基础复制配置和启动源和副本的完整说明,请参见 第 19.1.3.4 节,“使用 GTID 设置复制”

默认情况下,SOURCE_AUTO_POSITION 选项处于禁用状态。如果在副本上启用了多源复制,则需要为每个适用的复制通道设置该选项。再次禁用 SOURCE_AUTO_POSITION 选项将导致副本恢复到基于文件的复制;这意味着,当 GTID_ONLY=ON 时,一些位置可能被标记为无效,在这种情况下,您还需要在禁用 SOURCE_AUTO_POSITION 时指定 SOURCE_LOG_FILESOURCE_LOG_POS

当副本启用了 GTID (GTID_MODE=ONON_PERMISSIVEOFF_PERMISSIVE) 并启用了 SOURCE_AUTO_POSITION 选项时,自动定位将激活连接到源。源必须将 GTID_MODE=ON 设置为 ON,以便连接成功。在初始握手机制中,副本发送一个 GTID 集合,包含它已经收到的、提交的或两者的交易。该 GTID 集合等于 gtid_executed 系统变量 (@@GLOBAL.gtid_executed) 和 Performance Schema replication_connection_status 表中记录的交易集(结果是语句 SELECT RECEIVED_TRANSACTION_SET FROM PERFORMANCE_SCHEMA.replication_connection_status)。

源响应发送所有记录在其二进制日志中的交易,GTID 不在副本发送的 GTID 集合中。为此,源首先通过检查每个二进制日志文件的头部中的 Previous_gtids_log_event,从最新的文件开始。源找到第一个 Previous_gtids_log_event,其中不包含副本缺少的交易,然后从该二进制日志文件开始。该方法效率高,只有在副本落后于源很多二进制日志文件时才需要很长时间。源然后读取该二进制日志文件和后续文件中的交易,发送副本缺少的交易,并跳过副本已经收到的交易。副本收到第一个缺少的交易的时间取决于它在二进制日志文件中的偏移量。该交换确保源只发送副本没有收到的交易。如果副本从多个源接收交易,如 diamond拓扑结构中,自动跳过函数确保交易不会被应用两次。

如果源服务器上的某些事务已经从二进制日志中清除,或者已经被添加到gtid_purged系统变量中通过其他方法,那么源服务器将错误ER_SOURCE_HAS_PURGED_REQUIRED_GTIDS发送到副本上,并且复制不会启动。缺失的purged事务的GTID将被识别并列在源服务器的错误日志中的警告消息ER_FOUND_MISSING_GTIDS中。副本无法自动从该错误中恢复,因为需要catch up的交易历史记录的一部分已经被清除。尝试重新连接而不启用SOURCE_AUTO_POSITION选项只会导致副本上缺失的交易。从该情况中恢复的正确方法是让副本从另一个源服务器上复制缺失的交易,或者用一个从最新备份创建的新副本来替换副本。考虑修改源服务器上的二进制日志过期期限(binlog_expire_logs_seconds)以确保这种情况不会再次发生。

如果在交易交换过程中发现副本已经收到或提交了源服务器的UUID在GTID中的交易,但源服务器本身没有记录,那么源服务器将错误ER_REPLICA_HAS_MORE_GTIDS_THAN_SOURCE发送到副本上,并且复制不会启动。这种情况可能发生在源服务器没有设置sync_binlog=1的情况下,发生电源故障或操作系统崩溃,导致提交的交易没有同步到二进制日志文件,但已经被副本接收到了。源服务器和副本可能会分歧,如果在源服务器重新启动后客户端提交交易,这可能会导致源服务器和副本使用相同的GTID进行不同的交易。从该情况中恢复的正确方法是手动检查源服务器和副本是否已经分歧。如果相同的GTID现在用于不同的交易,那么您需要手动解决单个交易的冲突,或者从复制拓扑中删除源服务器或副本。

对于diamond拓扑结构中的多源副本(其中副本从两个或多个源服务器上复制,而这些源服务器又从共同的源服务器上复制),当使用基于GTID的复制时,确保所有通道上的复制过滤器或其他通道配置都是相同的。在基于GTID的复制中,过滤器仅应用于交易数据,而GTID不被过滤掉。这是为了使副本的GTID集合与源服务器的GTID集合保持一致,以便可以使用GTID自动定位而不需要每次重新获取过滤掉的交易。在diamond拓扑结构中,如果下游副本从多个源服务器上接收到相同的交易,那么下游副本现在拥有该交易的多个版本,结果取决于哪个通道首先应用该交易。第二个通道尝试应用该交易时将跳过该交易,因为该交易的GTID已经被第一个通道添加到gtid_executed集合中。使用相同的过滤器在所有通道上,因此没有问题,因为所有版本的交易都包含相同的数据,因此结果相同。但是,如果在通道上使用不同的过滤器,数据库可能变得不一致,复制可能会挂起。