binlog是 MySQL 的二进制日志，本质是一组按时间顺序写入的、记录所有数据变更（
INSERT、
UPDATE、
DELETE）的事件文件，不是 SQL 文本快照，而是结构化的
event流——它是主从复制的唯一数据源，没有它，从库根本不知道主库发生了什么。
为什么必须开 log-bin
才能做主从？
主从复制是「单向拉取 + 回放」机制：从库的
I/O Thread连上主库后，只做一件事——请求主库
binlog中从某个位置（
File+
Position或 GTID）开始的新事件。如果主库没开
log-bin，就根本没有可读的日志，
CHANGE MASTER TO会直接报错
ERROR 1236 (HY000): Could not find first log file name in binary log index file。
log-bin必须配置在
[mysqld]段，且不能带路径（如
log-bin = /var/lib/mysql/binlog会失败），推荐用
log-bin = mysql-bin开启后，MySQL 自动创建
mysql-bin.000001等序列文件，以及
mysql-bin.index索引文件 从库可以不开
log-bin（除非你要让它当其他库的主库），但开了不报错，只是多占磁盘
binlog_format
选 STATEMENT
、ROW
还是 MIXED
？
这个参数决定日志里记的是“SQL 语句”还是“行变更”，直接影响复制安全性和可观测性。线上环境几乎一律用
ROW，不是因为性能好，而是因为「不会丢数据、不会错行、不惧非确定函数」。
STATEMENT：记原始 SQL，比如
UPDATE t SET c=NOW()。问题在于：主从系统时间不同 → 从库写入时间戳和主库不一致；含
UUID()、
USER()等函数时，从库执行结果必然不同 → 复制中断
ROW：记每一行的前镜像（before image）和后镜像（after image）。即使语句含随机函数，只要主库改了哪几行，从库就精准改哪几行。缺点是日志体积大，且
mysqlbinlog输出不可读（全是十六进制）
MIXED：默认行为，自动降级 —— 大部分时候用
STATEMENT，遇到不安全函数时切到
ROW。看似聪明，但切换逻辑黑盒，故障时难以归因，不建议新环境使用
实操建议：
binlog_format = ROW写死在主库配置中，并在从库也配成一样（避免隐式转换引发不一致）。
主从复制启动时，MASTER_LOG_POS
怎么确定才不丢数据？
这是最容易出错的一步：位置点错了，轻则漏同步，重则主键冲突或主从数据分裂。关键原则是——位置点必须对应一个完整事务的起点，不能停在中间。
全新主库（无业务流量）：直接SHOW MASTER STATUS，取
File和
Position（通常是
mysql-bin.000001+
154） 已有业务的主库：不能直接用
SHOW MASTER STATUS当前值！要先锁表获取一致性位点：
FLUSH TABLES WITH READ LOCK;<br>SHOW MASTER STATUS;记下结果后，立刻
UNLOCK TABLES（锁表时间越短越好） 更稳妥的做法（尤其大库）：用
mysqldump --single-transaction --master-data=2导出，其中
--master-data=2会在 dump 文件开头写死
CHANGE MASTER TO语句，包含精确位点
真正难的从来不是配置命令，而是理解
binlog不是“日志备份”，而是“数据变更的唯一真相链”——它被删了，主从就断；它格式错了，从库就瞎执行；它位点偏了，数据就再也对不上。别信“先跑起来再调”，主从一旦错位，追平成本远高于初始化重搭。
