MySQL的undo、redo、binlog之间的关系

MySQL

MySQL的undo、redo、binlog的区别

|

物理日志：记录的是”在某个数据页上做了什么修改”
逻辑日志：记录的是这个语句的原始逻辑，也就是sql语句，比如”给ID=2这一行的c字段加1 “

【undo log】

事务开始之前，将当前事务版本生成 undo log（Tips：undo log 也会产生 redo log 来保证 undo log 的可靠性）。
事务提交之后，undo log 并不能立马被删除，而是放入待清理的链表，由 purge 线程判断是否有其它事务在使用 undo 段中表的上一个事务之前的版本信息，从而决定是否可以清理 undo log 的日志空间。
数据库事务四大特性中有一个是 原子性 ，具体来说就是 原子性是指对数据库的一系列操作，要么全部成功，要么全部失败，不可能出现部分成功的情况。
实际上， 原子性 底层就是通过undo log实现的。undo log主要记录了数据的逻辑变化，比如一条INSERT语句，对应一条DELETE的undo log，对于每个UPDATE语句，对应一条相反的UPDATE的undo log，这样在发生错误时，就能回滚到事务之前的数据状态。例如，user表中原记录如下：

执行sql update user set name = 'xiaohong' where id = 1; 的时候生成的undo log大概是update user set name = 'xiaoming' where id = 1;
同时，undo log也是MVCC(多版本并发控制)实现的关键。

【redo log】

mysql是如何保证事务的持久性的呢？最简单的做法是在每次事务提交的时候，将该事务涉及修改的数据页全部刷新到磁盘中。但是这么做会有严重的性能问题，主要体现在两个方面：

1. 因为Innodb是以页为单位进行磁盘交互的，而一个事务很可能只修改一个数据页里面的几个字节，这个时候将完整的数据页刷到磁盘的话，太浪费资源了！
2. 一个事务可能涉及修改多个数据页，并且这些数据页在物理上并不连续，使用随机IO写入性能太差！

因此，mysql设计了redo log机制，并通过WAL（Write-Ahead Logging）技术进行了性能优化。WAL的核心就是先顺序IO写日志磁盘、再随机IO写数据磁盘，节省的是随机写磁盘的 IO 消耗。mysql 每执行一条 DML 语句，先将记录顺序追加写入 redo log buffer并更新内存中的数据，等到有空闲线程、内存不足、Redo Log满时再批量落盘持久化。

【binlog】

binlog是mysql的逻辑日志并且由Server层进行记录，记录对象为任意数据库引擎的写入性操作(不包括查询)信息，以二进制的形式保存在磁盘中。
在实际应用中，binlog的主要使用场景有两个，分别是 主从复制 和 数据恢复 。

1. 主从复制 ：在Master端开启binlog，然后将binlog发送到各个Slave端，Slave端重放binlog从而达到主从数据一致。
2. 数据恢复 ：通过使用mysqlbinlog工具来恢复数据。

数据更新过程中，万一更新数据的过程中系统出现故障异常重启了，如何保证事务的持久性、原子性呢？概述如下：

1. 记录此次更新前数据记录的快照现场（即写undo log）
2. 读取此次更新所需要的数据入内存
3. 在内存中更新数据（效率高）
4. 写redo log，并置redo log状态为prepare
5. 写binlog
6. 置redo log状态为commit

基于上述简化版的undo log、redo log和binlog的写入流程，我们来梳理下原子性、持久性、一致性的可靠性保证：
A）假如是在步骤1/2/3中任一步骤发生故障，故障恢复后发现redo log中并无未完成的记录，故障恢复后只需要回滚undo log恢复现场即可；
B）假如在步骤4/5中任一步骤发生故障，故障恢复后发现redo log处于prepare状态，则进一步判断是否已经写入binlog：

1. 若已经写入binlog，则重新执行redo log的相关记录直到成功达到commit状态（主从的一致性）；
2. 若未写入binlog，则回滚undo log恢复现场（原子性）；

C）假如在步骤6发生故障，故障恢复后发现redo log处于commit状态，表示过程全部正常完成，则什么都不需要做