GTID主从复制必须主从同时启用、参数对齐、数据初始同步干净，否则START SLAVE会报错或静默跳过事务；需按OFF_PERMISSIVE→ON_PERMISSIVE→ON顺序切换gtid_mode，强制enforce_gtid_consistency=ON，配置文件同步写入，CHANGE MASTER TO必须用MASTER_AUTO_POSITION=1，mysqldump导出须含--set-gtid-purged=ON，server_uuid冲突和gtid_executed不匹配是常见隐性故障根源。
GTID主从复制不是“开关一开就能跑”，必须主从两端同时启用、参数对齐、数据初始同步干净，否则START SLAVE会直接报错或 silently 跳过事务。
主从两端的 gtid_mode 必须都设为 ON 且不能跳过过渡步骤
MySQL 不允许从 OFF 直接切到 ON，尤其当实例已有 binlog 且在运行时。强行 SET GLOBAL gtid_mode = ON 会失败，并提示需要先经过 OFF_PERMISSIVE → ON_PERMISSIVE 阶段。
- 先查当前状态：
SHOW VARIABLES LIKE 'gtid_mode'; - 若为
OFF，按顺序执行（每步后确认生效）：SET GLOBAL gtid_mode = OFF_PERMISSIVE;→SET GLOBAL gtid_mode = ON_PERMISSIVE;→SET GLOBAL gtid_mode = ON; - 紧接着必须设：
SET GLOBAL enforce_gtid_consistency = ON;（设为WARN只能临时测试，上线前必须是ON） - 这些 SET 命令只作用于当前会话，**必须同步写入 my.cnf**，否则重启后还原
CHANGE MASTER TO 必须带 MASTER_AUTO_POSITION = 1
这是 GTID 模式和传统位点复制最直观的区别：你不能再指定 MASTER_LOG_FILE 和 MASTER_LOG_POS，否则 MySQL 会忽略 GTID 并报错 ERROR 3021 (HY000): This operation cannot be performed with a running slave。
使用ydata-profiling（前身为pandas-profiling）生成全面的数据质量报告，包含相关性分析、缺失值模式和基数检测。导出交互式HTML仪表板和JSON摘要。
- 正确写法：
CHANGE MASTER TO MASTER_HOST='10.0.1.10', MASTER_USER='repl', MASTER_PASSWORD='xxx', MASTER_AUTO_POSITION=1; -
MASTER_AUTO_POSITION=1告诉从库：别管位置，用gtid_executed和主库的gtid_purged自动算差集，拉取缺失事务 - 如果之前用位点方式配过复制，先执行
STOP SLAVE; RESET SLAVE ALL;清掉旧的 relay log 和 master info，再CHANGE MASTER TO
初始数据同步必须保留 GTID 上下文
用 mysqldump 导出时漏掉 --set-gtid-purged=ON（默认值），会导致从库导入后 gtid_executed 为空，后续 START SLAVE 会重复执行已存在事务或卡住。
- 主库导出命令必须含：
mysqldump --all-databases --single-transaction --triggers --routines --events --set-gtid-purged=ON -u root -p > full.sql - 从库导入前，确保
gtid_mode=ON已生效，且没执行过任何写操作（否则gtid_executed会污染） - 导入后检查：
SELECT @@global.gtid_executed;应该和 dump 文件头里的SET @@GLOBAL.GTID_PURGED完全一致 - 如果 dump 里是
SET @@GLOBAL.GTID_PURGED='aaa:1-100';，而从库当前gtid_executed是空或不匹配，需手动设置：SET GLOBAL gtid_purged = 'aaa:1-100';（仅限导入后、启复制前）
server_id 和 server_uuid 冲突会导致复制静默失败
两个参数都必须唯一，但容易混淆：server_id 是配置文件里人工设的整数，用于复制链路标识；server_uuid 是 MySQL 启动时自动生成写入 auto.cnf 的字符串，不可人为修改——它才是 GTID 中 UUID:TID 的 UUID 部分。
- 检查
server_id：SELECT @@global.server_id;，主从不能相同 - 检查
server_uuid：SELECT @@global.server_uuid;，如果克隆虚拟机没清data/auto.cnf，多个实例 UUID 相同，GTID 事务会互相覆盖，复制看起来正常但数据不一致 - 若 UUID 冲突，删掉从库
data/auto.cnf，重启 mysqld，它会生成新 UUID -
server_uuid一旦生成就固定，即使改server_id也不影响它
最常被忽略的是 auto.cnf 文件的 UUID 冲突，以及 dump 导出时没加 --set-gtid-purged=ON。这两点不出问题时一切顺利，一出就是数据不一致，且日志里没有明显报错，只能靠比对 gtid_executed 和主库 gtid_purged 才能发现。
