为什么在 mysql binlog 已经启用的情况下我们仍然需要 innodb redo log？
Why we still need innodb redo log when mysql binlog has been enabled?
在我的理解中，mysqlbinlog完全可以作为InnoDB的redo log。
那么，启用binlog后，为什么InnoDB要同时写入redo log，而不是直接切换到binlog呢？这不会显着降低数据库写入性能吗？
除了简化设计和实现之外，这样做还有什么好处吗？
据我所知，在保证ACID合规的情况下同时启用两个日志，会出现以下问题：
- 每条具有相同含义的日志记录必须分别写入两次。
- 每次事务或事务组提交时刷新两个日志。
- 为了保证两个日志文件的一致性，采用了XA(2PC)等复杂低效的方式
因此，所有其他产品似乎只使用一组日志（SQL 服务器称为事务日志，ORACLE 称为重做日志，而 PostgreSQL 称为 WAL）来完成所有相关工作.是不是只有MySQL必须同时开启两组日志，既保证ACID合规，又保证主从复制强一致？
有没有办法在只启用其中一个的情况下实现 ACID 合规性和强一致性半同步复制？
这是一个有趣的话题。长期以来，我一直提倡将InnoDB write-ahead log和binlog合并的想法。这样做的最大动机是不再需要同步两个单独的日志。但是，恐怕这不会很快发生。
在 MariaDB，我们正在采取一些措施来减少 fsync() 开销。 MDEV-18959 Engine transaction recovery through persistent binlog 的想法是保证 binlog 永远不会落后于 InnoDB 重做日志，并且通过这种方式，允许在 binlog 文件上仅通过一次 fsync() 调用进行持久的 crash-safe 事务提交.
虽然 binlog 实现逻辑日志记录，但 InnoDB 重做日志实现物理日志记录（涵盖对实现撤消日志和索引树的持久数据页的更改）。正如我在M|18 Deep Dive: InnoDB Transactions and Write Paths中所解释的，一个用户事务被分成多个mini-transactions，每个事务可以原子地修改多个数据页。
重做日志是对多个数据页进行原子更改的“粘合剂”。我认为重做日志对于实现 update-in-place 数据结构的原子更改是绝对必要的。 Append-only 数据文件结构，例如 LSM 树，本身可以是日志，不一定需要单独的日志。
对于包含二级索引的InnoDB table，每一个单行操作实际上被分成多个mini-transactions，分别对每个索引进行操作。因此，交易层需要更多的“胶水”，使 table 的索引彼此一致。该“胶水”由撤消日志提供，它在持久数据页中实现。
InnoDB 预先对索引页执行更改，提交是一个快速操作，仅更改撤消日志中事务的状态 header。但是回滚非常昂贵，因为必须向后重放撤消日志（并且将写入更多重做日志以覆盖那些索引页更改）。
在 MariaDB Server 中，MyRocks 是另一个事务性存储引擎，它做相反的事情：在内存中缓冲变化直到最后，并在提交时将它们应用到数据文件。这使得回滚非常便宜，但事务的大小受可用内存量的限制。我了解到 MyRocks 可以按照您建议的方式工作。
在我的理解中，mysqlbinlog完全可以作为InnoDB的redo log。
那么，启用binlog后，为什么InnoDB要同时写入redo log，而不是直接切换到binlog呢？这不会显着降低数据库写入性能吗？
除了简化设计和实现之外，这样做还有什么好处吗？
据我所知，在保证ACID合规的情况下同时启用两个日志，会出现以下问题：
- 每条具有相同含义的日志记录必须分别写入两次。
- 每次事务或事务组提交时刷新两个日志。
- 为了保证两个日志文件的一致性，采用了XA(2PC)等复杂低效的方式
因此，所有其他产品似乎只使用一组日志（SQL 服务器称为事务日志，ORACLE 称为重做日志，而 PostgreSQL 称为 WAL）来完成所有相关工作.是不是只有MySQL必须同时开启两组日志，既保证ACID合规，又保证主从复制强一致？
有没有办法在只启用其中一个的情况下实现 ACID 合规性和强一致性半同步复制？
这是一个有趣的话题。长期以来，我一直提倡将InnoDB write-ahead log和binlog合并的想法。这样做的最大动机是不再需要同步两个单独的日志。但是，恐怕这不会很快发生。
在 MariaDB，我们正在采取一些措施来减少 fsync() 开销。 MDEV-18959 Engine transaction recovery through persistent binlog 的想法是保证 binlog 永远不会落后于 InnoDB 重做日志，并且通过这种方式，允许在 binlog 文件上仅通过一次 fsync() 调用进行持久的 crash-safe 事务提交.
虽然 binlog 实现逻辑日志记录，但 InnoDB 重做日志实现物理日志记录（涵盖对实现撤消日志和索引树的持久数据页的更改）。正如我在M|18 Deep Dive: InnoDB Transactions and Write Paths中所解释的，一个用户事务被分成多个mini-transactions，每个事务可以原子地修改多个数据页。
重做日志是对多个数据页进行原子更改的“粘合剂”。我认为重做日志对于实现 update-in-place 数据结构的原子更改是绝对必要的。 Append-only 数据文件结构，例如 LSM 树，本身可以是日志，不一定需要单独的日志。
对于包含二级索引的InnoDB table，每一个单行操作实际上被分成多个mini-transactions，分别对每个索引进行操作。因此，交易层需要更多的“胶水”，使 table 的索引彼此一致。该“胶水”由撤消日志提供，它在持久数据页中实现。
InnoDB 预先对索引页执行更改，提交是一个快速操作，仅更改撤消日志中事务的状态 header。但是回滚非常昂贵，因为必须向后重放撤消日志（并且将写入更多重做日志以覆盖那些索引页更改）。
在 MariaDB Server 中，MyRocks 是另一个事务性存储引擎，它做相反的事情：在内存中缓冲变化直到最后，并在提交时将它们应用到数据文件。这使得回滚非常便宜，但事务的大小受可用内存量的限制。我了解到 MyRocks 可以按照您建议的方式工作。