10bet网址
MySQL复制
相关的文档10bet官方网站 下载此节选
PDF(美国高级主任)- 1.5 mb
PDF (A4)- 1.6 mb
HTML下载(TGZ)- 322.5 kb
HTML下载(Zip)- 330.4 kb


2.3.3 GTID自动定位

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

如果要使用基于gtid的复制启动副本,需要启用SOURCE_AUTO_POSITION|MASTER_AUTO_POSITION选项中的将复制源更改为语句(从MySQL 8.0.23)或将master更改为语句(MySQL 8.0.23之前)。另一种选择SOURCE_LOG_FILE|MASTER_LOG_FILE而且SOURCE_LOG_POS|MASTER_LOG_POS选项指定了日志文件的名称和文件中的起始位置,但是使用gtid副本不需要这些非本地数据。有关使用基于gtid的复制配置和启动源和副本的完整说明,请参见第2.3.4节,“使用gtid建立复制”

SOURCE_AUTO_POSITION|MASTER_AUTO_POSITION选项默认关闭。如果副本上启用了多源复制,则需要为每个适用的复制区域通道设置该选项。禁用SOURCE_AUTO_POSITION|MASTER_AUTO_POSITION选项再次使副本恢复到基于文件的复制,在这种情况下,还必须指定一个或两个SOURCE_LOG_FILE|MASTER_LOG_FILESOURCE_LOG_POS|MASTER_LOG_POS选项。

当副本启用了gtid时(GTID_MODE =对ON_PERMISSIVE,OFF_PERMISSIVE)及MASTER_AUTO_POSITION启用选项,将激活连接到源的自动定位。源必须具有GTID_MODE =对为使连接成功而设置。在最初的握手中,副本发送一个GTID集,其中包含它已经接收到的、提交的或两者都有的事务。的GTID集合的并集gtid_executed系统变量(@@GLOBAL.gtid_executed),以及记录在性能模式中的一组gtidreplication_connection_status表作为收到的事务(语句的结果)从PERFORMANCE_SCHEMA.replication_connection_status选择RECEIVED_TRANSACTION_SET).

源通过发送其二进制日志中记录的GTID不包括在副本发送的GTID集中的所有事务来响应。要做到这一点,源程序首先通过检查Previous_gtids_log_event在每个二进制日志文件的头中,从最近的开始。当源头找到第一个Previous_gtids_log_event其中不包含副本缺少的事务,它从二进制日志文件开始。这种方法是有效的,只有在副本落后于源的大量二进制日志文件时才会花费大量时间。然后,源读取二进制日志文件中的事务以及当前文件之前的后续文件,发送带有副本缺少的GTID的事务,并跳过副本发送的GTID集中的事务。直到副本接收到第一个丢失事务的时间取决于它在二进制日志文件中的偏移量。这种交换确保源只发送带有副本尚未接收或提交的GTID的事务。如果副本从多个源接收事务,就像菱形拓扑的情况一样,自动跳过功能确保事务不会应用两次。

的gtid集合中,如果任何应该由源发送的事务已经从源的二进制日志中清除,或者添加到gtid集合gtid_purged系统变量通过另一种方法,源发送错误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已添加到gtid_executed由第一频道设置。在通道上使用相同的过滤,就不会有问题,因为事务的所有版本都包含相同的数据,因此结果是相同的。但是,在通道上使用不同的过滤,数据库可能变得不一致,复制可能挂起。