mysql主从架构本身不支持真正的自动切换，必须依赖外部工具（如mha、orchestrator等）实现检测、选主、路由变更；gtid仅确保切换过程数据不丢、不重、复制可自动拉起，前提是所有节点启用gtid_mode=on、enforce_gtid_consistency=on及配套参数。

MySQL 主从架构本身**不支持真正的“自动切换”**，GTID 也不是一个自动故障转移（failover）组件。它只是让**手动切换变得可预测、可验证、无需计算位点**。所谓“自动切换”，实际需要配合外部工具（如 MHA、Orchestrator、VIP + 脚本、或云厂商高可用服务）来完成检测、选主、路由变更等动作；GTID 的作用是确保这些动作执行后，数据不会丢、不会重复、复制能立刻拉起。 下面直接说清楚关键点：

GTID 让切换“稳”的核心原因

每个事务自带唯一 ID（source_id:transaction_id），从库靠自己已执行的 GTID 集合（gtid_executed）和收到但未执行的集合（gtid_retrieved）自动比对、跳过已执行事务。不用再人工查 SHOW MASTER STATUS、算偏移量、输错一个字符就中断复制。

切换前必须满足的硬性条件

• 所有节点开启 gtid_mode = ON 且 enforce_gtid_consistency = ON
• 主库和所有从库的 binlog_format = ROW、log_bin = ON、log_slave_updates = ON
• 每个实例 server_id 全局唯一
• 初始搭建时用了 mysqldump --set-gtid-purged=ON 或 xtrabackup --slave-info，保证 gtid_purged 完整
• 存量传统复制集群要切 GTID，必须走五步渐进式切换（WARN → ON → OFF_PERMISSIVE → ON_PERMISSIVE → ON），不能直接设 ON

一次安全的手动切换流程（外部工具调用的核心逻辑）

假设原主库宕机，需将某从库 slave1 提升为新主：

MySQL

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

下载

• 确认 slave1 已追平：SHOW SLAVE STATUS\G 中 Retrieved_Gtid_Set 和 Executed_Gtid_Set 完全相等，且两个线程都为 Yes
• 在 slave1 上执行：STOP SLAVE; RESET SLAVE ALL;（注意带 ALL，清掉旧位点和 gtid_purged 元数据）
• 设置只读关闭：SET GLOBAL read_only = OFF;（原主库通常设为 read_only = ON，这里要反向操作）
• 其他从库连向新主时，CHANGE MASTER TO 只写：MASTER_AUTO_POSITION = 1，其余参数如 MASTER_HOST、MASTER_USER 等照常填，绝不能出现 MASTER_LOG_FILE 或 MASTER_LOG_POS

为什么旧主恢复后只能当从库，不能再写？

因为它的 gtid_executed 已落后于新主——哪怕只差一个事务，GTID 复制就会拒绝启动，报错类似：The slave requires GTIDs not present in master's binary logs。必须用 RESET MASTER 清空其 binlog 并重新配置为从库，否则无法加入复制链。