MySQL GTID 自动定位怎么切换复制源

MySQL 已启用 GTID 时，切换复制源不需要重新计算 binlog 文件名和位置。停止副本的接收线程与应用线程后，执行 CHANGE REPLICATION SOURCE TO ... SOURCE_AUTO_POSITION=1，副本会把自己已经接收或执行的 GTID 集告诉新源，新源只发送它缺少的事务。

官方地址：https://dev.mysql.com/doc/refman/8.4/en/replication-gtids-howto.html

GTID 自动定位解决了什么

一次常见故障是：原复制源不可用，副本需要改连同一拓扑中的另一台 MySQL。文件位置复制要求人工找到新源上的对应 binlog 坐标；GTID 自动定位则比较集合。副本在连接握手中发送已有 GTID，新源从自己的 binary log 中挑出副本没有的事务。

这项能力解决的是“从哪里继续取事务”，不是“候选源是否一定正确”。如果新源缺少原源的一段事务，或需要的 GTID 已经从新源 binary log 清理，复制仍会拒绝启动。官方对应错误包括 ER_SOURCE_HAS_PURGED_REQUIRED_GTIDS；如果副本记录了某个源 UUID 下、而候选源自己没有提交的 GTID，还可能遇到 ER_REPLICA_HAS_MORE_GTIDS_THAN_SOURCE。

支持范围与切换前检查

下面使用 MySQL 8.4 的当前语法。候选源应为 gtid_mode=ON，副本使用自动定位时也要启用 GTID；启用 GTID 的拓扑通常同时设置 enforce_gtid_consistency=ON。先分别在副本和候选源保存状态，避免切换后失去判断依据。

-- 在副本上记录 GTID 能力与已经执行的事务集合
SELECT @@GLOBAL.gtid_mode,
       @@GLOBAL.enforce_gtid_consistency,
       @@GLOBAL.gtid_executed;

-- 查看当前复制源、通道、线程和最近错误
SHOW REPLICA STATUS\G

-- 在候选源上记录它拥有的事务，以及已经从 binary log 清理的集合
SELECT @@GLOBAL.gtid_mode,
       @@GLOBAL.gtid_executed,
       @@GLOBAL.gtid_purged;

把查询结果作为字符串带入任意管理会话，可以做两个保守检查。第一个判断副本已经执行的集合是否被候选源覆盖；第二个判断候选源已清理的 GTID 中，是否存在副本还没有执行的部分。

-- 1 表示候选源覆盖副本已有集合；0 时先调查拓扑分叉或本地事务
SELECT GTID_SUBSET('副本_gtid_executed',
                   '候选源_gtid_executed') AS replica_is_covered;

-- 结果为空才表示候选源没有清理副本仍缺少的 GTID
SELECT GTID_SUBTRACT('候选源_gtid_purged',
                     '副本_gtid_executed') AS purged_but_missing;

这里采用的是偏保守的运维判断。复杂的多源、环形或含本地写入拓扑可能让全集子集检查返回 0，需要按 UUID 分段解释，不能为了通过检查而修改 gtid_purged。

最小切换示例

假设副本原来连接 source-a，现在要改连 source-b.internal。先确认应用已经把写入口切到正确主节点，再在副本执行：

-- SOURCE_AUTO_POSITION=1 要求接收线程和应用线程都处于停止状态
STOP REPLICA;

-- 只使用 GTID 自动定位，不要同时填写 SOURCE_LOG_FILE 或 SOURCE_LOG_POS
CHANGE REPLICATION SOURCE TO
    SOURCE_HOST = 'source-b.internal',
    SOURCE_PORT = 3306,
    SOURCE_USER = 'repl_user',
    SOURCE_PASSWORD = '由密钥系统注入的占位值',
    SOURCE_AUTO_POSITION = 1;

-- 配置完成后重新启动接收与应用线程
START REPLICA;

生产环境不要把真实复制密码写进工单、脚本仓库或文章。应通过受控凭据系统注入，并沿用或显式配置 TLS。若复制账户使用 caching_sha2_password 且连接不安全，MySQL 还要求配置公钥获取或公钥路径；更推荐直接使用可验证的安全连接。

如果是多源复制，每条管理语句都要指定同一个通道，例如：

-- 多源环境必须始终绑定同一个 channel，避免误改其他复制链路
STOP REPLICA FOR CHANNEL 'orders';

-- 给 orders 通道切换候选源并启用 GTID 自动定位
CHANGE REPLICATION SOURCE TO
    SOURCE_HOST = 'source-b.internal',
    SOURCE_PORT = 3306,
    SOURCE_USER = 'repl_user',
    SOURCE_PASSWORD = '由密钥系统注入的占位值',
    SOURCE_AUTO_POSITION = 1
FOR CHANNEL 'orders';

-- 只启动刚刚修改的复制通道
START REPLICA FOR CHANNEL 'orders';

切换后按状态字段确认

-- 默认通道直接查看；多源环境追加 FOR CHANNEL 'orders'
SHOW REPLICA STATUS\G

不要只看 START REPLICA 没报错。至少核对这些字段：

Seconds_Behind_Source 可以辅助观察，但不能替代线程状态、错误字段和 GTID 集。刚切换时尤其要先确认接收链路和应用链路都正常，再判断延迟。

兼容与失败处理

MySQL 8.0.23 及以后使用 CHANGE REPLICATION SOURCE TO 和 SOURCE_AUTO_POSITION；更早版本沿用 CHANGE MASTER TO 与 MASTER_AUTO_POSITION。混合版本拓扑应以副本实际版本的官方手册为准，不要把两套关键字混写。

如果出现“候选源已清理所需 GTID”，正确处理通常是选择仍保留这段日志的源，或从包含所需事务的正确备份重新构建副本。不要用手工篡改 gtid_executed、gtid_purged 或跳过事务来掩盖数据缺口。

切换复制源也不需要先执行 RESET REPLICA ALL。该命令会清理连接元数据，扩大回滚范围；仅仅替换 SOURCE_HOST 并启用自动定位时，直接在停止状态下执行 CHANGE REPLICATION SOURCE TO 即可。

性能与安全注意

• 副本落后很多 binary log 时，候选源查找并发送第一个缺失事务可能需要时间；不要把短暂无数据误判为切换失败。
• 确认候选源的日志保留周期覆盖故障恢复窗口，GTID 只能标识缺口，不能替代日志保留。
• 复制账户只授予必要权限，凭据不落入命令历史；跨网络连接启用 TLS 并验证服务端证书。
• 切换完成后保留原状态记录和回滚方案，直到新链路的接收、应用和业务读写都稳定。

常见问题

SOURCE_AUTO_POSITION=1 后还要设置 binlog 文件和位置吗？

不要同时设置。自动定位使用 GTID 集协商，SOURCE_LOG_FILE、SOURCE_LOG_POS 与它不能一起出现在同一次配置中。

为什么 Auto_Position=1 但 Replica_IO_Running 仍是 No？

先看 Last_IO_Error。常见原因是认证或 TLS 失败、网络不可达、候选源已清理副本需要的 GTID，或者副本拥有候选源不认可的同源 GTID。

切换源前只停止 IO_THREAD 可以吗？

不可以。官方要求使用 SOURCE_AUTO_POSITION=1 时，接收线程和应用线程都要停止，直接执行 STOP REPLICA 最清楚。

GTID 自动定位能保证新源数据一定完整吗？

不能。它负责比较和传输可用的缺失 GTID，候选源是否属于正确拓扑、日志是否仍保留、数据是否发生分叉，仍需在切换前核对。