MySQL主从复制是基于binlog日志重放的异步数据分发机制，依赖log-bin和唯一server-id驱动，需配置网络、权限、ROW格式及时间同步等关键项。
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 若被意外关掉，中继日志会越积越多，最终撑爆磁盘。
