能跑通的gtid主从复制核心三步:主从均需在my.cnf[mysqld]段显式配置gtid_mode=on与enforce_gtid_consistency=on并重启;主库用mysql_native_password插件创建replication slave权限用户;从库执行change replication source to ... source_auto_position=1后start replica,并通过show replica status\g验证replica_io_running、replica_sql_running及source_uuid等关键字段。

能跑通的 GTID 主从复制,核心就三步:主从都开 gtid_mode=ON 且设好 enforce_gtid_consistency=ON,主库建好兼容认证的复制用户,从库用 CHANGE REPLICATION SOURCE TO ... MASTER_AUTO_POSITION = 1 接入并 START REPLICA。中间任何一环卡住,SHOW REPLICA STATUS\G 里必有明确错误字段,比如 Retrieval_Gtid_Set 为空、Source_UUID 为 NULL 或报 Plugin 'caching_sha2_password' could not be loaded——这些都不是配置“差不多就行”的信号。
主从必须同时开启 GTID 并强制一致性
MySQL 8.0 默认不启用 GTID,只开 log_bin 不等于就能走 GTID 复制。必须在 my.cnf 的 [mysqld] 段显式写入:
gtid_mode = ON enforce_gtid_consistency = ON
这两项必须同时生效,缺一不可。前者让每个事务带上唯一 UUID:TRX_ID 标识,后者阻止任何不支持 GTID 的语句(如 CREATE TABLE ... SELECT、非确定性函数)被提交,否则复制会直接拒绝启动。
常见错误是只改了主库、忘了从库;或动态执行 SET GLOBAL gtid_mode = ON ——这在 MySQL 8.0 中会被拒绝,必须重启 mysqld 才生效。
验证是否真正启用:SELECT @@gtid_mode, @@enforce_gtid_consistency; 返回值必须都是 ON。
复制用户必须用 mysql_native_password 插件
MySQL 8.0 默认认证插件是 caching_sha2_password,但从库的 I/O 线程在连接主库时无法加载该插件,会报错:
Plugin caching_sha2_password could not be loaded
所以主库上创建复制用户时,必须显式指定插件:
CREATE USER 'repl'@'%' IDENTIFIED WITH mysql_native_password BY 'ReplPass123!';
再授权:
GRANT REPLICATION SLAVE ON *.* TO 'repl'@'%';
注意:FLUSH PRIVILEGES; 不是可选步骤,漏掉会导致权限不生效;'%' 要匹配从库实际发起连接的 IP,生产环境建议限定为具体内网段(如 '192.168.1.%')。
从库 CHANGE REPLICATION SOURCE TO 必须带 MASTER_AUTO_POSITION = 1
GTID 模式下,不能再用传统方式指定 MASTER_LOG_FILE 和 MASTER_LOG_POS,否则会报错:
When @@GLOBAL.GTID_MODE = ON, the START SLAVE statement cannot use UNTIL_SQL_BEFORE_GTIDS or UNTIL_SQL_AFTER_GTIDS.
正确命令是:
CHANGE REPLICATION SOURCE TO SOURCE_HOST='192.168.1.100', SOURCE_PORT=3306, SOURCE_USER='repl', SOURCE_PASSWORD='ReplPass123!', SOURCE_AUTO_POSITION = 1;
注意关键词变化:MASTER_* 已全部改为 SOURCE_*(MySQL 8.0.23+),旧命令会语法报错;SOURCE_AUTO_POSITION = 1 是开关,不是可选项。
执行前确保从库已清空旧状态:STOP REPLICA; RESET REPLICA ALL;(MySQL 8.0.23+ 推荐),否则可能因残留的 master.info 冲突导致 Retrieval_Gtid_Set 为空。
验证时重点盯住三个字段:Replica_IO_Running、Replica_SQL_Running、Seconds_Behind_Master
运行 SHOW REPLICA STATUS\G 后,只看这三项:
-
Replica_IO_Running: Yes→ I/O 线程连上了主库、正在拉取 binlog -
Replica_SQL_Running: Yes→ SQL 线程正在重放 relay log -
Seconds_Behind_Master: 0(稳定几秒后不再跳变)→ 数据追平
如果前两者是 Connecting 或 No,先查 Source_IO_State 和 Last_IO_Error;如果是 Seconds_Behind_Master 持续增长,大概率是主库写了大事务(如全表 UPDATE)、从库磁盘慢或 CPU 饱和,而不是配置问题。
容易忽略的一点:Source_UUID 字段必须是非空字符串,且与主库的 SELECT @@server_uuid; 一致。若为 NULL,说明 CHANGE REPLICATION SOURCE TO 没生效,或者主库的 gtid_mode 实际没开起来。











