旧主库重做为从库前必须跳过切换期间新主库已执行但旧主库缺失的GTID事务，需通过SELECT @@global.gtid_executed结合binlog解析定位精确起始GTID，并SET GLOBAL gtid_purged清除冲突历史。
旧主库重做为从库前必须跳过哪些 Binlog 事件
主备切换后，原主库如果要重新接入作为新主库的从库，直接启动复制会大概率报错 Duplicate entry 或 Cannot execute statement——因为切换期间新主库已写入部分数据，而旧主库的 Binlog 位置落后且可能含冲突事务。
关键不是“全量重放”，而是定位到切换完成、新主库开始接管写入的那个精确 GTID 或 binlog position。常见错误是拿 SHOW MASTER STATUS 在新主库上随便截一个位置，就让旧主库从那开始同步，结果跳过了中间关键的 DDL 或用户数据变更。
- 先在新主库查出切换时刻的 GTID 集合：
SELECT @@global.gtid_executed;，再结合运维记录或日志确认最后一条由旧主库发起的写入事务（比如某条INSERT INTO user_log）对应的 GTID - 用
mysqlbinlog --base64-output=DECODE-ROWS -v解析新主库的 binlog 文件，搜索该事务的GTID_LOG_EVENT和后续第一个非空事务起始位置 - 旧主库执行
SET GLOBAL gtid_purged = 'xxx-xxx-xxx:1-12345';（注意必须是RESET MASTER后才能设，否则报错Can't modify gtid_purged）
逆向解析 Binlog 时为什么不能只靠 mysqlbinlog --flashback
mysqlbinlog --flashback 是 Percona Toolkit 的功能，MySQL 官方 mysqlbinlog 并不支持。很多人误以为加了这个参数就能自动生成回滚 SQL，实际运行会报错 unknown option '--flashback'。
真正可行的逆向路径是：先用官方 mysqlbinlog 输出带 ROW 格式的可读事件，再人工或脚本识别 Write_rows_v1/Delete_rows_v1 等事件，把新值还原成旧值。这一步极易出错——比如没处理 UPDATE 中的 WHERE 条件字段变化，或忽略 ENUM / SET 类型的隐式转换。
- 务必使用
--base64-output=DECODE-ROWS -v，否则看到的是乱码@1=0x... @2=0x...，无法判断字段含义 - 注意
mysqlbinlog默认只解析到当前系统时间，若需解析历史 binlog，得显式指定--start-datetime和--stop-datetime或--start-position/--stop-position - 遇到
ALTER TABLE ... ADD COLUMN后的Write_rows事件，行数据字段数会变多，脚本若按旧表结构解析，字段错位会导致补偿 SQL 写错列
用 pt-table-sync 做数据补偿的风险点
pt-table-sync 能比对主从数据差异并生成修复语句，但它默认以“主库为准”单向同步。如果旧主库上存在未被同步到新主库的脏写（比如切换窗口期应用直连旧主写的几条记录），直接跑 pt-table-sync --sync-to-master 会把这些数据删掉，造成真实丢失。
更隐蔽的问题是它依赖 PRIMARY KEY 或唯一索引对齐行，一旦某张表只有 UNIQUE KEY 且含 NULL 值，pt-table-sync 会漏比对或误判为不同行。
- 执行前先用
--print模式输出将要执行的 SQL，人工核对前 20 条是否符合预期，尤其关注DELETE和REPLACE语句 - 禁止在业务高峰期运行；它会在目标表加
SELECT ... FOR UPDATE，锁表时间取决于数据量和网络延迟 - 若表无主键，必须用
--chunk-index指定一个能高效分块的索引，否则退化为全表扫描，可能拖垮数据库
GTID 模式下 RESET SLAVE 不等于清空复制上下文
很多人执行 RESET SLAVE 后以为可以重新配置 CHANGE MASTER TO，结果启动复制时报错 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。这是因为 RESET SLAVE 只清配置，不清理 gtid_executed 和 gtid_purged 元数据。
真正需要的是组合操作：先 STOP SLAVE，再 RESET SLAVE ALL（注意是 ALL），最后手动 SET GLOBAL gtid_purged = ''（仅当确定要丢弃所有已执行 GTID 时）或设为新主库要求的集合。
-
RESET SLAVE ALL会删除master.info和relay-log.info文件，并重置Retrieved_Gtid_Set和Executed_Gtid_Set - 设
gtid_purged前必须确保gtid_executed为空，否则报错；可用SHOW GLOBAL VARIABLES LIKE 'gtid_executed';确认 - 如果旧主库之前启用了
log_slave_updates，它的 binlog 里也存有从新主库同步来的 GTID，这些也要一并 purge，否则START SLAVE时仍会尝试重放已失效事件
