MySQL 主从复制不是“备份工具”，也不是“实时同步服务”，它本质是一套基于日志重放的异步数据分发机制——主库写 binlog，从库拉取并回放，中间有 relay-log 中转，两个线程（I/O Thread + SQL Thread）各司其职。
主从复制靠什么驱动？binlog
和 server-id
是硬门槛
没有
log-bin，主库连操作记录都留不下；没有唯一
server-id，从库启动时直接报错
ERROR 1236 (HY000)或无法注册到主库的 dump 线程列表里。这两项必须在
/etc/my.cnf的
[mysqld]段中显式配置，且重启生效。
log-bin=mysql-bin：文件名可自定义，但建议保持简洁，避免路径或特殊字符
server-id=137：不能为 0 或重复，常见做法是用 IP 最后一段（如
192.168.1.137→
137） 务必关闭
skip-networking，否则从库根本连不上主库
为什么 show slave status\G
里 Slave_IO_Running: No
？
这是最常卡住的第一步，原因几乎都出在网络或权限上，而非配置语法：
主库没开远程访问：grant replication slave on *.* to 'repl'@'192.168.1.%' identified by 'xxx';后漏了
flush privileges;防火墙拦了 3306（或自定义端口），
telnet master_ip 3306连不通就不用往下试
change master to里写的
master_host是域名但未被从库解析，建议一律用 IP 主库
bind-address写死为
127.0.0.1，导致只监听本地 —— 应改为
0.0.0.0或具体内网 IP
binlog_format=row
为什么现在是默认推荐？
因为
STATEMENT模式下，像
now()、
sysdate()、自增 ID 分配、触发器等，在从库重放时极易产生主从不一致。而
ROW格式记录的是“哪一行变了、变成什么样”，不依赖上下文，复制更可靠。 5.7+ 默认就是
ROW，但老环境迁移时务必确认：
select @@binlog_format;切勿在运行中动态改
binlog_format，必须重启 MySQL 生效
MIXED是折中方案，但实际行为难预测，生产环境建议明确选
ROW
真正容易被忽略的，是时间同步和 relay-log 自动清理——如果主从服务器时间差超过 30 秒，
pt-heartbeat监控会误报延迟；而
relay_log_purge=ON若被意外关掉，中继日志会越积越多，最终撑爆磁盘。
