笙亿网络策划

基于位点复制和 GTID 复制的区别及优缺点对比

约 6 分钟读完 1 阅
文章导读
MySQL 8.0 默认不再推荐传统基于 binlog 文件名和 position 的复制，因为它在自动化运维中不可靠且极易出错，而 GTID 复制能自动定位同步位置并支持脚本化运维。生产环境应优先启用 GTID 模式，除非受限于 MySQL 5.6.5 以下版本。
📋 目录
  1. A 命令速用版
  2. B 为什么会这样
  3. C 分步处理
  4. D 怎么验证是否生效
  5. E 常见坑
  6. F 常见问题
  7. G 参考来源
A A

MySQL 8.0 默认不再推荐传统基于 binlog 文件名和 position 的复制，因为它在自动化运维中不可靠且极易出错，而 GTID 复制能自动定位同步位置并支持脚本化运维。生产环境应优先启用 GTID 模式，除非受限于 MySQL 5.6.5 以下版本。

先说结论：GTID 复制取代传统位点复制是因其在自动定位、避免人工计算错误及事务一致性上的显著优势，MySQL 8.0 中核心功能已强依赖 GTID。

  • 适合：MySQL 5.6.5 及以上版本的新建集群或需要自动化运维、故障切换的场景。
  • 重点看：GTID 能让 CHANGE MASTER TO 变成一行命令，无需人工查找 binlog 文件名和 position 偏移量。
  • 别忽略：开启 GTID 需同时设置 gtid_mode=ON 和 enforce_gtid_consistency=ON，且事务必须满足一致性要求。

命令速用版

传统位点复制需要人工确认主库 binlog 文件名和位置，命令如下：

CHANGE MASTER TO MASTER_HOST='10.0.1.10', MASTER_USER='repl', MASTER_PASSWORD='xxx', MASTER_LOG_FILE='mysql-bin.000012', MASTER_LOG_POS=123456789;

启用 GTID 后，从库只需执行自动定位命令，无需关心文件名或字节偏移：

基于位点复制和 GTID 复制的区别及优缺点对比
CHANGE MASTER TO MASTER_HOST='10.0.1.10', MASTER_USER='repl', MASTER_PASSWORD='xxx', MASTER_AUTO_POSITION=1;

为什么会这样

传统位点复制依赖人工确认主库当前 binlog 文件的字节位置，该值在主库 binlog 被 purge、重启轮转或 failover 后会瞬间失效。GTID 为每个事务分配全局唯一编号（UUID:TID），从库告诉主服务器已执行完哪些 GTID 值，主库只发送从库未执行的事务 GTID 值，同一个事务只在指定的从库上执行一次。

分步处理

若要从传统复制迁移到 GTID 复制，需按顺序调整参数以避免数据不一致：

  1. 检查版本：确认 MySQL 版本不低于 5.6.5，GTID 是该版本引入的全局事务标识符。
  2. 过渡模式：先将 gtid_mode 设置为 OFF_PERMISSIVE，允许新事务匿名但复制事务支持 GTID。
  3. 开启强制：设置 enforce_gtid_consistency=ON，禁止违反一致性的事务，生产环境必须设为 ON。
  4. 正式启用：将 gtid_mode 设置为 ON，此时所有事务均带 GTID 标识。
  5. 切换从库：在从库执行 STOP SLAVE，然后执行 CHANGE MASTER TO MASTER_AUTO_POSITION=1，最后 START SLAVE。

怎么验证是否生效

执行以下命令查看 GTID 工作模式及已执行集合，确认参数已持久化且集合在增长：

SHOW GLOBAL VARIABLES LIKE 'gtid_mode';
SHOW GLOBAL VARIABLES LIKE 'gtid_executed';
SELECT * FROM mysql.gtid_executed;

注意 mysql.gtid_executed 表是定期压缩更新的，在事务提交非常频繁的系统上，其内容可能略有延迟，查看系统变量 gtid_executed 最准确。

基于位点复制和 GTID 复制的区别及优缺点对比

常见坑

  • 跳错风险：传统位点复制跳错常用 SET GLOBAL sql_slave_skip_counter=1，但这本质是跳过下一条语句，在 ROW 格式 binlog 下极可能破坏数据一致性。
  • 文件丢失：位点复制中若主库 binlog 被 purge 哪怕只删了一天前的文件，SHOW MASTER LOGS 就可能看不到原文件，导致从库同步中断。
  • Failover 复杂：位点复制 failover 后，新主库的位点与旧主库完全不对应，必须人工比对所有从库状态才能选最全节点，这个过程无法脚本化。
  • UUID 持久化：实例 UUID 首次启动时自动生成并写入 data/auto.cnf 文件，重启不改变，确保实例唯一性，不要手动修改该文件。

常见问题

GTID 复制能完全替代传统位点复制吗？

能，MySQL 8.0 默认不推荐传统基于 binlog 文件名 +position 的复制，因为它在自动化运维中天然不可靠。

开启 GTID 后如何跳过错误事务？

不建议使用 sql_slave_skip_counter，GTID 复制下跳过错误事务需通过注入空事务等方式处理，否则可能破坏数据一致性。

从库切换为 GTID 复制需要重建数据吗？

不需要，执行 STOP SLAVE 后变更 MASTER_AUTO_POSITION=1 再 START SLAVE 即可自动匹配 GTID。

参考来源

  • MySQL 8.0 为什么不再推荐使用传统位点复制_分析 GTID 在自动运维中的优势
  • MySQL 基于 GTID 模式的主从复制
  • 基于日志点的复制和 GTID 的复制有何区别？
  • GTID vs 传统复制 (基于 binlog 位置)
  • MySQL GTID 主从复制：原理、部署与避坑指南-CSDN 博客
  • MySQL 复制必知必会:GTID 原理与 gtid_purged 的 5 个关键应用场景
  • MySQL GTID 复制架构实战：从迁移到切换的完整指南_mysql 主从实战 gtid-CSDN 博客
  • MySQL 主从复制与 GTID 环形复制
  • MySQL 主从复制配置详解：基于日志点与 GTID 的比较