binlog和redo log是MySQL里最重要的两份日志，一个工作在Server层，一个工作在InnoDB存储引擎层，二者职责不同却紧密配合。binlog负责记录所有涉及数据变更的逻辑操作，是主从复制和数据恢复的基础；redo log则通过WAL机制保证事务提交后数据不会因宕机丢失。很多初学者在搭建主从架构时发现同步失败，或者想排查数据误删问题时，才发现这两个日志根本没有开启。这篇文章就从配置入手，手把手教你把binlog和redo log设置到位。
先搞清楚binlog和redo log的区别
binlog是MySQL Server层的日志，它以事件的形式记录所有对数据库产生变更的操作，包括INSERT、UPDATE、DELETE以及DDL语句，纯粹的SELECT查询不会记录。binlog有三种格式：STATEMENT记录原始SQL语句，ROW记录每一行数据的变更前后镜像，MIXED则由MySQL自动在两者之间切换。主流做法是使用ROW格式，虽然日志量更大，但主从复制的准确性最高，能避免STATEMENT格式下某些函数（如NOW()、UUID()）导致的复制不一致问题。
redo log是InnoDB引擎独有的物理日志，它记录的是某个数据页被修改之后的物理结果。采用WAL（Write-Ahead Logging）机制，事务提交时只需保证redo log落盘，脏页可以稍后慢慢刷回磁盘，这就把随机写转换成了顺序写，性能大幅提升。当MySQL发生崩溃重启时，InnoDB会重放redo log中已提交但未刷盘的部分，这就是所谓的崩溃恢复能力。简单来说：binlog回答的是“执行了什么操作”，redo log回答的是“数据页被改成了什么样”。
两份日志通过两阶段提交机制保持一致：事务提交时先写redo log并标记为prepare状态，再写binlog，最后把redo log标记为commit状态。如果中间某个环节宕机，恢复时就能根据状态判断事务到底该提交还是回滚，避免主库和从库数据出现分歧。
binlog的配置方法
binlog默认是关闭的（MySQL 8.0之前），需要在配置文件my.cnf中显式开启。Linux下配置文件通常位于/etc/my.cnf，Windows下则是安装目录中的my.ini。在[mysqld]配置段中加入如下参数：
[mysqld] # 开启binlog，MySQL 8.0默认已开启 log-bin=mysql-bin # 使用ROW格式，保证主从复制安全 binlog_format=ROW # binlog过期天数，超过后自动清理，MySQL 8.0使用binlog_expire_logs_seconds expire_logs_days=7 # 服务端唯一标识，主从架构中每台机器必须不同 server-id=1 # 每次事务提交都立即刷盘，最安全但性能略降 sync_binlog=1 # 记录哪些库，不配置则记录全部 # binlog-do-db=testdb # 忽略哪些库 binlog-ignore-db=mysql,information_schema # 单个binlog文件最大体积，超过后自动切换新文件 max_binlog_size=256M
修改完成后重启MySQL服务生效。需要特别说明sync_binlog参数：设为1表示每次事务提交都把binlog缓冲区刷到磁盘，配合后面redo log的innodb_flush_log_at_trx_commit=1，就是所谓的“双1配置”，能最大程度保证数据不丢失，金融类业务推荐这么设置。如果追求性能，可以设为0或100，代价是宕机时可能丢失少量事务。
验证配置是否生效，可以登录MySQL后执行如下命令：
-- 查看binlog是否开启及日志位置 SHOW VARIABLES LIKE 'log_bin%'; -- 查看当前日志格式 SHOW VARIABLES LIKE 'binlog_format'; -- 查看所有binlog文件列表 SHOW BINARY LOGS; -- 查看binlog中的事件内容 SHOW BINLOG EVENTS IN 'mysql-bin.000001';
日常运维中还会用到几个刷新命令：FLUSH LOGS或RESET MASTER可以强制切换到新的binlog文件，后者还会清空所有历史日志，操作前务必确认从库已经消费完旧日志，否则主从复制会直接断掉。
redo log的配置方法
redo log由InnoDB自动维护，默认就处于开启状态，但默认参数往往不够用。redo log的大小决定了崩溃恢复的时长和写入性能，主要涉及以下参数：
[mysqld] # redo log目录，建议放到独立的高速磁盘 innodb_log_group_home_dir=/var/lib/mysql # 每个redo log文件的大小，MySQL 8.0.30后由innodb_redo_log_capacity替代 innodb_log_file_size=512M # 日志文件组数，通常保持默认 innodb_log_group_home_dir下文件循环使用 innodb_log_files_in_group=2 # 事务提交时redo log刷盘策略，1为最安全 innodb_flush_log_at_trx_commit=1
重点看innodb_flush_log_at_trx_commit，它有三个可选值：1表示每次事务提交都刷盘，配合sync_binlog=1构成双1配置；2表示提交时只写到操作系统的文件缓存，每秒刷盘一次；0表示每秒由后台线程写入并刷盘。设为2时性能最好，但MySQL进程崩溃不丢数据，而操作系统崩溃或断电可能丢失约1秒的事务，一般业务用2就够了，对数据一致性要求高的场景务必用1。
修改innodb_log_file_size在MySQL 5.7及之前需要先干净关闭MySQL再修改，否则启动可能报错。MySQL 8.0.30之后官方推荐直接使用innodb_redo_log_capacity参数，它代表redo log的总容量，InnoDB会自动管理文件数量，而且支持在线动态调整，无需重启：
-- 在线调整redo log总容量为2GB SET GLOBAL innodb_redo_log_capacity = 2147483648; -- 查看当前redo log配置 SHOW VARIABLES LIKE 'innodb_%log%'; -- 查看redo log使用情况 SELECT * FROM performance_schema.innodb_redo_log_files;
redo log容量设置过小会导致频繁的checkpoint刷脏页，写入出现抖动；过大则会拉长崩溃恢复时间。经验值上，单个文件的写入速率乘以希望容忍的恢复时间就是合理的总容量，一般线上建议设置在1GB到4GB之间，写入密集的业务可以更大。
常见问题与排查思路
配置完成后如果发现主从复制不工作，先用SHOW SLAVE STATUS查看错误信息，最常见的错误是两台机器的server-id相同，或者binlog被RESET MASTER清空后从库找不到对应的日志位点。另外要注意binlog文件所在的磁盘空间，ROW格式下日志膨胀速度很快，一定要合理设置过期时间并监控磁盘余量。
如果是重启后MySQL起不来，报错提示redo log文件大小与配置不符，说明手工修改了innodb_log_file_size但没走正常流程。MySQL 5.7的处理办法是正常关闭实例后，删除ib_logfile开头的文件再启动，InnoDB会按新参数重建。MySQL 8.0则基本不会遇到这类问题，直接调大容量在线生效即可。
最后提醒一点，binlog和redo log各司其职，不能互相替代。有些教程说开了redo log就不用binlog，这是错误的：redo log是循环覆盖写的物理日志，无法归档，主从复制和数据按时间点恢复只能依赖binlog。两份日志配置到位，再加上合理的刷盘策略，数据库的数据安全才有了最基本的保障。
mysql binlog配置redo logmysql日志修改时间：2026-09-11 08:30:37