Mysql数据库面试必备之三大log介绍(2)-木庄网络博客

不会，因为 undo log 只记录事务开始前数据的原始版本，当再次对这行数据修改时，产生的修改记录会写到 redo log。undo log 负责回滚，redo log负责前滚。

啥是回滚和前滚？

（1）回滚

未提交的事务，即事务未执行 commit。但事务内修改的脏页中，有一部分已刷盘。此时数据库宕机重启，需要回滚来将先前那部分已经刷盘的脏块从磁盘上撤销。

（2）前滚

未完全提交的事务，即事务已经执行 commit，但该事务内修改的脏页中只有一部分数据被刷盘，另一部分还在 buffer pool，此时数据库宕机重启，就要用前滚来将未来得及刷盘的数据从 redo log 中恢复出来并刷盘。?

三、bin log 归档日志（数据库 Server 层二进制逻辑日志、和什么引擎无关）

bin log 记录了用户对数据库所有 sql 操作（不包含查询语句，因为这类操作对数据本身没有修改）。之所以可以称为归档日志，是因为它不会像 redo log 那样循环擦除之前的记录，而是会一直记录日志。一个 bin log 文件默认最大容量1G（可通过 max_binlog_size 参数修改），单个日志超过最大值则会新创建一个文件继续写。
注意：日志可能是基于事务来记录的，而事务不应该跨文件记录，如果 binlog 日志文件达到了最大值但刚好事务还没有提交，此时则不会创建新文件记录，而是继续增大日志。因此 max_binlog_size 的值和实际的 binlog 文件大小不一定相等。

经过上述介绍，binlog 主要用就是主从同步和数据库基于时间点的还原。

那么问题来了，可以没有 binlog 吗（有了 redo log 为啥还需要 bin log）？

需要分场景来看：

主从模式下，binlog 是必须的，因为从库的数据同步需要依赖 binlog；

单机模式下，不考虑数据库基于时间点的还原，binlog 就不是必须的，因为有 redo log 就可以保证 crash-safe 能力了；

redo log 的记录修改落盘后，日志会被覆盖掉，无法用于数据恢复等操作，redo log 是 innodb 引擎层实现的，并不是所有引擎都有；

redo log 与 bin log 的区别？

?什么是 redo log 两阶段提交，为什么要这么做？
更新内存后引擎层写 redo log 将状态改成 prepare 为提交第一阶段，Server 层写 bin log，将状态改成 commit 为提交第二阶段。两阶段提交目的是确保 binl og 和 redo log 数据一致性。

如果不是两阶段提交可能会出现什么情况？
1）假设先写 redo log 再写 bin log，即 redo log 没有 prepare 阶段，写完直接置为commit，然后再写 bin log。如果写完 redo log 后还没写完 bin log 数据库宕机了，重启后系统自动用 redo log 恢复，此时会造成磁盘上数据页数据比 bin log 上的记录数据多，数据不一致。
2）假设先写 bin log 再写 redo log，如果写完 bin log 没写完 redo log 数据库宕机了，那么 bin log 上的记录就会比磁盘上数据页的记录多一些，下次用 bin log 恢复数据，恢复后的数据和原来的数据不一致。

描述一下 redo log 容灾恢复过程？
如果 redo log 是完整（commit 状态）的，直接用 redo log 恢复；
如果 redo log 是预提交 prepare 但不是 commit 状态，此时要去判断 binlog 是否完整，如果完整（commit）那就提交 redo log，再用 redo log 恢复，不完整就回滚事务。

?到此这篇关于Mysql数据库面试必备之三大log介绍的文章就介绍到这了,更多相关Mysql三大log内容请搜索

更多相关Mysql内容来自木庄网络博客

标签：Mysql

返回前面的内容