什么是mysql主从复制_mysql复制基础概念解析

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 statusG 里 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 若被意外关掉，中继日志会越积越多，最终撑爆磁盘。