当主库宕机，基于传统日志点位（binlog+position）的复制在进行故障转移时，其核心难点在于：你不仅要确保所有从库与新的主库数据同步，还要在纷繁的日志文件中，为每一个从库重新计算出一个精准且唯一的同步位点。这一过程极易因操作失误或日志文件轮转，导致主从数据不一致甚至同步中断。
而基于GTID（Global Transaction Identifier，全局事务标识）的复制，为这个复杂的棘手问题提供了一套优雅且自动化的解法。
🔑 核心原理：GTID 的"身份证"机制
GTID是整个方案的核心基石，它给主库上提交的每一个事务都颁发了一张唯一的、全局的“身份证”。其格式通常为 source_id:transaction_id。
基于这个唯一的ID，- 自动定位与幂等执行：当从库连接到新主库时，它会直接通过MASTER_AUTO_POSITION=1的参数，将自己已执行的GTID集合发送给主库。主库会计算出两者GTID集合的“差值”，并将缺失的事务推送给从库，从库执行时会自动跳过那些GTID已存在的日志，从根源上杜绝了因重复执行SQL而造成的数据混乱。它使主从同步不再依赖易错的文件名和偏移量，将问题关键从“物理坐标”转变为“逻辑集合”。
幂等性（Idempotence）：简单说，就是同一个操作执行一次和执行多次，产生的结果是一样的。GTID机制保证了同一个事务且仅会被应用一次，这是整个自动故障转移安全性的基石。
👑 故障转移流程：GTID 如何实现自动“撑腰”
当主库发生故障，整个集群（在编排工具的管理下）会自动遵循以下流程进行恢复**（这里以 Orchestrator 为例，它是目前主流的 MySQL 高可用管理工具）：
故障探测与选举：编排工具会持续监控所有节点的健康状况，一旦发现主库失联，会从一
