gtid主从复制必需的五项硬性参数是：server_id、log_bin（主库必须，从库建议关闭）、gtid_mode=on、enforce_gtid_consistency=on、binlog_format=row；缺一不可。
GTID主从复制能跑起来，核心就三件事：主从都开gtid_mode=ON、server_id必须唯一、从库用MASTER_AUTO_POSITION=1启动复制。其他配置漏一项，Slave_IO_Running或Slave_SQL_Running就会卡在No。
主库和从库的my.cnf必须加哪些参数？
不是所有参数都可选——以下五项是硬性要求，缺一不可：
-
server_id：主库设为1，从库至少为2，且整个集群不能重复（哪怕跨机房） -
log_bin：主库必须开启，从库建议关闭（除非做级联复制） -
gtid_mode=ON：主从都要显式设为ON，不能只靠默认值（MySQL 5.7+ 默认可能是OFF） -
enforce_gtid_consistency=ON：主从都得开，否则gtid_mode=ON会被拒绝生效 -
binlog_format=ROW：GTID强制要求，设成MIXED或STATEMENT会导致START SLAVE报错
常见坑：log_slave_updates只在从库需要级联复制时才开；skip_slave_start=ON建议加在从库配置里，避免重启后自动拉起错误复制流。
为什么CHANGE MASTER TO必须带MASTER_AUTO_POSITION=1？
这是GTID和传统复制最根本的分水岭。不加它，MySQL会按老方式找MASTER_LOG_FILE和MASTER_LOG_POS，而GTID模式下这些字段压根没意义，强行指定反而触发ERROR 1777 (HY000)。
正确写法只有这一种：
CHANGE MASTER TO MASTER_HOST='192.168.1.10', MASTER_USER='repl', MASTER_PASSWORD='SecurePass123!', MASTER_AUTO_POSITION=1;
注意：MASTER_AUTO_POSITION=1必须是整数值1，写成ON或TRUE会语法报错；执行前确保从库gtid_executed为空（即没导入过数据），否则可能跳过部分事务。
START SLAVE后状态异常，怎么快速定位？
别急着查日志，先看这两行：
SHOW SLAVE STATUS\G
重点盯住：
-
Slave_IO_Running: Yes但Slave_SQL_Running: No→ 通常是SQL线程执行事务失败，看Last_SQL_Error，大概率是主从表结构不一致或GTID已存在（比如从库手动插入过数据） - 两个都是
No→ IO线程根本连不上主库，检查Master_Host是否可达、防火墙端口（默认3306）、复制用户权限、主库bind_address是否监听了对应网卡 -
Retrieved_Gtid_Set为空 → IO线程没拉到任何GTID，基本确认网络或认证问题 -
Executed_Gtid_Set和Retrieved_Gtid_Set不重叠 → 主库binlog被清过，从库缺失前置GTID，此时RESET SLAVE再重搭是最快解法
特别注意：Seconds_Behind_Master为NULL不一定代表延迟，更可能是SQL线程已停止，得结合Slave_SQL_Running一起看。
初始化从库数据时，mysqldump要加什么关键参数？
用mysqldump导出主库全量数据时，如果漏掉这两个参数，从库CHANGE MASTER TO会直接失败：
-
--set-gtid-purged=ON（MySQL 5.7.6+ 默认行为，但显式写出更安全）：让dump文件头部包含SET @@GLOBAL.GTID_PURGED语句，告诉从库“我带的这些数据对应哪些GTID” -
--single-transaction：保证一致性快照，避免锁表；但注意它对非InnoDB表无效，混合引擎库需配合--lock-all-tables
导出后，在从库执行前，先清空gtid_executed：
RESET MASTER;
再导入dump文件。否则SET @@GLOBAL.GTID_PURGED会因GTID集合冲突而报错ERROR 1840 (HY000)。
GTID复制真正的麻烦不在配置，而在「一致性边界」——比如主库删库后binlog被expire_logs_days自动清理，从库就再也追不回来了；又比如人为在从库写了数据，gtid_executed就污染了，后续同步必然断裂。这些点没法靠脚本全自动兜底，得靠运维对GTID生命周期有真实手感。
