MySQL 8.0+中GTID并非开箱即用，必须同时满足：gtid_mode=ON、enforce_gtid_consistency=ON、binlog_format=ROW、log_bin=ON及唯一server_id，缺一不可；主从均需配置并重启生效。
MySQL 8.0+ 默认支持 GTID，但gtid_mode=ON不是开箱即用的——它依赖几个强约束条件，漏掉任意一个都会在START SLAVE时报错或复制中断。直接上配置会踩坑，必须先确认基础状态。
检查 MySQL 版本与当前 GTID 状态
GTID 在 5.6 引入，但 5.7 才真正稳定，8.0 起默认启用部分相关变量。别信“版本够新就自动 OK”，得实查：
-
SELECT VERSION();确认 ≥ 5.7.6（最低安全线） -
SHOW VARIABLES LIKE 'gtid_mode';必须是ON，不是OFF_PERMISSIVE或ON_PERMISSIVE -
SHOW VARIABLES LIKE 'enforce_gtid_consistency';必须是ON，否则START SLAVE直接拒绝 -
SHOW VARIABLES LIKE 'log_bin';主库必须为ON；从库可关，但建议开启以便后续角色切换
主库和从库的 my.cnf 必填配置项
GTID 复制不是“改一个参数就行”，它要求主从两端都满足一致性约束。以下配置必须写进 /etc/my.cnf（或 my.ini Windows）并重启 mysqld：
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 所有节点都要设唯一
server-id，比如主库server-id=1，从库server-id=2；重复会导致 IO 线程拒绝连接 - 主库必须启用：
log-bin=mysql-bin、gtid_mode=ON、enforce_gtid_consistency=true - 从库也必须启用：
gtid_mode=ON、enforce_gtid_consistency=true；如果要支持主动切为主库，还得加log-bin和log-slave-updates=ON - 不要手动配
relay-log文件名，GTID 模式下 MySQL 会自动生成，硬指定反而容易出错
创建复制用户并初始化从库数据
GTID 不接受“从某个 binlog 文件位置开始同步”，它只认事务 ID。所以从库初始化必须基于一致快照，且记录当时的 GTID 集合：
- 主库执行：
FLUSH TABLES WITH READ LOCK;→SHOW MASTER STATUS;记下Executed_Gtid_Set值（不是 File/Position） - 用
mysqldump --all-databases --single-transaction --triggers --routines --set-gtid-purged=ON > full.sql导出（--set-gtid-purged=ON关键！否则 dump 里没 GTID SET） - 从库导入：
mysql ；导入后执行 <code>SET GLOBAL gtid_purged = 'xxx:1-100';（值来自主库SHOW MASTER STATUS的Executed_Gtid_Set） - 最后才运行：
CHANGE MASTER TO MASTER_HOST='xxx', MASTER_USER='repl', MASTER_PASSWORD='xxx', MASTER_AUTO_POSITION=1;—— 注意是MASTER_AUTO_POSITION=1，不是MASTER_LOG_FILE那套
验证复制状态与常见失败点
跑完 START SLAVE; 后，别只看 Slave_IO_Running 和 Slave_SQL_Running 是 Yes 就以为成了。GTID 下真正的健康指标是：
-
SHOW SLAVE STATUS\G中Retrieved_Gtid_Set和Executed_Gtid_Set应该持续增长，且后者应包含前者 - 若出现
error_code: 1236，大概率是gtid_purged设少了，或者主库 binlog 被PURGE BINARY LOGS清掉了一段，导致从库要的 GTID 找不到 - 若
Seconds_Behind_Master一直非 0，检查主库是否用了非事务引擎（如 MyISAM），enforce_gtid_consistency=true会阻止这类语句执行，但有些旧应用仍可能绕过 - 从库执行
STOP SLAVE; START SLAVE;后延迟突增？说明 relay log 没清干净，GTID 模式下不建议手动删relay-log文件，应靠RESET SLAVE ALL;重置
GTID 最容易被忽略的其实是初始化阶段的 --set-gtid-purged=ON 和 SET GLOBAL gtid_purged 这两步——导出时没带 GTID 元信息，或者设的值比主库实际已提交的少，后面所有同步都会卡在第一个事务。
