MySQL 5.7 配置 GTID 主从复制需在主从节点 my.cnf 中开启 gtid_mode 和 enforce_gtid_consistency，设置唯一 server-id，并在从库使用 CHANGE MASTER TO MASTER_AUTO_POSITION=1 建立连接。该方案适用于需要简化故障切换和避免事务重复执行的生产环境，风险边界是不支持非事务引擎和特定 DDL 语句。

命令速用版

主从节点 my.cnf 配置文件需包含以下核心参数，确保 binlog 格式为 ROW 且 GTID 模式开启。

[mysqld]
server-id=1
log-bin=mysql-bin
binlog-format=ROW
gtid-mode=ON
enforce-gtid-consistency=ON
log-slave-updates=ON

从库连接主库使用 MASTER_AUTO_POSITION=1 替代传统的文件位置定位。

CHANGE MASTER TO
MASTER_HOST='主库 IP',
MASTER_USER='repl',
MASTER_PASSWORD='密码',
MASTER_AUTO_POSITION=1;

为什么会这样

GTID 由 server_uuid 和 transaction_id 组成，保证事务在集群中全局唯一。

传统复制依赖 binlog 文件名和位置偏移量，主库切换后需人工计算新位点。GTID 模式下，从库自动识别已执行事务集合，通过 MASTER_AUTO_POSITION=1 请求主库发送缺失的事务，简化了运维操作并降低了人为错误风险。

分步处理

配置过程分为参数修改、账号创建、数据同步和复制启动四个阶段。

1. 修改配置文件：主库和从库的/etc/my.cnf 均需设置 gtid_mode=ON 和 enforce_gtid_consistency=ON，server-id 必须全局唯一。

2. 创建复制账号：在主库执行 CREATE USER 和 GRANT REPLICATION SLAVE 权限，确保从库可连接。

3. 数据一致性处理：新库可直接配置，旧库需通过 mysqldump 备份主库数据并导入从库，确保 GTID 执行集合一致。

4. 启动复制：在从库执行 CHANGE MASTER TO 命令后，运行 START SLAVE 启动同步线程。

怎么验证是否生效

通过 SHOW SLAVE STATUS 命令检查复制线程状态和 GTID 执行情况。

执行 SHOW SLAVE STATUS\G，确认 Slave_IO_Running 和 Slave_SQL_Running 状态均为 Yes。查看 Retrieved_Gtid_Set 和 Executed_Gtid_Set 字段，确认从库正在接收并执行主库的 GTID 事务。

常见坑

GTID 模式对 SQL 语句和存储引擎有特定限制，配置前需排查业务兼容性。

1. 不支持非事务引擎：MyISAM 等非事务存储引擎可能导致 GTID 不一致，建议统一使用 InnoDB。

2. 禁止特定语句：不支持 CREATE TABLE ... SELECT 语句，不支持创建或删除临时表操作。

3. 参数顺序敏感：开启 GTID 需先设置 enforce_gtid_consistency=ON，再设置 gtid_mode=ON，顺序错误会导致启动失败。

常见问题

传统复制模式能直接切换到 GTID 吗？

可以切换，但需确保主从无匿名事务且数据一致。

先在主从服务器设置 GLOBAL.ENFORCE_GTID_CONSISTENCY=ON，观察状态确认无匿名事件后，再开启 GTID_MODE 并执行 CHANGE MASTER TO MASTER_AUTO_POSITION=1。

从库报错 GTID 不一致怎么处理？

需重置从库 GTID 状态或跳过特定事务。

若数据允许丢失，可 STOP SLAVE，RESET SLAVE ALL，重新导入备份并配置复制。若需跳过，可使用 sql_slave_skip_counter 但 GTID 模式下受限，建议重新构建从库。

参考来源

1. 51CTO 博客：mysql5.7 基于 GTID 实现主从复制_yang_hwei_lazihuman 的技术博客

2. CSDN 博客：配置 MySQL 5.7 基于 GTID 实现主从复制和使用 percona-toolkit 实现监控及数据校验

3. 技术博客：MySQL5.7 配置 GTID 主从---搭建 GTID 主从