主从复制靠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 写到一半未刷盘，从库拉到半截事务，可能直接卡死。这些都不是配置漏了，而是复制机制本身的约束。
