能跑通gtid主从需三步：主从启用gtid模式并校验参数、主库创建mysql_native_password认证的复制用户、从库用source_auto_position=1配置并重置uuid；任一缺失均导致复制失败。
能跑通的GTID主从，核心就三步：主从都开gtid_mode=ON和enforce_gtid_consistency=ON，主库建兼容认证的复制用户，从库用CHANGE REPLICATION SOURCE TO指定源并启用GTID自动定位——跳过任何一步，SHOW REPLICA STATUS\G里必然报错。
确认GTID已真正启用（主从都要做）
MySQL 8.0 默认gtid_mode可能是OFF或ON_PERMISSIVE，不能只看安装版本。必须进MySQL执行：
SELECT @@gtid_mode, @@enforce_gtid_consistency;
两个值都必须是ON才算生效。常见错误是只改了my.cnf但没重启MySQL，或漏配enforce_gtid_consistency——后者不开启会导致CREATE USER或DML报错“GTID consistency violated”。
- 如果
gtid_mode不是ON，需按顺序执行：SET GLOBAL GTID_MODE = OFF_PERMISSIVE;→SET GLOBAL GTID_MODE = ON_PERMISSIVE;→SET GLOBAL GTID_MODE = ON; -
enforce_gtid_consistency必须设为ON，且只能在gtid_mode=ON后设置 - 修改
my.cnf后务必重启MySQL，systemctl restart mysqld，不能只FLUSH PRIVILEGES
创建能连通的复制用户（主库执行）
MySQL 8.0 默认认证插件是caching_sha2_password，但从库IO线程不支持它，会卡在Plugin caching_sha2_password could not be loaded。必须显式指定mysql_native_password：
CREATE USER 'repl'@'%' IDENTIFIED WITH mysql_native_password BY 'ReplPass123!';<br>GRANT REPLICATION SLAVE ON *.* TO 'repl'@'%';<br>FLUSH PRIVILEGES;
注意点：
- 不能用
root或其他已有用户复用，权限模型和认证插件会冲突 -
@'%'要明确写，不能省略；若只写@'localhost'，从库连不上 - 密码必须含大小写字母+数字+符号，否则
validate_password策略可能拒绝
从库配置server-id并重置复制状态（关键易错步）
从库my.cnf中server-id必须唯一且非0，但更关键的是：复制镜像或克隆虚拟机后，/var/lib/mysql/auto.cnf里的server_uuid会重复，导致GTID冲突、SQL线程拒绝执行。必须手动清理：
- 停复制：
STOP REPLICA; - 删旧状态：
RESET REPLICA ALL;（MySQL 8.0.23+ 推荐，清空master.info和relay-log.info） - 删UUID文件：
rm -f /var/lib/mysql/auto.cnf，再重启MySQL，让它自动生成新server_uuid - 确认
SELECT @@server_uuid;主从不一致
跳过RESET REPLICA ALL直接START REPLICA，大概率报Could not initialize master info structure或The slave is connecting using CHANGE MASTER TO ... which is not allowed when @@GLOBAL.GTID_MODE = ON。
用GTID方式执行CHANGE REPLICATION SOURCE TO（从库执行）
GTID模式下，不用记File和Position，但命令格式和参数名有硬性要求：
CHANGE REPLICATION SOURCE TO<br> SOURCE_HOST='192.168.1.100',<br> SOURCE_USER='repl',<br> SOURCE_PASSWORD='ReplPass123!',<br> SOURCE_AUTO_POSITION=1;
SOURCE_AUTO_POSITION=1是GTID启用的开关，缺一不可。常见错误：
- 写成
MASTER_AUTO_POSITION=1（旧语法，MySQL 8.0已废弃） - 漏掉
SOURCE_AUTO_POSITION=1，却还留着SOURCE_LOG_FILE和SOURCE_LOG_POS，会触发冲突报错 - 主库没提交过事务，
SELECT * FROM performance_schema.replication_applier_status_by_coordinator;里APPLYING_TRANSACTION为空，START REPLICA后Seconds_Behind_Master一直为NULL
启动后立刻查：SHOW REPLICA STATUS\G，重点盯三项：Replica_IO_Running: Yes、Replica_SQL_Running: Yes、Retrieved_Gtid_Set和Executed_Gtid_Set是否在增长。只要Executed_Gtid_Set为空，说明GTID根本没被识别或应用。
GTID真正的麻烦点不在配置，而在“看不见”的一致性约束：比如主库执行了CREATE TEMPORARY TABLE，或用了UUID()、NOW()这类非确定函数，GTID会直接拒绝同步。这些细节不会报错，但数据会在某次事务后悄然分裂——所以首次验证一定要用带自增主键+时间戳字段的INSERT+SELECT来回跑几轮，再比对SELECT COUNT(*)和SELECT MIN(id), MAX(id)。
