MySQL中常见的日志题目介绍
MySQL 里有两个日志，即：重做日志（redo log）和归档日志（binlog）。（举荐课程：MySQL教程）
其中，binlog 可以给备库运用，也可以保留起来用于恢复数据库历史数据。它是实此刻 server 层的，所有引擎可以共用。redo log 是 InnoDB 特有的日志，用来支撑 crash-safe 能力。
你一定听过 MySQL 事务的两阶段提交，指的就是在事务提交的时候，分成 prepare 和 commit 两个阶段。
如图 1 所示为一个事务的施行流程，你在最后三步可以看到，redo log 先 prepare 完成，再写 binlog，最后才进入 redo log commit 阶段。
图 2 只用 binlog 支撑解体恢复
这样的流程下，binlog 还是不克不及支撑解体恢复的。我说一个不支撑的点吧：binlog 没有能力恢复“数据页”。
要是在图中标的位置，也就是 binlog2 写完了，但是整个事务尚无 commit 的时候，MySQL 产生了 crash。
重新启动后，引擎内部事务 2 会回滚，然后利用 binlog2 可以补回归；但是关于事务 1 来说，系统已经以为提交完成了，不会再利用一次 binlog1。
但是，InnoDB 引擎运用的是 WAL 技术，施行事务的时候，写完内存和日志，事务就算完成了。要是之后解体，要依赖于日志来恢复数据页。
也就是说在图中这个位置产生解体的话，事务 1 也是可能遗失了的，并且是数据页级的遗失。此时，binlog 里面并没有记载数据页的更新细节，是补不回归的。
你要是要说，那我优化一下 binlog 的内容，让它来记载数据页的更改可以吗？可以，但这其实就是又做了一个 redo log 出来。
所以，至少此刻的 binlog 能力，还不克不及支撑解体恢复。
题目 6：那能不克不及反过来，只用 redo log，不要 binlog？
答复：要是只从解体恢复的角度来讲是可以的。你可以把 binlog 关掉，这样就没有两阶段提交了，但系统仍然是 crash-safe 的。
但是，要是你理解一下业界各个企业的运用场景的话，就会发明在正式的生产库上，binlog 都是开着的。由于 binlog 有着 redo log 没法替换的功能。
一个是归档。redo log 是轮回写，写到末尾是要回到开头继续写的。这样历史日志无法保存，redo log 也就起不到归档的作用。
一个就是 MySQL 系统依赖于 binlog。binlog 作为 MySQL 一开端就有的功能，被用在了许多地方。其中，MySQL 系统高可用的根基，就是 binlog 复制。
还有许多企业有异构系统（比方一些数据剖析系统），这些系统就靠消费 MySQL 的 binlog 来更新本人的数据。关掉 binlog 的话，这些下流系统就无法输入了。
总之，因为此刻包含 MySQL 高可用在内的许多系统机制都依赖于 binlog，所以“鸠占鹊巢” redo log 还做不到。你看，开展生态是多么重要。
最后，举荐你关注丁奇的《MySQL 实战 45 讲》专栏。在专栏里，丁奇会帮你梳理出学习 MySQL 的主线见识，比方事务、索引、锁等，还会就开发历程中时常碰到的概括题目和你剖析计议，而且帮你了解题目背后的本质。你会收成 MySQL 中心技术详解与道理注明和 36 个 MySQL 常见痛点题目解析。
statement 格局的 binlog，最后会有 COMMIT；
row 格局的 binlog，最后会有一个 XID event。
别的，在 MySQL 5.6.2 版本今后，还引入了 binlog-checksum 参数，用来验证 binlog 内容的准确性。关于 binlog 日志因为磁盘缘由，可能会在日志中间出错的状况，MySQL 可以通过校验 checksum 的效果来发明。所以，MySQL 还是有方法验证事务 binlog 的完备性的。
题目 2：redo log 和 binlog 是怎么关联起来的?
答复：它们有一个共同的数据字段，叫 XID。解体恢复的时候，会按次序扫描 redo log：
以上就是MySQL中常见的日志题目介绍的细致内容，更多请关注 百分百源码网 其它相干文章！
