主从复制前必须确认的 4 个状态
主从同步失败，80% 源于基础状态没对齐。别急着改
my.cnf，先在主库和从库分别执行：
SHOW MASTER STATUS;（主库）——确认
File和
Position非空，且
Executed_Gtid_Set有值（若启用了 GTID）
SHOW SLAVE STATUS\G（从库）——重点看
Slave_IO_Running和
Slave_SQL_Running是否都为
Yes，
Seconds_Behind_Master是否持续增长
SELECT @@server_id;—— 主从必须不同，否则复制线程直接拒绝启动
SELECT @@log_bin, @@binlog_format;—— 主库
log_bin必须为
ON，
binlog_format建议统一用
ROW（避免语句级复制在从库因函数/临时表等导致不一致）
配置文件里最容易写错的 3 个参数
my.cnf中几个关键项看似简单，但拼写、作用域或默认值陷阱极多：
server-id：必须是整数（如
1或
2），不能是
1.0或字符串
"1"；且仅在
[mysqld]段生效，
[client]段无效
log-bin：值不是布尔，而是日志文件前缀（如
log-bin = /var/lib/mysql/mysql-bin），路径需 MySQL 进程有写权限；若只写
log-bin不带值，MySQL 会用主机名自动命名，但迁移时易引发路径不一致问题
binlog-do-db或
replicate-do-db：慎用！它们不支持通配符，且对跨库语句（如
INSERT INTO db2.t SELECT * FROM db1.t）行为不可靠；更安全的做法是用
replicate-wild-do-table = db1.%
GTID 模式下 CHANGE MASTER TO 的写法差异
启用 GTID（
gtid_mode=ON+
enforce_gtid_consistency=ON）后，不能再用传统
MASTER_LOG_FILE/
MASTER_LOG_POS，必须用
MASTER_AUTO_POSITION=1：
CHANGE MASTER TO MASTER_HOST='192.168.1.10', MASTER_USER='repl', MASTER_PASSWORD='xxx', MASTER_PORT=3306, MASTER_AUTO_POSITION=1;
如果从库已有旧复制关系，执行前必须先
STOP SLAVE;并
RESET SLAVE ALL;（注意是
ALL，否则
gtid_purged可能残留冲突值）；主库导出时也要用
mysqldump --set-gtid-purged=ON，否则从库恢复后无法自动定位同步起点。
从库延迟高时优先检查的 3 类瓶颈
Seconds_Behind_Master持续 > 60 秒，不要立刻调大
slave_parallel_workers： 单线程 SQL 回放卡住：查
SHOW PROCESSLIST看
State是否长期停留在
Updating或
Creating sort index，说明某条大事务（如
ALTER TABLE或未加索引的
DELETE）正在阻塞整个 SQL 线程 磁盘 I/O 跟不上：用
iostat -x 1观察
%util是否持续 > 90%，尤其是从库的
mysql-bin所在磁盘；
sync_binlog=1和
innodb_flush_log_at_trx_commit=1在从库可酌情改为
0或
2（牺牲少量安全性换吞吐） 网络抖动导致 IO 线程反复重连：检查
Seconds_Behind_Master是否周期性归零又跳升，配合
tcpdump抓包看是否有频繁
RST；可在主库设置
slave_net_timeout=60，从库设
master_connect_retry=30避免重试风暴
真正难处理的是混合了大事务和高并发写入的场景——这时候单靠配置调优收效甚微，得拆分业务逻辑或引入中间件做读写分流。
