mysql5.7如何通过GTID实现主从切换_GTID模式配置要点-mysql教程-PHP中文网

不能直接将gtid_mode设为ON，因为MySQL强制要求切换前集群中不存在任何匿名事务；存量传统复制的binlog全是匿名事务，直接设ON会报错或导致从库SQL线程启动失败，必须经WARN→ON→OFF_PERMISSIVE→ON_PERMISSIVE→ON五步渐进切换，并确保所有节点同步执行、匿名事务清零后方可完成。

mysql5.7如何通过gtid实现主从切换_gtid模式配置要点

MySQL 5.7 不能直接在主从已运行的集群上“开启 GTID”就完事——必须按五步渐进切换，且所有节点严格同步执行，否则复制立即中断或数据不一致。

gtid_mode 为什么不能直接设为 ON

MySQL 强制要求：GTID 模式启用前，必须确认集群中**不存在任何匿名事务（Anonymous GTID）**。而存量主从如果长期运行在传统模式下，binlog 里全是 0-0- 开头的事务标识，SET GLOBAL gtid_mode = ON 会直接报错或导致从库 SQL 线程拒绝启动。

真正安全的路径是分阶段过渡：

SET GLOBAL enforce_gtid_consistency = WARN → 观察错误日志里是否有不兼容语句（如 CREATE TABLE ... SELECT、RAND()）
SET GLOBAL enforce_gtid_consistency = ON → 阻断新不兼容语句写入
SET GLOBAL gtid_mode = OFF_PERMISSIVE → 允许混用匿名/带 GTID 事务，但只读取不生成新 GTID
SET GLOBAL gtid_mode = ON_PERMISSIVE → 开始生成 GTID，但仍兼容旧事务
SET GLOBAL gtid_mode = ON → 彻底禁用匿名事务

每一步执行后，必须在所有主从节点上运行 SELECT @@global.gtid_mode, @@global.enforce_gtid_consistency 确认值一致，并等待至少 1–2 分钟观察 SHOW SLAVE STATUS\G 中无延迟或错误。

mysqldump 初始化从库时 --set-gtid-purged=ON 是硬性要求

传统方式用 mysqldump --master-data=2 导出再导入，在 GTID 模式下会导致从库启动失败，报错类似：Could not execute Write_rows event... BINLOG_FORMAT = STATEMENT 或更隐蔽的 GTID_PURGED mismatch。

正确做法只有这一种：

MySQL

编写正确的MySQL查询，避免字符集、索引和锁方面的常见陷阱。

下载

导出必须加 --set-gtid-purged=ON（MySQL 5.6.9+ 支持），它会在 dump 文件开头插入两行关键语句：
SET @MYSQLDUMP_TEMP_LOG_BIN = @@SESSION.SQL_LOG_BIN;
SET @@SESSION.SQL_LOG_BIN= 0;
SET @@GLOBAL.GTID_PURGED='xxx-xxx-xxx';
导入前确保从库 gtid_mode=ON 且未执行过任何事务（否则 GTID_PURGED 冲突）
绝对不要用 --set-gtid-purged=OFF 初始化 GTID 从库——这会让从库认为“自己没执行过任何 GTID 事务”，后续 CHANGE MASTER TO ... MASTER_AUTO_POSITION=1 必然失败

CHANGE MASTER TO 必须用 MASTER_AUTO_POSITION=1

一旦完成 GTID 切换，CHANGE MASTER TO 就不能再指定 MASTER_LOG_FILE 和 MASTER_LOG_POS。这些字段在 GTID 模式下被忽略，强行填写反而可能触发非预期行为（比如跳过部分事务）。

标准命令是：

CHANGE MASTER TO
  MASTER_HOST='192.168.2.171',
  MASTER_PORT=3306,
  MASTER_USER='repluser',
  MASTER_PASSWORD='Abcd@1234',
  MASTER_AUTO_POSITION=1;

注意点：

MASTER_AUTO_POSITION=1 表示启用 GTID 自动定位，从库会基于 gtid_executed 和主库的 Executed_Gtid_Set 自动计算需要拉取的事务范围
执行前务必先 STOP SLAVE，否则会报错 ERROR 3021 (HY000): The slave is not configured or failed to initialize
成功后 SHOW SLAVE STATUS\G 中 Auto_Position: 1 必须为 1，且 Retrieved_Gtid_Set 和 Executed_Gtid_Set 应持续增长

最容易被忽略的配置项：log_slave_updates 和 server-uuid

这两个不是可选项，而是 GTID 复制能链式传递的前提：

log_slave_updates=ON 必须在**所有从库**（包括级联从库）的配置文件中显式设置并重启生效；否则该从库无法将重放的事务写入自己的 binlog，下游从库就收不到 GTID，复制链断裂
server-uuid 必须全局唯一，由 MySQL 启动时自动生成（存于 auto.cnf）。若克隆虚拟机或复制数据目录，必须删除原 auto.cnf 让 MySQL 重生成，否则多个实例 UUID 相同会导致 GTID 冲突、事务被跳过甚至数据覆盖
另外两个常漏配但关键的项：master-info-repository=TABLE 和 relay-log-info-repository=TABLE，它们让复制元数据持久化到表而非文件，避免 mysqld 意外崩溃后丢失位置信息

GTID 的可靠性不来自“自动”，而来自对每个环节的显式约束——少配一项，就可能在某个低峰夜凌晨三点让你收到告警。