予晚我接触MySQL这些年，踩过最深的坑之一，就是没搞懂Binlog和Redo Log这对“孪生兄弟”的关系。面试被问过，线上故障排查被坑过，甚至给团队做技术分享时还讲错过一次。很多人跟我当初一样，张口就说“Binlog管主从复制，Redo Log管崩溃恢复”，这话没全错，但离真相差着十万八千里。如果只是背这个结论去应付面试，迟早会在真实故障里摔跟头。
这篇文章我想从头梳理一遍MySQL的Binlog和Redo Log，包括它们各自是什么、为什么需要两套日志、两阶段提交到底在解决什么问题，以及日常运维中怎么看日志、怎么安全删Binlog、怎么调Redo Log参数。内容不绕弯子，也不拽玄乎的术语，尽量用我理解问题的方式讲清楚，配合实际案例和排查过程，让看完的人能直接用到生产环境里。
1. 为什么MySQL要同时维护两套日志体系？很多人的理解都不完整
1.1 先想清楚一个最基础的矛盾：一个数据库系统需要日志来做什么
在搞清楚Binlog和Redo Log之前，必须先回答一个问题：InnoDB既然有了Redo Log，MySQL Server层为什么还要搞一个Binlog？
我第一次被问住是在一次故障复盘会上。当时线上MySQL突然宕机，重启后靠Redo Log恢复了数据，但主从同步却断了，Slave报错说找不到对应的Binlog位点。大家核对半天才发现，主库虽然恢复了数据，但Binlog和实际数据不一致，导致从库跟主库对不上。那次之后我才真正意识到，Redo Log和Binlog是两套独立设计、各司其职的体系，谈不上谁替代谁，更不是“一个管恢复、一个管复制”这么单薄。
要理解这个问题，得从MySQL的整体架构说起。MySQL分为Server层和存储引擎层，Binlog是Server层生成的日志，所有引擎都能用，主要服务于数据复制、增量备份、时间点恢复这些上层功能；Redo Log则是InnoDB存储引擎自带的日志，只服务于InnoDB这一层，核心目标是保证事务的持久性——也就是崩溃后重启，已提交事务的数据不丢。
既然职责不同，设计思路自然也完全不同。Redo Log是物理逻辑日志，记录的是一条记录在哪个页、哪个偏移量、改成了什么，也就是说它关注的是“数据页最终被改成了什么样”；Binlog是逻辑日志，记录的是语句级的逻辑变化，比如“执行了一条UPDATE，把id=1这行数据的name从A改成了B”，关注的是“这个变更操作本身是什么”。
所以回到最开始的矛盾就清楚了：InnoDB的事务提交需要Redo Log来保底，确保数据能持久化；MySQL整体的数据复制、恢复、回滚到任意时间点，则需要Binlog来提供一套完整、独立、可跨引擎的逻辑变更流。二者缺一个都会出问题。
1.2 用一个“寄快递”的类比把两套日志的分工讲清楚
为了让自己跟别人都能听明白，我后来总结了一个快递类比，分享过几次，反馈还不错。
假设你经营一家淘宝店，每天卖出很多货。Redo Log像是仓库里的入库出库单，记录的是货品在仓库货架上的实际物理移动——A货架第3层放了两箱货，B货架第5层拿走一箱。它非常详细地记录物理位置的变化，一旦仓库着火（数据库崩溃），你靠入库出库单能重新把货架整理成火灾前的样子。
Binlog则像你发给物流公司的发货清单——今天发了哪些订单、每单发往哪里、发了什么货。物流公司不关心你的仓库内部怎么摆货，只凭发货清单就能同步每个站点的包裹状态。
对应到MySQL里，Redo Log的作用是“仓库内恢复”，只管InnoDB数据页的一致性；Binlog的作用是“外部协作”，主从复制、数据订阅、备份恢复，全都依赖这份发货清单。这也就解释了为什么主从复制用的是Binlog而不是Redo Log，因为从库是一个独立的实例，它需要的是“你执行了哪些逻辑操作”，而不是“你哪个数据页改成了什么样”。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 先搞清一个根本问题：Binlog和Redo Log到底记录的是什么
2.1 Binlog的逻辑日志身份：格式是理解它的第一把钥匙
Binlog有三种记录格式，分别是Statement、Row和Mixed，这是理解Binlog绕不过去的基础。
Statement格式记录的是原始SQL语句。比如你执行了UPDATE user SET age = age + 1 WHERE score > 60，Binlog里直接存这条SQL。优点是日志量小，缺点也很明显——它依赖执行环境的上下文。主从库如果用了不同的索引、不同的数据分布，或者SQL里用了NOW()这种非确定性函数，从库执行同样的SQL得到的结果可能跟主库不一致。我自己就遇到过因为ORDER BY不走索引导致主从数据不一致的案例，排查了两天，最后发现Binlog格式还是老的Statement。
Row格式记录的是每一行数据的实际变更前后值。比如更新了1000行，Binlog里就记录1000行的变更前后快照。优点是一致性最好，主从复制时不再依赖执行环境；缺点是日志量暴涨，一条DELETE FROM table删除100万行，Binlog会产生非常庞大的记录。MySQL 8.0默认就是Row格式，这也是官方推荐的答案，一致性优先。
Mixed格式则是Statement和Row的混合体，MySQL会自动判断某种情况下是否可能产生不一致，如果不确定就切到Row格式。
还有一个容易忽略的点：Binlog是追加写的滚动日志文件。一个文件写满后，会生成一个新的文件继续写，文件名形如mysql-bin.000001、mysql-bin.000002。这个设计决定了它天然适合做基于时间点或位点的恢复——你可以任意指定从某个Binlog文件、某个Position位置开始重放变更。这也是为什么PURGE BINARY LOGS能精确删除指定文件，而不会影响整个日志链。
2.2 Redo Log的物理逻辑日志身份：它记录的本质是“数据页的修改轨迹”
Redo Log的格式在官方文档里被称为“物理逻辑日志”（Physical Logical Log）。重点在这个“物理+逻辑”的组合——它逻辑地描述了一次物理页面的修改。不像Binlog记录SQL语句或行快照，Redo Log记录的是类似“把表空间ID为5、页号为1024的页面，从偏移量2048开始的4个字节，从值A改为值B”这样的信息。
为什么说“物理”又“逻辑”？说它物理，是因为它确实绑定到具体的表空间和数据页；说它逻辑，是因为它不会记录数据页的完整快照，只记录修改片段。这样做的好处有两个：一是日志量比记录整页小得多，二是重放时不关心当时SQL上下文，只看页面号和偏移量，直接就能把页面恢复到位。
Redo Log的另一个重要特征是循环写入。InnoDB会用一组固定大小的文件组成Redo Log文件组，默认一般是ib_logfile0、ib_logfile1，写满后覆盖最老的文件继续写。这个设计跟Binlog完全不同，Binlog可以堆积大量历史文件，而Redo Log只保留最近一段时间的数据页面修改记录。如果你把Redo Log文件组想成一个环形缓冲区，那就很好懂了——当写指针追上擦除指针时，老日志会被覆盖，所以它无法承担历史备份、时间点恢复这类长期任务。
2.3 对比表格：两套日志的核心差异一目了然
我整理了一张对比表，算是这篇文章的核心参照物，后续所有实战细节都能跟表格对应上。
| 对比维度 | Binlog | Redo Log |
|---|---|---|
| 所属层级 | MySQL Server层 | InnoDB存储引擎层 |
| 主要作用 | 主从复制、时间点恢复、增量备份 | 崩溃恢复、事务持久性 |
| 记录内容 | 逻辑操作（SQL或行变更） | 物理数据页的修改轨迹 |
| 文件组织 | 滚动追加，多个文件可保留 | 固定大小文件组，循环覆盖 |
| 记录格式 | Statement / Row / Mixed | 物理逻辑记录 |
| 清理方式 | 手动或按过期策略删除 | 自动覆盖最老文件 |
| 依赖范围 | 不依赖具体引擎 | 仅InnoDB引擎使用 |
| 刷盘时机 | 事务提交时写入OS Buffer或磁盘 | 每次数据页修改时记录，根据刷盘策略定期持久化 |
这张表也能帮你在面试时快速建立清晰的分类框架：层级、内容、文件组织、职责，四个维度记住，基本就能应对大多数关于两套日志区别的提问。
3. 两阶段提交和崩溃恢复：连接Binlog与Redo Log的枢纽机制
3.1 为什么需要“两阶段提交”？问题出在Binlog和Redo Log写盘时机不一致
现在我们已经知道，Binlog和Redo Log是两套独立的日志。但在一个事务提交时，这两套日志都必须落盘，问题就来了：如果先写Binlog、后写Redo Log，写完Binlog后突然宕机，重启后从库可能多执行了一条主库没有的数据变更；如果先写Redo Log、后写Binlog，写完Redo Log后突然宕机，主库自己恢复了这条事务，但Binlog里没有，从库就会缺少这条变更。
这就好比在一个团队里，项目经理（Binlog）和仓库管理员（Redo Log）各记一本账。两本账如果不保持一致，对账的时候必然出问题。
MySQL的解法就是引入分布式系统中常用的两阶段提交（Two-Phase Commit）机制，把事务提交拆成Prepare和Commit两个阶段，让Binlog和Redo Log在事务边界上达成一致。这一步非常关键，它是理解MySQL崩溃恢复正确性的核心。
3.2 两阶段提交的完整流程：Prepare、写Binlog、Commit
我以一次简单的UPDATE t SET c = 1 WHERE id = 1为例，带大家走一遍完整的事务提交流程。
第一步，执行阶段。InnoDB在内存中修改数据页，并生成对应的Redo Log，此时这个事务处于Prepare状态。注意，这里还只是把Redo Log写入Redo Log Buffer，事务还没真正提交。
第二步，Prepare阶段落Redo Log。InnoDB将事务产生的Redo Log写入磁盘（具体刷盘策略取决于innodb_flush_log_at_trx_commit参数），并将事务标记为Prepare状态。这一步做完，即使系统立刻崩溃，InnoDB也能通过Redo Log恢复这条事务的修改。
第三步，写入Binlog。MySQL Server层把这条事务对应的Binlog事件写入Binlog文件，并按参数控制刷入磁盘。写完后，Binlog就已经包含了这条事务的完整逻辑变更。
第四步，Commit阶段。InnoDB将事务标记为Committed状态，同时写入一个内部标记，表示这条事务对应的Binlog已经落盘。MySQL返回客户端提交成功。
这个顺序不是随便定的。先Prepare Redo Log，是为了保证事务修改本身可恢复；后写Binlog，是为了避免Binlog里出现一条“在Redo Log中不存在”的事务；最后Commit加标记，则是为了让崩溃恢复时能判断一条处于Prepare状态的事务，到底是该提交还是该回滚。
3.3 崩溃恢复时，MySQL怎么判断该回滚还是该提交？
如果系统在事务提交的某个阶段宕机，重启后InnoDB会执行崩溃恢复，这时它面对的是一条处于Prepare状态的Redo Log事务，需要决定是提交还是回滚。判断依据就是Binlog是否完整落盘。
具体逻辑分三种情况。
情况一：Redo Log里事务已经是Commit状态。这说明两阶段提交已经完整走完，事务毫无疑问应该提交。
情况二：Redo Log里事务是Prepare状态，但对应的Binlog已经完整写入，Binlog中有该事务的XID事件。这时MySQL认为事务已经成功提交，因为Binlog的存在意味着“数据变更已经对外发布”，所以InnoDB会主动提交这条事务，保证主库数据和Binlog一致。
情况三：Redo Log里事务是Prepare状态，但Binlog中没有对应的完整事务记录。这说明事务还没提交成功就宕机了，或者Binlog没有完整落盘，MySQL会回滚这条事务。
用一句话总结就是：Binlog是否完整落盘，是崩溃恢复时决定提交还是回滚的“判定标尺”。 两阶段提交本质上是为了让这套判定逻辑可靠、可执行。
3.4 组提交与刷盘策略：性能和安全如何权衡
在理解了基本流程后，再往深一层看：两阶段提交每个事务都要刷两次盘，性能影响很大。MySQL 8.0通过组提交（Group Commit）机制做了优化，能让多个事务的Prepare和Commit阶段合并刷盘，从而减少磁盘I/O次数。
这里有两个参数需要重点关注。
innodb_flush_log_at_trx_commit：控制Redo Log的刷盘频率。设为1表示每次事务提交都刷盘，数据最安全；设为0表示每秒刷一次，最多可能丢1秒事务；设为2表示每次提交只写入操作系统缓存，每秒刷盘一次，性能和安全中间态。生产环境核心业务我建议还是1，千万别为了省一点I/O拿数据安全开玩笑。
sync_binlog：控制Binlog的刷盘策略。设为1表示每次事务提交都刷Binlog到磁盘，配合innodb_flush_log_at_trx_commit=1能达到最多丢失零个事务的安全级别；设为0或大于1的值会让MySQL批量刷盘，性能更好，但可能丢失部分已提交事务的Binlog记录。
在实际调优中，我见过不少团队为了性能把这两个参数都改成0，结果一次宕机后出现主从数据不一致，恢复过程极其痛苦。越是交易、支付这类账务系统，越要把这两个参数配置成1，性能可以用别的办法优化，数据正确性没有妥协余地。
4. 实战视角：怎么看日志、怎么安全删Binlog、怎么调整Redo Log
4.1 实操：如何查看Binlog里到底记录了什么
先介绍一个最有用的排查命令：SHOW BINLOG EVENTS。它的用法是：
sql复制SHOW BINLOG EVENTS IN 'mysql-bin.000003' LIMIT 10;
这条命令能直接看到Binlog文件里的事件列表，包括每个事件的Position位置、事件类型、所属库表以及SQL内容（如果是Statement格式）或变更行的简要信息。平时排查主从不同步、定位某个时间点的变更来源，这个命令比mysqlbinlog更快速，因为不需要退出MySQL客户端。
如果要看Binlog文件里某条具体事务的完整SQL，比如要恢复一个被误删的数据，那就用mysqlbinlog工具：
bash复制mysqlbinlog --base64-output=DECODE-ROWS -v /var/lib/mysql/mysql-bin.000005
注意，MySQL 8.0默认是Row格式，直接看会是Base64编码的二进制内容，必须加上--base64-output=DECODE-ROWS -v参数才能解码成可读的行变更前后值。这个命令在生产环境排查误操作时是救命稻草，我后面会专门讲一个案例。
查看当前正在写的Binlog文件和位置，用这个：
sql复制SHOW MASTER STATUS;
对于主从复制来说，这会输出当前Binlog文件名和Position位置，是从库CHANGE MASTER TO配置的核心参数。
4.2 生产环境最关心的问题：MySQL 8.0的Binlog到底能不能删？怎么删才安全？
很多人在热搜里搜“mysql8.0 binlog可以删除吗”，说明这是个非常普遍的运维困惑。我说得直接一点：Binlog当然可以删除，但不能用rm命令删文件，而是要通过MySQL自己的机制安全清理。 用操作系统rm直接干掉的后果，轻则主从复制报错，重则备份恢复链断裂，别问我是怎么知道的。
安全删除Binlog有三种常见方式。
第一种，基于过期时间自动清理。MySQL 8.0之前用的是expire_logs_days参数，8.0正式引入binlog_expire_logs_seconds参数，单位是秒，粒度更细。比如设置保留7天：
sql复制SET GLOBAL binlog_expire_logs_seconds = 604800;
注意这个参数只是控制自动清理策略，不会立即删除文件，而是在Binlog切换时或后台任务中清理过期文件。
第二种，基于文件名手动清理。用PURGE BINARY LOGS TO 'mysql-bin.000100';表示删除这个文件之前的所有Binlog；或者用PURGE BINARY LOGS BEFORE '2025-01-01 00:00:00';删除指定时间之前的所有Binlog。
第三种，直接重置所有Binlog。RESET MASTER;会清空所有Binlog文件并从000001重新开始。这个操作杀伤力极大，生产环境只有在新搭建实例、彻底重建复制环境时才推荐使用，操作前一定要想清楚。
我还要强调一个很多人忽视的前提：判断Binlog能否删除，不是看它存储占用了多少空间，而是看“从库是否已经消费了这个Binlog”。如果从库还在等一个旧Binlog，你手动把它删了，主从复制会立刻中断，从库状态变成SQL thread报错。生产环境清理Binlog前，建议先执行：
sql复制SHOW SLAVE STATUS\G
确认从库的Master_Log_File和Read_Master_Log_Pos已经超过了打算删除的Binlog文件，然后才动手。另外，如果你准备用Binlog做基于时间点的备份恢复，也要确保备份集之前还有足够的Binlog可供回放，否则备份就白做了。
4.3 Redo Log的大小设计与Buffer参数调优：为什么不能凭感觉设置
Redo Log相关参数是生产环境优化中经常踩坑的地方。
在MySQL 8.0.30之前，Redo Log的大小由innodb_log_file_size（每个Redo Log文件的大小）和innodb_log_files_in_group（文件组里文件数量）共同决定，两者相乘就是Redo Log总容量。8.0.30引入了innodb_redo_log_capacity参数，优先控制Redo Log总容量，如果提供了这个参数，innodb_log_file_size和innodb_log_files_in_group会被忽略。
Redo Log设置太小会带来一个明显的症状：写入高峰时，Redo Log写指针很快追上擦除指针，InnoDB会进入“用户线程刷脏”模式，也就是强制让事务等待脏页刷新，性能急剧下降。 这就像环形水池已经满了，还在不断往里倒水，必须先排水才能继续倒。
我的建议是：如果写多读少的线上业务经常出现磁盘I/O尖刺，先检查InnoDB_redo_log_waits状态变量，如果持续有等待，就该考虑调大Redo Log容量了。在8.0.30+版本，可以动态调整：
sql复制SET GLOBAL innodb_redo_log_capacity = 8589934592; -- 8GB
但注意，调大Redo Log不是越多越好。Redo Log越大，崩溃恢复时需要重放的日志就越多，恢复时间也会变长。我见过有人一口气给了64GB，结果一次宕机恢复花了半小时，业务等不起。通用建议是把Redo Log总容量设置为能容纳高峰期15到30分钟的写入量，具体需要结合业务峰值写入速度推算。
再补充一个容易被忽略的参数：innodb_log_buffer_size，也就是Redo Log Buffer大小。默认值是16MB，如果事务产生的Redo Log量超过Buffer大小，会触发额外I/O将部分日志写入磁盘。对写入密集型业务，建议调大到64MB或128MB，降低刷盘次数，但对单个超大事务的效果有限，因为一个事务的Redo Log不能被拆分成多次部分刷盘。
4.4 实操：Redo Log Buffer在压力测试中体现的性能差异
有一次我们做写性能压测，在纯插入场景下，innodb_log_buffer_size从16MB调到64MB后，吞吐量提升了大约8%。原因是原本小Buffer频繁触发中间态写入，导致额外的磁盘I/O和等待。改完后，观察SHOW ENGINE INNODB STATUS里的Log i/o's written和Log waits，确认Log waits降到了接近0。
这个优化虽然收益不算特别夸张，但几乎零成本、无风险，适合任何写入量较大的MySQL实例采用。类似这样的小调整，需要结合状态变量来判断，而不是单纯靠感觉拍脑袋，这也是我在实践中最想强调的思路。
5. 生产环境里关于Binlog和Redo Log的那些坑与经典问题
5.1 由Binlog缺失引发的一次主从复制故障：完整排查过程
下面分享一个我实际处理的线上故障，整个过程比较典型，值得完整走一遍。
某个周五晚上，业务方反馈订单查询越来越慢，主库CPU飙升。我登录Master执行SHOW PROCESSLIST，发现大量Binlog dump线程处于高锁等待状态。再执行SHOW SLAVE STATUS，发现从库的Slave_IO_Running是Yes，但Seconds_Behind_Master在持续增长。
第一反应是网络带宽问题，但查了监控发现主从之间带宽没问题。然后我看了Master的Binlog文件列表，发现文件号从000120直接跳到了000135，中间缺了十几个文件，明显是有过手动删除或者PURGE操作。
进一步查了从库当前的Relay_Log_File和Master_Log_File，发现从库消费到000118还没结束，而主库已经把000119到000134都清了。从库无法获取需要的Binlog文件，IO线程虽然还在，但主库这边的Binlog dump线程已经拿不到对应文件，只能等超时重连，导致复制延迟持续累积。
排查方向立刻转向“谁动了Binlog”。查了操作记录，果然是之前有同事为了释放磁盘空间，手动执行了PURGE BINARY LOGS TO 'mysql-bin.000135';，恰好从库还在消费旧文件，直接导致复制差点断掉。
解决办法是：第一，立即停止所有自动清理策略，防止继续删除；第二，用xtrabackup等工具从主库重新做一次全新的物理备份，然后重建从库，让从库从最新位点开始重新建立复制。整个过程耗时三个小时，业务影响不小。这起事故的核心教训就是：清理Binlog之前必须确认所有从库的消费位点，绝不能只看磁盘剩余空间。
5.2 一次误删数据的恢复：Binlog的时间点恢复价值
另一个让我印象深刻的案例是一次误操作。业务方在账号环境里执行了：
sql复制DELETE FROM orders WHERE status = 2;
本来只想删测试数据，结果忘了加库名和严格过滤条件，一下子删了半个核心订单表。幸好有完整的Binlog，而且格式是Row。
恢复思路是利用Binlog找到误删操作前的最后一个位置点，然后重放到这个位置。
大致步骤是这样的：
- 确认误删时间点，比如22:15。
- 用
mysqlbinlog解析对应时段的Binlog文件，命令类似于：
bash复制mysqlbinlog --base64-output=DECODE-ROWS -v \
--start-datetime="2025-03-10 22:00:00" \
--stop-datetime="2025-03-10 22:20:00" \
/var/lib/mysql/mysql-bin.000130 > /tmp/recover_orders.sql
- 在文件里找到那条
DELETE对应的日志位置，确定恢复目标Position。 - 用
--stop-position参数只解析到误删前一刻，得到需要重放的Binlog内容。 - 将Binlog中的删除事件反转为插入语句，生成恢复SQL，再导入到临时库，校验数据完整后导入生产环境。
这个流程里最耗时的是把Row格式的DELETE事件反转为INSERT语句，因为需要手工或脚本根据Binlog里记录的删除前行快照生成插入SQL。有一些开源工具可以辅助解析，但核心原理都是基于Row格式不会丢失变更前值这一特性。可以说，只要Binlog还在，误删数据就还有救。
5.3 面试和日常交流中常见的几个高频问题，我给出我的回答思路
最后总结几个关于Binlog和Redo Log的高频问题，不光是面试用，日常跟同事讨论时也经常用到。
Q1：为什么说Redo Log是“物理逻辑日志”？
Redo Log记录的是“物理数据页上的修改操作”，所以是物理的；但它并不记录数据页被修改后的完整内容，只描述修改本身，所以又是逻辑的。这样既避免了完整页快照的体积过大，又能精确定位需要恢复的数据页。
Q2：Binlog的三种格式分别带来什么影响？
Statement格式日志量小但一致性风险高，Row格式一致性最好但日志量大，Mixed格式由MySQL自动判断切换。核心业务推荐Row格式，配合binlog_row_image=FULL能保证恢复和复制时有完整前后值。
Q3：两个日志刷盘参数怎么设置最安全？
innodb_flush_log_at_trx_commit=1和sync_binlog=1是最安全组合，零事务丢失；如果追求性能愿意接受丢失最近1秒事务的风险，可以调整为2和1，但绝对不建议两者都设成0。
Q4：Binlog可以删除吗？
可以，但必须通过PURGE BINARY LOGS或过期策略删除，删除前要确认所有从库的消费位点已超过待删文件，且备份恢复链路不需要这些旧文件。
Q5：Redo Log无限增大后，崩溃恢复时间会变长吗？
会。Redo Log越大，需要重放的范围就越大，恢复时间越长。合理的大小是能覆盖写入峰值期间的日志量，而不是越大越好。
这些问题背后其实都指向同一个核心逻辑：Binlog和Redo Log两套日志，各自维护一套边界，两阶段提交负责让它们在事务提交时保持一致，而崩溃恢复时的提交或回滚决策，完全以Binlog的完整性作为依据。 搞懂了这条主线，不管是面试还是排障，思路都会清晰很多。
5.4 一些踩过坑之后想说的话
如果你正在准备面试或者刚开始深入学习MySQL，我的建议是不要只背两套日志的区别列表，而是从“为什么需要两套日志”这个角度出发，顺着事务提交链路把两阶段提交、崩溃恢复、主从复制串起来理解。知识一旦形成了链路，遇到问题就能自然地联想到可能出故障的环节。
如果你是在维护生产环境，我建议尽早建立一套日志巡检机制：每天检查Binlog文件增长量和过期清理策略、确认从库复制位点与主库Binlog清理策略匹配、观察Redo Log的写等待状态变量。这些操作成本很低，但能避免绝大多数日志相关的线上事故。
我自己在经历了主从断连、误删恢复、Redo Log性能瓶颈这些问题之后，最大的体会是：MySQL日志体系就像一个精密的双轨系统，理解越深，操作起来就越有底气，遇到问题也不会慌张。希望这篇文章能帮你把这对“孪生兄弟”彻底搞清楚，在实战里少走一些弯路。