为啥在启用 mysql binlog 后我们还需要 innodb redo log？

Posted 2023-02-16

【中文标题】为啥在启用 mysql binlog 后我们还需要 innodb redo log？

【英文标题】：Why we still need innodb redo log when mysql binlog has been enabled?为什么在启用 mysql binlog 后我们还需要 innodb redo log？

【发布时间】：2020-01-18 20:43:27

【问题描述】：

在我的理解中，mysql binlog 完全可以作为 InnoDB 的 redo log。

那么，在启用binlog之后，为什么InnoDB非要切换到使用binlog，还要同时写redo log呢？这不会显着降低数据库写入性能吗？

除了简化设计和实现之外，这样做有什么好处吗？

AFAIK，在保证 ACID 合规性的情况下同时启用两个日志，会出现以下问题：

每条具有相同含义的日志记录必须分别写入两次。 每次提交事务或事务组时刷新两个日志。 为确保两个日志文件之间的一致性，使用了复杂且低效的方式，例如 XA (2PC)。

因此，所有其他产品似乎只使用一组日志（SQL Server 称为 Transaction log，ORACLE 称为 redo log，PostgreSQL 称为 WAL）来完成所有相关工作。是不是只有 MySQL 必须同时打开两组日志才能保证 ACID 合规性和强一致性主从复制？

有没有办法实现 ACID 合规性和强一致性半同步复制，同时只启用其中一个？

【参考方案1】：

这是一个有趣的话题。一直以来，我一直在提倡将 InnoDB write-ahead log 和 binlog 合并的想法。这样做的最大动机是不再需要同步两个单独的日志。但是，恐怕这不会很快发生。

在 MariaDB，我们正在采取一些措施来减少 fsync() 开销。 MDEV-18959 Engine transaction recovery through persistent binlog 的想法是保证 binlog 永远不会落后于 InnoDB 重做日志，从而允许在 binlog 文件上仅通过一次 fsync() 调用进行持久的、崩溃安全的事务提交。

虽然 binlog 实现了逻辑日志记录，但 InnoDB 重做日志实现了物理日志记录（涵盖对实现撤消日志和索引树的持久数据页面的更改）。正如我在M|18 Deep Dive: InnoDB Transactions and Write Paths 中解释的那样，一个用户事务分为多个小事务，每个小事务可以原子地修改多个数据页。

重做日志是对多个数据页进行原子更改的“粘合剂”。我认为重做日志对于实现就地更新数据结构的原子更改是绝对必要的。仅追加的数据文件结构（例如 LSM 树）本身可以是日志，不一定需要单独的日志。

对于包含二级索引的 InnoDB 表，每一个单独的行操作实际上都被划分为多个小事务，分别对每个索引进行操作。因此，事务层需要更多的“粘合剂”，使表的索引彼此一致。这种“胶水”由撤消日志提供，它在持久数据页中实现。

InnoDB 预先对索引页进行更改，commit 是一种快速操作，只是在 undo log header 中更改事务的状态。但是回滚是非常昂贵的，因为撤消日志必须向后重放（并且将写入更多的重做日志来覆盖那些索引页面的更改）。

在 MariaDB Server 中，MyRocks 是另一个事务性存储引擎，它的作用正好相反：在内存中缓冲更改直到最后，并在提交时将它们应用到数据文件。这使得回滚非常便宜，但事务的大小受可用内存量的限制。我知道 MyRocks 可以按照您建议的方式工作。

【讨论】：

您好，Marko，感谢您的精彩而全面的回答。但是无论你使用哪种 ACID 兼容的存储引擎，binlog 都会导致额外的写入，对吧？似乎只有禁用binlog，直接通过redo log进行复制，才能完全避免这些额外的开销？我发现了这个：medium.com/@Alibaba_Cloud/…mariadb等主流发行版中是否有可能出现类似的功能？

@ASBai 你是对的。多年来，我一直提倡将所有日志事件写入单个文件的想法。在jira.mariadb.org/browse/MDEV-12353 中，我正在研究一种新的 InnoDB 重做日志格式，该格式允许添加“外部”日志事件。解析和应用日志的更简单的代码也可以更容易地实现物理复制（没有二进制日志）。

我认为这是一个很大的改进，我必须投赞成票:-)