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