能跑通的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 实际没开起来。
