binlog 是 MySQL 记录数据变更的二进制事件日志，为主从复制唯一数据源；必须启用 log-bin 才能启动复制，且需配置为 ROW 格式并精准定位事务起点位点。
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;
记下结果后，立刻
SHOW MASTER STATUS;UNLOCK TABLES（锁表时间越短越好） - 更稳妥的做法（尤其大库）：用
mysqldump --single-transaction --master-data=2导出，其中--master-data=2会在 dump 文件开头写死CHANGE MASTER TO语句，包含精确位点
真正难的从来不是配置命令，而是理解 binlog 不是“日志备份”，而是“数据变更的唯一真相链”——它被删了，主从就断；它格式错了，从库就瞎执行；它位点偏了，数据就再也对不上。别信“先跑起来再调”，主从一旦错位，追平成本远高于初始化重搭。
