mysql主从复制日志文件的核心就是binlog，也称为二进制日志。它记录了数据库所有更改数据的操作，是实现主从同步和数据恢复的基础。了解binlog机制，有助于我们排查同步延迟、配置复制链路以及做故障恢复。
binlog在主从复制中的作用
在主从架构中，主库把每一条写操作以事件形式写入binlog。从库上的IO线程连接主库，拉取binlog并保存到本地中继日志，再由SQL线程回放，从而保证从库数据与主库一致。没有binlog，主从复制就无法获得变更数据源。
- 数据同步：从库依赖binlog获取增量变更
- 断点续传：通过文件名和位置点记录同步进度
- 数据恢复：可通过mysqlbinlog工具重放历史操作
binlog的三种格式
binlog支持多种记录格式，不同格式影响日志体积和复制安全性。
| 格式 | 说明 | 特点 |
|---|---|---|
| STATEMENT | 记录SQL语句 | 日志小，但某些函数可能导致主从不一致 |
| ROW | 记录行级变更 | 安全但日志较大，推荐生产使用 |
| MIXED | 混合模式 | 由mysql自动选择上述两种 |
binlog写入机制
事务执行过程中，binlog先写入内存缓冲区，事务提交时按参数sync_binlog控制刷盘策略。当设置为1时，每次提交都刷盘，最安全但性能略低。
查看binlog文件列表
可以使用如下命令查看当前主库已有的binlog文件：
-- 查看binlog文件列表 SHOW BINARY LOGS; -- 查看当前正在写入的binlog SHOW MASTER STATUS;
使用mysqlbinlog解析日志
在服务器上可用mysqlbinlog工具将二进制内容转为文本，便于排查从库同步失败原因。
# 将指定binlog解析为文本 mysqlbinlog -v /var/lib/mysql/mysql-bin.000012 > binlog.txt # 按时间区间解析 mysqlbinlog --start-datetime="2023-01-01 00:00:00" --stop-datetime="2023-01-02 00:00:00" mysql-bin.000012
主从复制基本配置示例
主库需要开启binlog并配置唯一server-id，从库指定主库地址及同步起点。
# 主库配置文件 my.cnf [mysqld] server-id=1 log-bin=mysql-bin binlog-format=ROW
-- 从库设置主库信息 CHANGE MASTER TO MASTER_HOST='192.168.0.1', MASTER_USER='repl', MASTER_PASSWORD='password', MASTER_LOG_FILE='mysql-bin.000012', MASTER_LOG_POS=154; START SLAVE;
常见注意事项
若发现从库延迟严重，可检查主库是否大量写入、网络是否稳定，以及从库SQL线程是否遇到锁等待。此外，binlog会占用磁盘空间，应通过expire_logs_days或二进制日志清理命令定期删除旧文件。
定期监控binlog大小和复制状态，是保障mysql主从集群稳定运行的关键。