binlog 是主从复制的数据源头
没有
binlog，MySQL 主从复制根本无法启动。它不是可选日志，而是主库向从库“发货”的唯一凭证——所有写操作（
INSERT、
UPDATE、
DELETE、
CREATE TABLE等）都必须先记进
binlog，从库的
IO Thread才能拉取并重放。 主库必须显式开启：
log-bin = mysql-bin，否则
SHOW BINARY LOGS为空，
CHANGE MASTER TO会报错
ERROR 1236 (HY000)
server-id必须非零且全局唯一；若为
0，主库虽能启
binlog，但从库连接时会被拒绝 日志文件名（如
mysql-bin.000001）和当前写入位置（
Position）由
SHOW MASTER STATUS返回，从库
CHANGE MASTER TO时必须严格匹配，差一位都会同步中断
mysqlbinlog 工具是诊断和恢复的底层抓手
mysqlbinlog不是复制流程中自动运行的组件，而是 DBA 手动介入时最常调用的命令行工具——它把二进制格式的
binlog解析成可读的 SQL 或事件描述，用于排查同步异常、定位误删时间点、或生成回滚语句。 查看某段日志内容：
mysqlbinlog --base64-output=DECODE-ROWS -v mysql-bin.000003（加
-v才能看到
Write_rows等行事件细节） 按时间点恢复：用
--start-datetime="2026-01-28 10:00:00"和
--stop-datetime截取区间，再导入到临时库比对 常见坑：
binlog_format = ROW时，直接
mysqlbinlog xxx | mysql会失败（含大量
SET @@SESSION.GTID_NEXT），需加
--skip-gtids或过滤掉 GTID 相关行
binlog_format 决定日志内容安全性和体积，ROW 是生产首选
三种格式不是性能高低之分，而是“能否正确还原数据”的底线判断。用
STATEMENT在涉及
NOW()、
UUID()、自增字段或非确定性函数时，从库执行结果可能和主库不一致——这种不一致不会报错，但数据已悄然漂移。
ROW：记录每一行变更前后的镜像（
Write_rows/
Update_rows），100% 可靠，但日志体积大、不可读；
mysqlbinlog输出全是十六进制，必须加
-v才能解析成伪 SQL
MIXED默认回退到
STATEMENT，只在检测到高风险函数时切
ROW，看似智能，实则埋下黑盒风险——你永远不知道哪条语句被悄悄切了模式 线上环境请硬性配置：
binlog-format = ROW，并在主从两端统一，避免因格式不一致导致从库解析失败（错误如
Unknown binlog format）
relay-log 是从库的“中间缓存”，不是可有可无的摆设
很多人以为
binlog直接发给从库 SQL 线程执行，其实中间必经
relay-log。它是从库本地的二进制日志副本，由
IO Thread拉取后写入，再由
SQL Thread顺序读取执行——这个缓冲层让网络抖动、主库重启等不影响从库最终一致性。 从库必须配置
relay-log = mysql-relay-bin，否则启动
START SLAVE时会报
Failed to initialize the master info structure
relay-log.info文件记录已执行到哪个
relay-log文件及位置，崩溃重启后靠它续断点；若手动删除该文件，从库会从头开始重放，造成重复写入 不建议开启
log-slave-updates除非要做级联复制（A→B→C），否则它会让从库也写
binlog，徒增 I/O 和磁盘压力 实际部署中最容易被跳过的，是确认
master.info和
relay-log.info的落盘时机——它们默认异步刷盘，主机断电可能导致位点丢失、重复执行。真正在意强一致的场景，得配
sync_relay_log = 1和
sync_relay_log_info = 1。
