MySQL GTID是全局事务标识符，通过唯一ID（source_id:transaction_id）追踪事务，使主从同步不依赖binlog文件名和偏移量，从而提升故障切换可靠性；需全局启用gtid_mode=ON与enforce_gtid_consistency=ON，并确保binlog_format=ROW、log_slave_updates=ON及server_id唯一。
MySQL GTID 是什么，为什么它能让故障切换更可靠
GTID（Global Transaction Identifier）不是开关，而是一套事务追踪机制：每个事务在集群中都有唯一 ID，格式是 source_id:transaction_id。它让主从之间不再依赖 binlog 文件名和偏移量，而是靠“这个事务我执行过没”来判断同步状态。这意味着切换时不用手动算位置、不会因文件轮转或路径不一致出错，只要从库的 GTID 集合包含主库缺失的部分，就能自动补全。
常见错误现象：ERROR 1236 (HY000): The slave is connecting using CHANGE MASTER TO MASTER_AUTO_POSITION = 1, but the master has purged binary logs containing GTIDs that the slave requires——本质是主库 gtid_purged 已清理掉从库还没拉取的事务，GTID 模式下这比传统模式更容易暴露数据断层。
- 必须在所有节点开启
gtid_mode=ON且enforce_gtid_consistency=ON，否则复制会拒绝启动 -
gtid_executed是只读变量，记录本机已执行的所有 GTID；gtid_purged是已清理但曾执行过的 GTID 集合，主库重启后由gtid_executed初始化，不能手动 SET（除非RESET MASTER） - 如果用
mysqldump --set-gtid-purged=OFF导入数据，新实例没有 GTID 上下文，后续无法加入 GTID 复制链——必须用--set-gtid-purged=ON或导入后手动 SETgtid_purged
如何安全地把从库提升为主库（failover）
GTID 本身不提供自动选主，它只是让手动切换变得可预测。关键动作不是“停服务”，而是确认从库已追平、并重置其角色为新主。
使用场景：原主库宕机不可恢复，需人工介入切换；或演练高可用流程。
- 先查从库是否已同步完成：
SHOW SLAVE STATUS\G中Retrieved_Gtid_Set和Executed_Gtid_Set必须完全相等，且Slave_IO_Running和Slave_SQL_Running均为Yes - 停止复制：
STOP SLAVE;，再执行RESET SLAVE ALL;（注意：带ALL才会清空gtid_purged相关元数据） - 设置为新主库：
SET GLOBAL gtid_purged = 'xxx:1-100';（值来自原主库的SELECT @@global.gtid_executed;，确保新主“承认”自己已执行过这些事务） - 应用连接需指向新主库 IP/端口，旧主库恢复后只能作为从库重新接入，不能再写入
从备份恢复时如何避免 GTID 冲突
用物理备份（如 xtrabackup）或逻辑备份（mysqldump）恢复实例后，如果没处理 GTID，新实例的 gtid_executed 为空或与集群不一致，会导致复制中断或重复执行事务。
性能影响：SET GLOBAL gtid_purged 是轻量操作，但若设置错误，后续所有事务都会被拒绝执行（报错 ERROR 1840 (HY000)）。
- 物理备份恢复后，xtrabackup 通常会在
xtrabackup_binlog_info中记录gtid_executed，恢复完立即执行：SET GLOBAL gtid_purged = 'xxx:1-500'; - 逻辑备份恢复后，若 dump 文件含
SET @@GLOBAL.GTID_PURGED语句，确保它在CREATE DATABASE等 DDL 之前执行；否则需手动提取并 SET - 严禁在已有数据的实例上执行
RESET MASTER——它会清空gtid_executed并重置gtid_purged为空，导致该实例无法再作为从库加入任何 GTID 集群
哪些配置项最容易被忽略导致 GTID 失效
GTID 不是开个开关就自动生效的，几个底层参数一旦不匹配，复制连握手都失败。
错误现象：Failed to initialize multi-threaded slave because of missing prerequisites 或直接报 ERROR 3021，其实根源常在配置不一致。
-
binlog_format必须为ROW，STATEMENT 或 MIXED 模式下部分事务无法生成有效 GTID -
log_slave_updates必须开启，否则级联复制中中间从库无法生成自己的 GTID 日志，下游无法继续同步 - 所有节点的
server_id必须唯一且非 0，GTID 模式下它参与构成source_id，重复会导致复制拒绝连接 - MySQL 5.7.6+ 默认启用 GTID auto-position，但老版本或升级实例可能仍用传统 position，检查
SHOW SLAVE STATUS中Auto_Position是否为1
最麻烦的是跨版本混搭：MySQL 5.6 不支持 GTID 的完整语义，5.7 和 8.0 之间也有细微差异，比如 gtid_mode 允许的取值范围不同。上线前务必在同版本环境验证整套 failover 流程，而不是只测单点配置。
