Documentation Home
MySQL 8.4 Reference Manual
Related Documentation Download this Manual
PDF (US Ltr) - 39.8Mb
PDF (A4) - 39.9Mb
Man Pages (TGZ) - 257.9Kb
Man Pages (Zip) - 364.9Kb
Info (Gzip) - 4.0Mb
Info (Zip) - 4.0Mb


19.1.3.3 GTID 自动定位

GTIDs 替代了之前用于确定数据流开始、停止或恢复的文件偏移对。使用 GTIDs 时,副本可以直接从复制数据流中获取所有需要的信息,以便与源同步。

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

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

当副本启用 GTIDs (GTID_MODE=ONON_PERMISSIVE,OFF_PERMISSIVE ) 和 SOURCE_AUTO_POSITION 选项启用时,自动定位将被激活以连接到源。源必须设置 GTID_MODE=ON,以便连接成功。在初始握手中,副本将发送包含已接收、已提交或已提交的交易的 GTID 集合。这 GTID 集合等于 gtid_executed 系统变量 (@@GLOBAL.gtid_executed ) 中的 GTID 集合和性能 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系统变量中添加到GTID集中由其他方法,源将发送错误ER_SOURCE_HAS_PURGED_REQUIRED_GTIDS给副本,并且复制不开始。缺少的删除事务的GTID被识别并在源的错误日志中列出在警告信息ER_FOUND_MISSING_GTIDS中。副本不能自动从这个错误中恢复,因为需要的交易历史部分已经被删除。尝试重新连接没有启用SOURCE_AUTO_POSITION选项只会导致副本上的删除事务丢失。恢复的正确方法是让副本从其他源复制缺少的交易,或者将副本替换为从更 recent备份创建的新副本。考虑将源的二进制日志过期期限binlog_expire_logs_seconds设置为确保情况不再发生。

在交易交换过程中,如果发现复制服务器已经接收或提交了具有源UUID的交易,但是源服务器本身没有记录它们,源服务器将发送错误ER_REPLICA_HAS_MORE_GTIDS_THAN_SOURCE到复制服务器,并且复制不启动。这可能发生在源服务器在没有设置sync_binlog=1的情况下,出现了断电或操作系统崩溃,导致已经提交的交易丢失,但已经被复制服务器接收。源服务器和复制服务器可能会分歧,如果客户端在源服务器重启后提交了交易,这可能会导致源服务器和复制服务器使用相同的GTID来记录不同的交易。恢复这种情况的正确方法是手动检查源服务器和复制服务器是否分歧。如果相同的GTID现在用于不同的交易,您需要对单个交易进行手动冲突解决或删除源服务器或复制服务器以从复制拓扑结构中删除。如果问题只在源服务器上丢失了交易,您可以将源服务器转换为复制服务器,让它跟随其他服务器在复制拓扑结构中,然后再将其转换回源服务器如果需要。

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