gtid空洞是指gtid_executed中事务id序列不连续（如存在1和3但缺失2），它非错误而是设计使然，常见于跳过复制错误或不写binlog的操作；不能靠reset master填补，因该操作清空所有binlog且要求实例可丢数据，生产主库执行将中断复制链路。
GTID空洞是什么，为什么不能靠RESET MASTER填
MySQL的gtid_executed是只增不减的集合，一旦事务被记录，即使后续被回滚、删除binlog或主从切换，对应GTID也不会自动消失。所谓“空洞”，就是gtid_executed中缺失某个连续序列号（比如存在uuid:1和uuid:3，但没有uuid:2），这本身不报错、不影响复制——但如果你试图用SET GTID_NEXT + 空事务“补”它，MySQL会直接拒绝：ERROR 1840 (HY000): @@GLOBAL.GTID_PURGED can only be set when @@GLOBAL.GTID_EXECUTED is empty。
- 空洞不是bug，是GTID设计使然：每个GTID代表一个已执行事务的唯一身份，跳号常见于
DROP DATABASE、CREATE TEMPORARY TABLE等不写binlog的语句，或从库跳过错误时手动注入GTID -
RESET MASTER会清空gtid_executed和所有binlog，但要求实例是全新或可丢数据的从库；生产主库执行等于自断复制链路 - 真正危险的操作是手动修改
gtid_purged：它必须是gtid_executed的子集，且不能引入新GTID，否则启动失败或主从不一致
如何安全跳过空洞并让从库追上主库
典型场景：主库gtid_executed = uuid:1-5,7-10，从库因网络中断错过uuid:6，导致START SLAVE卡在Waiting for source to send event，错误日志出现The slave is connecting using CHANGE MASTER TO MASTER_AUTO_POSITION = 1但无进展。
- 先确认空洞位置：
SELECT * FROM performance_schema.replication_connection_status\G，看LAST_ERROR_MESSAGE是否含Could not execute because of a gap in the sequence - 在从库执行跳过操作：
STOP SLAVE; SET GTID_NEXT = 'uuid:6'; BEGIN; COMMIT; SET GTID_NEXT = 'AUTOMATIC'; START SLAVE;—— 注意uuid必须和主库一致，可通过SHOW MASTER STATUS查主库的Executed_Gtid_Set - 跳过后立即检查：
SHOW SLAVE STATUS\G中Retrieved_Gtid_Set和Executed_Gtid_Set应开始收敛，且Seconds_Behind_Master不再增长
gtid_executed和gtid_purged的更新时机差异
这两个变量常被混淆，但行为完全不同：gtid_executed是运行时内存+磁盘双写（每次事务提交后追加到binlog文件末尾），而gtid_purged只在PURGE BINARY LOGS或RESET MASTER时才变更，且值来自已删除binlog中最早的GTID集合。
- 重启mysqld后，
gtid_executed从最新binlog文件头读取（所以删binlog前务必确保gtid_executed已落盘） -
gtid_purged不可手动SET，只能通过RESET MASTER或PURGE间接更新；若手动SET GTID_PURGED，必须满足：gtid_purged ⊆ gtid_executed，且服务器未开启binlog（sql_log_bin=OFF） - 主从不一致常源于
gtid_purged被误设过大：比如从库导入全量备份后，SET GTID_PURGED设成主库当前值，但实际缺失中间binlog，导致后续复制找不到起点
备份恢复时gtid_executed怎么保持连贯
用mysqldump --set-gtid-purged=ON导出时，会在SQL头部写入SET @@GLOBAL.GTID_PURGED；但若备份期间主库持续写入，这个值可能比实际gtid_executed旧，恢复后从库会漏掉部分事务。
- 最稳做法：停写+
FLUSH TABLES WITH READ LOCK+SHOW MASTER STATUS记下Executed_Gtid_Set，再mysqldump，释放锁后立刻UNLOCK TABLES - 不停服方案：用
Percona XtraBackup，它备份时自动记录gtid_executed快照，并生成xtrabackup_binlog_info供恢复时对齐 - 恢复后务必验证：
SELECT GTID_SUBSET('uuid:1-100', @@global.gtid_executed)返回1才算覆盖完整，否则说明备份点之后有遗漏
空洞本身不破坏数据一致性，但处理方式错一步，就可能让主从GTID集合永久分叉——尤其是gtid_purged设错后，连CHANGE MASTER TO MASTER_AUTO_POSITION=1都连不上源端。
