• 首页
  • vue
  • TypeScript
  • JavaScript
  • scss
  • css3
  • html5
  • php
  • MySQL
  • redis
  • jQuery
  • GTID自动定位

    GTID取代了先前为确定开始,停止或恢复主从节点之间的数据流所需的文件偏移对。使用GTID时,从服务器直接与主服务器同步所需的所有信息都是直接从复制数据流中获得的。

    要使用基于GTID的复制来启动从属服务器,请不要在用于指示从属服务器从给定主服务器复制的语句中包括MASTER_LOG_FILEMASTER_LOG_POS选项CHANGE MASTER TO。这些选项指定日志文件的名称和文件中的起始位置,但是对于GTID,从站不需要此非本地数据。相反,您需要启用该MASTER_AUTO_POSITION选项。有关使用基于GTID的复制配置和启动主服务器和从服务器的完整说明,请参见“使用GTID设置复制”。

    MASTER_AUTO_POSITION选项默认为禁用。如果在从属服务器上启用了多源复制,则需要为每个适用的复制通道设置选项。MASTER_AUTO_POSITION再次禁用该选项将使从属设备恢复为基于文件的复制,在这种情况下,您还必须指定MASTER_LOG_FILEMASTER_LOG_POS选项之一或两者。

    当复制从启用GTIDs(GTID_MODE=ONON_PERMISSIVE,OFF_PERMISSIVE),并且MASTER_AUTO_POSITION选项使能,自动定位,用于连接到主激活。主机必须已GTID_MODE=ON设置才能成功连接。在初始握手中,从设备发送一个GTID集,其中包含它已经接收,提交或同时进行的事务。此GTID集等于gtid_executed系统变量(@@GLOBAL.gtid_executed)中GTID集的并集,以及replication_connection_status作为接收到的事务记录在Performance Schema 表中的GTID集(语句的结果SELECT RECEIVED_TRANSACTION_SET FROM PERFORMANCE_SCHEMA.replication_connection_status)。

    主服务器通过发送记录在其二进制日志中的所有事务进行响应,该事务的GTID不包括在从服务器发送的GTID集中。这种交换确保了主服务器仅发送带有从设备尚未接收或提交的GTID的事务。如果从设备从多个主机接收事务,例如菱形拓扑,则自动跳过功能可确保不会两次应用事务。

    如果应由主服务器发送的任何事务已从主服务器的二进制日志中清除,或已gtid_purged通过另一种方法添加到系统变量中的GTID组中,则主服务器将错误ER_MASTER_HAS_PURGED_REQUIRED_GTIDS发送给从服务器,并且复制不会开始。在警告消息ER_FOUND_MISSING_GTIDS中,在主机的错误日志中标识并列出丢失的已清除事务的 GTID。从服务器无法自动从此错误中恢复,因为已清除了追赶主服务器所需的部分事务历史记录。尝试在没有连接的情况下重新连接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现在用于不同的事务,则您需要根据需要对单个事务执行手动冲突解决,或者从复制拓扑中删除主服务器或从服务器。