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:
- 所有节点都要设唯一
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 集合:
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理(CRM)系统设计、评审、优化或生成数据库模式时,应使用此项技能。
- 主库执行:
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 ;导入后执行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 元信息,或者设的值比主库实际已提交的少,后面所有同步都会卡在第一个事务。










