新手能跑通但不可靠，必须修改server-id、binlog-format=row、skip_slave_start=0三项配置，并通过实际数据插入与查询验证同步有效性。
新手能跑通，但“能连上”不等于“能稳用”
可以部署，但默认配置下极易出现同步中断、数据不一致、主从延迟飙升等问题。很多教程只教到 START SLAVE; 后 Slave_IO_Running 和 Slave_SQL_Running 都显示 Yes 就算成功——这其实是假象。真实环境中，哪怕只是主库执行一条没加 WHERE 的 UPDATE，或从库重启后 relay log 损坏，都会让复制静默失败。
必须改掉的三个默认配置项
MySQL 安装完不开任何配置就启主从，90% 会在 24 小时内出问题。以下三项不是“可选优化”，而是新手起步前必须显式设置：
-
server-id：主库和从库必须不同且为非零整数（如主库设1，从库设2），否则从库拒绝连接，错误提示是ERROR 1236 (HY000): Could not find first log file name in binary log index file -
binlog-format=ROW：默认是STATEMENT，在有函数、临时表、非确定性 SQL 时会丢数据；ROW模式记录每行变更，主从一致性才有保障 -
skip_slave_start=0（或直接删掉该行）：有些旧版包默认开启，导致从库重启后自动停止复制，必须手动START SLAVE，极易被忽略
验证同步是否真生效，别只看 SHOW SLAVE STATUS\G
光看 Seconds_Behind_Master 是 0 不够，它可能长期卡在 0 却已停止同步（比如 SQL 线程因唯一键冲突被 halt）。真正有效的验证方式是：
- 主库建测试表：
CREATE TABLE test_sync (id INT PRIMARY KEY, ts TIMESTAMP DEFAULT CURRENT_TIMESTAMP); - 主库插入：
INSERT INTO test_sync (id) VALUES (1); - 立刻在从库查：
SELECT * FROM test_sync;—— 必须看到刚插的那条，且ts值与主库基本一致（误差 - 再试一次带更新的：
UPDATE test_sync SET id = 2 WHERE id = 1;，确认从库也更新成功
如果某次更新没同步过去，SHOW SLAVE STATUS\G 中的 Last_SQL_Error 字段才会暴露真实原因，比如 Duplicate entry '2' for key 'PRIMARY'。
防火墙、权限、时钟这三个“隐形杀手”最常卡住新手
它们不出现在任何 MySQL 错误日志里，但会让 CHANGE MASTER TO 直接失败或连接超时：
- 主库防火墙必须放行 3306 端口，且允许从库 IP（不能只写
%，测试环境可暂用，但要清楚风险） - 复制账号必须用
GRANT REPLICATION SLAVE ON *.* TO 'repl'@'172.20.10.124';显式授权，CREATE USER后不GRANT就连不上，报错是Access denied for user 'repl'@'172.20.10.124' - 主从服务器系统时间差超过 5 秒，会导致基于 GTID 的复制初始化失败，或
Seconds_Behind_Master显示负值；用ntpdate -q pool.ntp.org校准后再启动复制
真正难的不是配置本身，而是你得知道哪些地方“看起来没问题，其实已经埋雷”。比如 relay-log 文件路径没写绝对路径，从库重启后找不到中继日志；又比如主库 max_binlog_size 设太小，频繁切日志导致从库 IO 线程反复重连。这些细节，文档不会标红，但线上一出事，全靠你翻 error.log 里的蛛丝马迹。
