mysql binlog是什么_mysql主从复制基础

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 不是“日志备份”，而是“数据变更的唯一真相链”——它被删了，主从就断；它格式错了，从库就瞎执行；它位点偏了，数据就再也对不上。别信“先跑起来再调”，主从一旦错位，追平成本远高于初始化重搭。