主从复制靠Binlog+Relay Log同步数据：主库写binlog，从库I/O Thread拉取存为relay log，SQL Thread串行回放；需开启binlog（row格式）、唯一server-id、专用复制账号，并正确配置CHANGE REPLICATION SOURCE TO。

主从复制靠什么同步数据？Binlog + Relay Log 是核心链路

MySQL 主从复制不是“实时镜像”，而是基于日志的异步重放：主库把所有写操作记进 binlog，从库用 I/O Thread 拉取并存为 relay log，再由 SQL Thread 逐条执行。整个过程不依赖网络直连同步内存或磁盘块，所以延迟、断连、重试都天然内建在这一机制里。

• binlog 必须开启，且格式建议设为 row（binlog_format = 'row'），避免函数（如 NOW()、UUID()）、自增主键冲突等导致主从不一致
• 从库写 relay log 是顺序追加，不校验语义；SQL Thread 是单线程串行回放——这意味着高并发写入主库时，从库容易积压，Seconds_Behind_Master 可能持续上涨
• server-id 必须全局唯一，否则从库连接主库会被拒绝，错误提示类似：ERROR 1236 (HY000): Got fatal error 1236 from master when reading data from binary log

配置前必须确认的三件事

很多“配了不生效”问题，其实卡在最基础的检查项上，不是语法错，而是状态没到位。

• 主库是否真正启用了 binlog？运行 SHOW VARIABLES LIKE 'log_bin';，返回 ON 才算生效（仅改配置文件不重启 MySQL 无效）
• 主库是否设置了 server-id？且不能为 0 或 1（MySQL 8.0+ 默认是 1，若多实例共存极易撞车）
• 主库是否创建了专用复制账号？权限必须包含 REPLICATION SLAVE 和 REPLICATION CLIENT，例如：

  CREATE USER 'repl'@'%' IDENTIFIED BY 'strong_pass_2026';
  GRANT REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO 'repl'@'%';
  FLUSH PRIVILEGES;

启动复制的关键命令：CHANGE REPLICATION SOURCE TO（MySQL 8.0.23+）

旧版用 CHANGE MASTER TO，新版已弃用，硬切会报错。注意参数名、引号、逗号位置——少一个单引号或拼错 SOURCE_LOG_FILE 就直接 IO_THREAD 启动失败。

• 先在主库查当前日志位点：SHOW MASTER STATUS;，拿到 File 和 Position 值（如 binlog.000004, 157）
• 在从库执行（注意替换值）：

  CHANGE REPLICATION SOURCE TO
    SOURCE_HOST='192.168.1.10',
    SOURCE_USER='repl',
    SOURCE_PASSWORD='strong_pass_2026',
    SOURCE_LOG_FILE='binlog.000004',
    SOURCE_LOG_POS=157;
  START REPLICA;

• 验证是否跑起来：SHOW REPLICA STATUS\G，重点看 Replica_IO_Running 和 Replica_SQL_Running 是否都是 Yes，以及 Seconds_Behind_Master 是否在收敛

为什么刚配好就报 “Could not find first log file name in binary log index file”？

这是新手最高频的报错，根本原因：从库请求的 SOURCE_LOG_FILE 在主库上已不存在（被 PURGE BINARY LOGS 清掉，或主库重启后生成了新文件名）。

• 不要盲目删 mysql-bin.index 或改配置骗过检查——这会导致数据跳变或中断
• 正确做法：主库执行 SHOW BINARY LOGS; 看现存日志列表，选最新一个文件作为起点；如果从库完全空白，可考虑用 mysqldump --master-data=2 导出主库快照 + 位点，再导入从库，避免从头追日志
• 长期运维建议：主库设置 expire_logs_days = 7（而非默认 0），既防磁盘爆满，也给从库留足追赶窗口

配置本身不难，难的是理解每个环节的依赖和容错边界。比如 SQL Thread 报错停摆后不会自动重试，必须人工 SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 1（谨慎！）或找 GTID 位点重置；又比如主库 crash 后 binlog 写到一半未刷盘，从库拉到半截事务，可能直接卡死。这些都不是配置漏了，而是复制机制本身的约束。