GTID 与位点方式对比
位点方式用「binlog 文件名 + 偏移量」定位进度，精确但强耦合具体文件，文件被清理或主库切换后容易失效；GTID 用「已执行过哪些事务」的集合表达进度，形式为 uuid:序号，天然适配主库切换与重放。CDC 工具与复制链路两种都支持，关键是同一套体系内口径要统一——一边按位点一边按 GTID 记录进度，故障切换时必然对不上。
基本信息
| 位点方式 | binlog 文件名 + 偏移量，如 mysql-bin.000123:1944 |
|---|---|
| GTID 方式 | 事务集合，形如 uuid:1-100，表达已执行的事务范围 |
| 开启条件 | gtid_mode=ON 与 enforce_gtid_consistency=ON，通常需重启生效 |
| 自动定位 | SOURCE_AUTO_POSITION=1 时由实例自动计算差异并补齐 |
| 术语变更 | MySQL 8.0.23 起 MASTER/SLAVE 术语改为 SOURCE/REPLICA |
| 失效场景 | 两种方式都无法跨越已被清理的 binlog 与已执行过的 GTID 事务 |
典型使用场景
- 搭建从库或 CDC 采集：选择定位方式并统一写进运维脚本
- 主库切换后恢复：GTID 方式可自动计算差异，位点方式需人工对齐
- 多源汇聚：多个源实例的 GTID 集合可统一管理与比对
- 跳过错事务：使用空事务方式跳过指定 GTID，避免整条链路阻塞
- 延迟评估：注意 GTID 集合本身不能用于计算延迟，应使用秒级延迟指标
两种连接写法（8.0.23+ 新术语）
两种连接写法（8.0.23+ 新术语）
-- 位点方式：需人工指定文件名与偏移
CHANGE REPLICATION SOURCE TO
SOURCE_HOST='10.0.0.5', SOURCE_LOG_FILE='mysql-bin.000123', SOURCE_LOG_POS=1944;
-- GTID 方式：自动定位，主库切换后无需改配置
CHANGE REPLICATION SOURCE TO
SOURCE_HOST='10.0.0.5', SOURCE_AUTO_POSITION=1;
-- 查看已执行与已清理的 GTID 集合
SELECT @@GLOBAL.gtid_executed;
SHOW VARIABLES LIKE 'gtid_purged';跳过指定事务（空事务方式）
跳过指定事务（空事务方式）
-- 目标是让该 GTID 被记录为已执行，但不产生数据变更
SET GTID_NEXT='aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee:1001';
BEGIN;
COMMIT;
SET GTID_NEXT='AUTOMATIC';
-- 执行前必须确认该事务确实可以丢弃，否则数据将永久缺失对比与失效场景
| 对比项 | 位点方式 | GTID 方式 |
|---|---|---|
| 定位表达 | binlog 文件名 + 偏移 | 事务集合（uuid:序号） |
| 主库切换 | 需要重新对齐位点 | 天然适配切换与重放 |
| 日志清理影响 | 位点失效即断链 | 同样受影响，但语义更清晰 |
| 工具支持 | 普遍支持 | 需要实例与工具都启用 GTID |
| 延迟计算 | 可用位点差参考 | 集合无法直接算延迟，需用秒级延迟指标 |
GTID 与位点不是二选一的对立：很多生产体系里复制链路用 GTID，而 CDC 工具仍按位点记录自身进度，此时要在运维文档里写清两套进度的对应关系，切换时才知道该对齐哪个。
使用空事务跳过 GTID 是不可逆操作：该事务的数据在其他节点仍可能存在，跳过会造成目标端永久缺失这段变更，操作前必须确认业务可接受。