主从复制靠什么同步数据？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';<br>GRANT REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO 'repl'@'%';<br>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<br> SOURCE_HOST='192.168.1.10',<br> SOURCE_USER='repl',<br> SOURCE_PASSWORD='strong_pass_2026',<br> SOURCE_LOG_FILE='binlog.000004',<br> SOURCE_LOG_POS=157;<br>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 写到一半未刷盘，从库拉到半截事务，可能直接卡死。这些都不是配置漏了，而是复制机制本身的约束。
