binlog是mysql主从复制的唯一数据源，必须开启log-bin并配置非零唯一server-id；其格式应统一设为ROW以确保数据一致性；relay-log是从库必需的中间缓存，需配置sync_relay_log=1等参数保障强一致。
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。