MySQL 事务日志

Question

我正在从事一个项目，我们需要在我们的 DBMS (MySQL) 中使用“事务日志”。我们已经切换到使用 InnoDB 以便将事务用于另一个需求。我想了解什么是交易日志。我已经搜索了一天多，包括阅读 MySQL 文档。也许我只是没有在寻找正确的关键字，我不确定。或者“交易日志”可能是不恰当的术语。

据我了解，数据库事务日志记录类似于日志文件系统，因为在将日志更改提交到文件系统之前对日志进行了更改。从我读到的内容来看，InnoDB 引擎听起来像是在将事务提交到磁盘之前将它们存储在某种日志中。这听起来准确吗？如果是这样，交易日志在哪里？是 ib_logfile0 和 ib_logfile1 吗？

Answer 1

你在这里绝对是在正确的轨道上。

每当 InnoDB 执行必须提交的事务时，它都是作为两阶段提交完成的。事务首先写入这些日志中。然后，他们从那里 promise 。

这在 MySQL 崩溃或服务器崩溃的情况下有很大帮助。

当您重新启动 mysql 时，ib_logfile0 和 ib_logfile1 中所有未提交的条目将作为 InnoDB 崩溃恢复的一部分进行重放，以使 InnoDB 进入和谐状态(这是 ACID Compliance 的一致和持久部分)

如果删除 ib_logfile0 和 ib_logfile1 并启动 mysql，这些文件包含的任何未提交的事务都会丢失。在崩溃恢复周期中，如果日志文件丢失，它们将根据 innodb_log_file_size 重新生成。设置。

请参阅MySQL Documentation for a detailed explanation of InnoDB .

@karatedog InnoDB 的 MVCC 部分发生在系统表空间内，更广为人知的是 ibdata1。记录事务开始之前的任何数据，以允许访问所需行的其他人在实现任何更新之前查看数据。这允许所谓的可重复读取。这属于 ACID 合规性的 I，我的意思是隔离。我在 DBA StackExchange 中写了关于事务隔离好、坏或丑陋的各种场景的帖子。

• read before write transaction
• Will these two queries result in a deadlock if executed in sequence?
• Is raid 5 suitable for mysql installation?

至于MyISAM，crash recovery is not automatic. It crashes rather easily .这就是 SQL 命令 REPAIR TABLE 存在的原因。这也是为什么 MySQL 实用程序 myisamchk 具有 -r 选项来为不在线的 MyISAM 表执行 REPAIR TABLE 的原因。

MariaDB and Aria一直在尝试制造一个安全存储引擎来替代 MyISAM。