mysql深入浅出之日志(redolog, binlog, undolog)

淡淡的烟草味﹌ 2022-09-03 14:22 221阅读 0赞

### 文章目录 ###

*  1. \[重做日志 \`redo log\` \](https://www.bilibili.com/video/BV1hB4y1F7Bx?p=2)
 *   *  1.1. 介绍
     *  1.2. 工作原理
     *  1.3. redolog写入机制
     *  1.4. 为何数据更新不直接写到磁盘上去? 还搞redo buffer等?
     *  1.5. 持久化到redolog的时间不耗时么?
     *  1.6. redolog 相关配置参数
 *  2. \[归档日志 \`binlog\`\](https://www.bilibili.com/video/BV1tN411Z7iJ)
 *   *  2.1. 介绍
     *  2.2. 开启binlog的场景
     *  2.3. 文件记录模式有三种
     *  2.4. binlog文件结构
     *  2.5. binlog写入机制
     *  2.6. binlog的实际操作
 *  3. redolog和binlog的区别
 *   *  3.1. 为何会有两份日志 redolog和binlog呢?
     *  3.2. 为什么必须有“两阶段提交”呢？
     *  3.3. 建议:
     *  3.4. 学习收获
 *  4. 事务回滚日志 undolog
 *   *  4.1. undolog 介绍
     *  4.2. undolog 作用
 *  5. 总结

![请添加图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMyNDYwODE5_size_16_color_FFFFFF_t_70]

**一条更新语句的执行流程**  
[学习视频 redolog undolog binlog][redolog undolog binlog]

读完下文, 你应该明白 MySQL可以恢复到半个月内任意一秒的状态是怎么操作的

mysql> create table T(ID int primary key, c int); # 创建表
    mysql> update T set c=c+1 where ID=2; # 更新表

前面我们说过，在一个表上有更新的时候，跟这个表有关的查询缓存会失效，所以这条语句就会把表T上所有缓存结果都清空。这也就是我们一般不建议使用查询缓存的原因。

1.  连接器 链接数据库
2.  分析器 词法确定更新语句, 语法解析判断是否能有表T和字段ID和c
3.  优化器 发现有索引ID可用
4.  执行器 找到这一行, 更新

与查询流程不一样的是，更新流程还涉及两个重要的日志模块，它们正是我们今天要讨论的主角：`redo log`（重做日志）和 `bin log`（归档日志）。如果接触MySQL，那这两个词肯定是绕不过的，我后面的内容里也会不断地和你强调。不过话说回来，redo log和binlog在设计上有很多有意思的地方，这些设计思路也可以用到你自己的程序里。

# 1. [重做日志 `redo log` ][redolog undolog binlog] #

不知道你还记不记得《孔乙己》这篇文章，酒店掌柜有一个粉板，专门用来记录客人的赊账记录。如果赊账的人不多，那么他可以把顾客名和账目写在板上。但如果赊账的人多了，粉板总会有记不下的时候，这个时候掌柜一定还有一个专门记录赊账的账本。

如果有人要赊账或者还账的话，掌柜一般有两种做法：

一种做法是直接把账本翻出来，把这次赊的账加上去或者扣除掉；  
另一种做法是先在粉板上记下这次的账，等打烊以后再把账本翻出来核算。  
在生意红火柜台很忙时，掌柜一定会选择后者，因为前者操作实在是太麻烦了。首先，你得找到这个人的赊账总额那条记录。你想想，密密麻麻几十页，掌柜要找到那个名字，可能还得带上老花镜慢慢找，找到之后再拿出算盘计算，最后再将结果写回到账本上。

这整个过程想想都麻烦。相比之下，还是先在粉板上记一下方便。你想想，如果掌柜没有粉板的帮助，每次记账都得翻账本，效率是不是低得让人难以忍受？

同样，在MySQL里也有这个问题，如果每一次的更新操作都需要写进磁盘，然后磁盘也要找到对应的那条记录，然后再更新，整个过程IO成本、查找成本都很高。为了解决这个问题，MySQL的设计者就用了类似酒店掌柜粉板的思路来提升更新效率。

而粉板和账本配合的整个过程，其实就是MySQL里经常说到的WAL技术，WAL的全称是**Write-Ahead Logging**，它的关键点就是先写日志，再写磁盘，也就是先写粉板，等不忙的时候再写账本。

具体来说，当有一条记录需要更新的时候，InnoDB引擎就会先把记录写到redo log（粉板）里面，并更新内存，这个时候更新就算完成了。同时，InnoDB引擎会在适当的时候，将这个操作记录更新到磁盘里面，而这个更新往往是在系统比较空闲的时候做，这就像打烊以后掌柜做的事。

如果今天赊账的不多，掌柜可以等打烊后再整理。但如果某天赊账的特别多，粉板写满了，又怎么办呢？这个时候掌柜只好放下手中的活儿，把粉板中的一部分赊账记录更新到账本中，然后把这些记录从粉板上擦掉，为记新账腾出空间。

与此类似，InnoDB的redo log是固定大小的，比如可以配置为一组4个文件，每个文件的大小是1GB，那么这块“粉板”总共就可以记录4GB的操作。从头开始写，写到末尾就又回到开头循环写，这就是redolog的写入机制.

## 1.1. 介绍 ##

1.  redolog是InnoDB数据库存储引擎的特有日志, 也就是收redolog属于引擎层
2.  redo的意思是重做, 以恢复操作为目的, 在数据库发生意外时重现操作
3.  redolog指的是事务中修改任何数据, 将最新的数据备份存储的位置(redolog), 被称为重做日志
4.  生成/销毁: 随着事务操作的执行, 会生成redolog , 在事务提交时, 产生redolog写入log Buffer, 并不是随着事物的提交就立即写入磁盘; 等待事务操作的脏页写入磁盘后, redolog使命完成, redolog占用空间就可以重用了(覆盖写入)
5.  脏页指的是内存和磁盘数据不一致, 比如内存里面更改了, 但是还没应用到磁盘中

## 1.2. 工作原理 ##

redolog是为了实现事务的持久化而出现的产物, 防止在发生故障时间点, 尚有脏页未写入表IBD文件中, 在重启MySQL服务时, 根据redolog进行重做, 从而达到事务的未入磁盘数据进行持久化这一特性;

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMyNDYwODE5_size_16_color_FFFFFF_t_70 1]

## 1.3. redolog写入机制 ##

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMyNDYwODE5_size_16_color_FFFFFF_t_70 2]

redolog文件内容是顺序循环写入文件, 写满时回溯到第一个文件进行覆盖写, 跟队列一样; `write pos`是当前记录的位置，一边写一边后移，写到第3号文件末尾后就回到0号文件开头。`checkpoint`是当前要擦除的位置，也是往后推移并且循环的，擦除记录前要把记录更新到数据文件。

`write pos`和`checkpoint`之间的是“粉板”上还空着的部分，可以用来记录新的操作。如果write pos追上checkpoint，表示“粉板”满了，这时候不能再执行新的更新，得停下来先擦掉一些记录，把checkpoint推进一下。

有了`redo log`，InnoDB就可以保证即使数据库发生异常重启，之前提交的记录都不会丢失，这个能力称为crash-safe。

要理解crash-safe这个概念，可以想想我们前面赊账记录的例子。只要赊账记录记在了粉板上或写在了账本上，之后即使掌柜忘记了，比如突然停业几天，恢复生意后依然可以通过账本和粉板上的数据明确赊账账目。

## 1.4. 为何数据更新不直接写到磁盘上去? 还搞redo buffer等? ##

如果直接将User更新直接放到磁盘上, 那么操作系统跟磁盘的交互数量更多, 而操作系统的时间占用尤其磁盘读写时间长, 所以为了尽可能的减少磁盘的交互次数, 使用redobuffer等, 先内存中攒着, 在持久化, 这样就可以降低磁盘交互次数;

## 1.5. 持久化到redolog的时间不耗时么? ##

比如更新a=2, 然后更新a=5, 在更新a=8, 这样持久化到redolog的时间是一个IO, 但是更新到User.IBD, 需要先定位a, 在更新, 所以会占用很多IO时间, 因此利用redolog暂时记录, 效率会高;

## 1.6. redolog 相关配置参数 ##

每个InnoDB存储引擎至少一个重做日志组`group`, 每个文件组至少两个重做日志文件, 默认为 `ib_logfile0` 和 `ib_logfile1`

mysql> show variables like '%innodb_log%';
    +-----------------------------+----------+
    | Variable_name               | Value    |
    +-----------------------------+----------+
    | innodb_log_buffer_size      | 16777216 |
    | innodb_log_checksums        | ON       |
    | innodb_log_compressed_pages | ON       |
    | innodb_log_file_size        | 50331648 |
    | innodb_log_files_in_group   | 2        |
    | innodb_log_group_home_dir   | ./       |
    | innodb_log_write_ahead_size | 8192     |
    +-----------------------------+----------+
    7 rows in set (0.01 sec)
    
    mysql>

`redo buffer` 持久化到`redolog` 策略可以通过`innodb_flush_log_at_trx_commit` 设置;

*  0: `buffer pool`随着事务提交commit, 写入到`logBuffer` 不直接写入到log文件中, 后台有个线程将 `logBuffer` 1s写到硬盘一次(`OS cache`负责); 这样可能会造成1s的数据丢失
 *  1: commit提交时会直接写`OS cache`, 操作系统就会直接写到磁盘中; 最安全, 但是性能最差
 *  2: commit提交时会写入 `log BUffer` 在写入`OS cache`, 但是操作系统不会直接写入到磁盘, 而是1s执行 `flush cache to disk` 操作;

总之:

*  事务`commit write` \--> 内存`logBuffer` \--> 操作系统控制内存写入磁盘线程`OS cache` \--> 日志log(磁盘)
 *  建议设置策略2, 因为`OS cache`操作相对安全(只要操作系统没死), 间接相当于内存成功写入磁盘中了

# 2. [归档日志 `binlog`][_binlog] #

## 2.1. 介绍 ##

1.  Server层的日志用于归档日志
2.  记录事务原子性,
3.  记录所有数据库表结构变更以及数据修改的二进制日志(不会记录查询和show这类操作)
4.  binlog日志以事件形式记录, 包含语句所执行的消耗时间

## 2.2. 开启binlog的场景 ##

因为binlog一般是关闭状态, 占用系统资源较大 1%, 一般只有下面两种场景会打开

1.  主从复制: 主库开启, 这样就可以把binlog传递给从库, 从库根据binlog恢复表数据, 一致性
2.  数据恢复: 万一有人删除表的情况, 通过`mysqlbinlog`工具恢复

## 2.3. 文件记录模式有三种 ##

1.  **ROW**(row\_based\_replication, RBP): 日志中会记录每一行数据被修改情况, 在slave端进行相同数据修改;  
    **优势:** 实现数据的完全恢复,  
    **缺点:** 更改100行, 会产生100行记录, 消耗大量资源;
2.  STATMENT(statement-based replication SBR): 每条修改数据的SQL记录到master的binlog中, slave在复制的时候, SQL进程会解析成和原来master端执行过的相同的SQL在执行, 简称SQL复制;  
    **优势:** 日志量少, 减少磁盘IO, 提升存储和恢复速度  
    **缺点:** 但是记录的一些参数会有差异, 比如`now()`时间, `last_insert_id()`等函数, 这样就不能恢复这条数据了
3.  MIXED(mixed-based replication MBR): 上面两种模式混合使用, 一般使用statement模式保存binlog, 对于statement模式无法复制的操作使用row保存, mysql会根据执行的sql语句选择写入模式

所以主从复制使用记录模式1 `ROW模式`

## 2.4. binlog文件结构 ##

mysql的binlog文件中记录的是对数据库的各种修改操作, 用来表示修改操作的数据结构是 `log event`, 不同的修改操作对应的不同的`log event` 比较常用的 `log event` 有: `Query event`, `Row event`, `XID Event`等  
binlog文件的内容是各种log event集合

*  `log event` 结构

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMyNDYwODE5_size_16_color_FFFFFF_t_70 3]

## 2.5. binlog写入机制 ##

*  根据记录模式和操作触发event时间生成log event(事件触发执行机制)
 *  事务执行过程中产生的log event写入缓冲区, 每个事务线程都有一个缓冲区, 保存成`binlog_cache_mngr数据结构`, 这个结构中有两个缓冲区(1, stmt\_cache 存放不支持事务信息, 2,trx\_cache, 存放支持事务的信息)
 *  事务提交, 会将log event写入外部binlog文件中;

**注意**: 不同事务以串行方式写入binlog文件中, 所以一个事务包含一个log event信息

## 2.6. binlog的实际操作 ##

下文命令流程实现的是从创建数据库, 创建数据库表, 插入和更新数据到删表删库跑路, 在利用binlog恢复数据库的操作流程;

*  启动binlog

*  查看日志

*  利用binlog恢复数据

# 按时间恢复
    mysqlbinlog --start-datetime="2020-04-25 18:00:00" --stop-datetime="2020-04-26 18:00:00" mysqlbinlog.000002 | mysql -uroot -p123456
    
    # 按时间位置号恢复
    mysqlbinlog --start-position=154 --stop-position=356 mysqlbinlog.000002 | mysql -uroot -p123456

*  实际操作

mysql> show databases; # 显示数据库所有
    mysql> create database mytest default character set utf8; # 创建数据库mytest
    Query OK, 1 row affected (0.07 sec)
    
    mysql> show databases; # 显示数据库所有
    +--------------------+
    | Database           |
    +--------------------+
    | mytest             |
    +--------------------+
    
    mysql> use mytest; # 选择数据库mytest
    Database changed
    mysql> create table user( # 创建表
        -> id int primary key,
        -> name varchar(20)
        -> ) engine=innodb
        -> charset=utf8;
    Query OK, 0 rows affected (0.47 sec)
    
    mysql> insert into user values (1, "tom"); # 插入数据
    mysql> insert into user values (2, "scott");
    mysql> select * from user; # 查询表
    +----+-------+
    | id | name  |
    +----+-------+
    |  1 | tom   |
    |  2 | scott |
    +----+-------+
    mysql> update user set name="TOM" where id = 1; # 更新数据
    mysql> drop database mytest; # 删表
    mysql> select * from user;
    ERROR 1046 (3D000): No database selected
    mysql> show master logs; # 显示当前有多少个binlog文件
    +------------------+-----------+
    | Log_name         | File_size |
    +------------------+-----------+
    | mysql-bin.000001 |       177 |
    | mysql-bin.000002 |      1546 |
    +------------------+-----------+
    
    mysql> show binlog events in "mysql-bin.000002" ;  # 查看当前所有的binlog记录
    +------------------+------+----------------+-----------+-------------+----------------------------------------------------------------------------------------------------+
    | Log_name         | Pos  | Event_type     | Server_id | End_log_pos | Info                                                                                               |
    +------------------+------+----------------+-----------+-------------+----------------------------------------------------------------------------------------------------+
    | mysql-bin.000002 |    4 | Format_desc    |         1 |         123 | Server ver: 5.7.33-0ubuntu0.18.04.1-log, Binlog ver: 4                                             |
    | mysql-bin.000002 |  123 | Previous_gtids |         1 |         154 |                                                                                                    |
    | mysql-bin.000002 |  154 | Anonymous_Gtid |         1 |         219 | SET @@SESSION.GTID_NEXT= 'ANONYMOUS'                                                               |
    | mysql-bin.000002 |  219 | Query          |         1 |         346 | create database mytest default character set utf8                                                  |
    | mysql-bin.000002 |  346 | Anonymous_Gtid |         1 |         411 | SET @@SESSION.GTID_NEXT= 'ANONYMOUS'                                                               |
    | mysql-bin.000002 |  411 | Query          |         1 |         573 | use `mytest`; create table user(
    id int primary key,
    name varchar(20)
    ) engine=innodb
    charset=utf8 |
    | mysql-bin.000002 |  573 | Anonymous_Gtid |         1 |         638 | SET @@SESSION.GTID_NEXT= 'ANONYMOUS'                                                               |
    | mysql-bin.000002 |  638 | Query          |         1 |         712 | BEGIN                                                                                              |
    | mysql-bin.000002 |  712 | Table_map      |         1 |         764 | table_id: 108 (mytest.user)                                                                        |
    | mysql-bin.000002 |  764 | Write_rows     |         1 |         808 | table_id: 108 flags: STMT_END_F                                                                    |
    | mysql-bin.000002 |  808 | Xid            |         1 |         839 | COMMIT /* xid=22 */                                                                                |
    | mysql-bin.000002 |  839 | Anonymous_Gtid |         1 |         904 | SET @@SESSION.GTID_NEXT= 'ANONYMOUS'                                                               |
    | mysql-bin.000002 |  904 | Query          |         1 |         978 | BEGIN                                                                                              |
    | mysql-bin.000002 |  978 | Table_map      |         1 |        1030 | table_id: 108 (mytest.user)                                                                        |
    | mysql-bin.000002 | 1030 | Write_rows     |         1 |        1076 | table_id: 108 flags: STMT_END_F                                                                    |
    | mysql-bin.000002 | 1076 | Xid            |         1 |        1107 | COMMIT /* xid=23 */                                                                                |
    | mysql-bin.000002 | 1107 | Anonymous_Gtid |         1 |        1172 | SET @@SESSION.GTID_NEXT= 'ANONYMOUS'                                                               |
    | mysql-bin.000002 | 1172 | Query          |         1 |        1246 | BEGIN                                                                                              |
    | mysql-bin.000002 | 1246 | Table_map      |         1 |        1298 | table_id: 108 (mytest.user)                                                                        |
    | mysql-bin.000002 | 1298 | Update_rows    |         1 |        1352 | table_id: 108 flags: STMT_END_F                                                                    |
    | mysql-bin.000002 | 1352 | Xid            |         1 |        1383 | COMMIT /* xid=25 */                                                                                |
    | mysql-bin.000002 | 1383 | Anonymous_Gtid |         1 |        1448 | SET @@SESSION.GTID_NEXT= 'ANONYMOUS'                                                               |
    | mysql-bin.000002 | 1448 | Query          |         1 |        1546 | drop database mytest                                                                               |
    +------------------+------+----------------+-----------+-------------+----------------------------------------------------------------------------------------------------+
    23 rows in set (0.00 sec)
    
    # 从 219 建库到删除前1383恢复, 这个从shell中执行
    mysql> mysqlbinlog --start-position=219 --stop-position=1383 mysql-bin.000002 | mysql -uro
    ot -p
    
    
    mysql> show databases;
    +--------------------+
    | Database           |
    +--------------------+
    | information_schema |
    | mysql              |
    | mytest             |
    | performance_schema |
    | sys                |
    +--------------------+
    5 rows in set (0.00 sec)
    
    mysql> use mytest;
    mysql> select * from user;
    +----+-------+
    | id | name  |
    +----+-------+
    |  1 | TOM   |
    |  2 | scott |
    +----+-------+

*  binlog删除和清除

purge binary logs to "mysqlbinlog.000001"; # 删除指定文件
    purge binary logs before "2020-04-28 00:00:00"; # 删除时间
    reset master; # 清除所有

*  日志设置有效期

mysql> set global expire_logs_days=7; # 设置超过7天后删除对应的binlog
    mysql> show variables like '%expire_logs_days%'; # 显示值
    +------------------+-------+
    | Variable_name    | Value |
    +------------------+-------+
    | expire_logs_days | 7     |
    +------------------+-------+

# 3. redolog和binlog的区别 #

## 3.1. 为何会有两份日志 redolog和binlog呢? ##

因为最开始MySQL里并没有InnoDB引擎。MySQL自带的引擎是MyISAM，但是MyISAM没有`crash-safe`的能力，`binlog`日志只能用于归档。而InnoDB是另一个公司以插件形式引入MySQL的，既然只依靠binlog是没有`crash-safe`能力的，所以InnoDB使用另外一套日志系统——也就是`redo log`来实现`crash-safe`能力。

这两种日志有以下三点不同。

1.  redo log是InnoDB引擎特有的；binlog是MySQL的Server层实现的，所有引擎都可以使用, 二进制文件存储。
2.  redo log是物理日志，记录的是数据页更新状态内容；binlog是逻辑日志，记录的是这个语句的原始逻辑, 记录的更新过程，比如“给ID=2这一行的c字段加1 ”。
3.  redo log是循环写的，空间固定会用完；binlog是可以追加写入的。“追加写”是指binlog文件写到一定大小后会切换到下一个，并不会覆盖以前的日志。
4.  redolog解决服务器异常, 宕机后数据恢复, 属于内部自动机制; binlog作为主从复制和数据恢复使用, 没有自动恢复能力, 需要手动恢复;

有了对这两个日志的概念性理解，我们再来看执行器和InnoDB引擎在执行这个简单的update语句时的内部流程。

执行器先找引擎取ID=2这一行。ID是主键，引擎直接用树搜索找到这一行。如果ID=2这一行所在的数据页本来就在内存中，就直接返回给执行器；否则，需要先从磁盘读入内存，然后再返回。

执行器拿到引擎给的行数据，把这个值加上1，比如原来是N，现在就是N+1，得到新的一行数据，再调用引擎接口写入这行新数据。

引擎将这行新数据更新到内存中，同时将这个更新操作记录到redo log里面，此时redo log处于prepare状态。然后告知执行器执行完成了，随时可以提交事务。

执行器生成这个操作的binlog，并把binlog写入磁盘。

执行器调用引擎的提交事务接口，引擎把刚刚写入的redo log改成提交（commit）状态，更新完成。

这里我给出这个update语句的执行流程图，图中浅色框表示是在InnoDB内部执行的，深色框表示是在执行器中执行的。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMyNDYwODE5_size_16_color_FFFFFF_t_70 4]

你可能注意到了，最后三步看上去有点“绕”，将redo log的写入拆成了两个步骤：prepare和commit，这就是"两阶段提交"。

## 3.2. 为什么必须有“两阶段提交”呢？ ##

这是为了让两份日志之间的逻辑一致  
前面我们说过了，binlog会记录所有的逻辑操作，并且是采用“追加写”的形式。如果你的DBA承诺说半个月内可以恢复，那么备份系统中一定会保存最近半个月的所有binlog，同时系统会定期做整库备份。这里的“定期”取决于系统的重要性，可以是一天一备，也可以是一周一备。  
当需要恢复到指定的某一秒时，比如某天下午两点发现中午十二点有一次误删表，需要找回数据，那你可以这么做：

*  首先，找到最近的一次全量备份，如果你运气好，可能就是昨天晚上的一个备份，从这个备份恢复到临时库；
 *  然后，从备份的时间点开始，将备份的binlog依次取出来，重放到中午误删表之前的那个时刻。

这样你的临时库就跟误删之前的线上库一样了，然后你可以把表数据从临时库取出来，按需要恢复到线上库去。

好了，说完了数据恢复过程，我们回来说说，为什么日志需要“两阶段提交”。这里不妨用反证法来进行解释。

由于redo log和binlog是两个独立的逻辑，如果不用两阶段提交，要么就是先写完redo log再写binlog，或者采用反过来的顺序。我们看看这两种方式会有什么问题。

仍然用前面的update语句来做例子。假设当前ID=2的行，字段c的值是0，再假设执行update语句过程中在写完第一个日志后，第二个日志还没有写完期间发生了crash，会出现什么情况呢？

1.  **先写redo log后写binlog**。假设在redo log写完，binlog还没有写完的时候，MySQL进程异常重启。由于我们前面说过的，redo log写完之后，系统即使崩溃，仍然能够把数据恢复回来，所以恢复后这一行c的值是1。  
    但是由于binlog没写完就crash了，这时候binlog里面就没有记录这个语句。因此，之后备份日志的时候，存起来的binlog里面就没有这条语句。  
    然后你会发现，如果需要用这个binlog来恢复临时库的话，由于这个语句的binlog丢失，这个临时库就会少了这一次更新，恢复出来的这一行c的值就是0，与原库的值不同。
2.  **先写binlog后写redo log**。如果在binlog写完之后crash，由于redo log还没写，崩溃恢复以后这个事务无效，所以这一行c的值是0。但是binlog里面已经记录了“把c从0改成1”这个日志。所以，在之后用binlog来恢复的时候就多了一个事务出来，恢复出来的这一行c的值就是1，与原库的值不同。  
    可以看到，如果不使用“两阶段提交”，那么数据库的状态就有可能和用它的日志恢复出来的库的状态不一致。

你可能会说，这个概率是不是很低，平时也没有什么动不动就需要恢复临时库的场景呀？

其实不是的，不只是误操作后需要用这个过程来恢复数据。当你需要扩容的时候，也就是需要再多搭建一些备库来增加系统的读能力的时候，现在常见的做法也是用全量备份加上应用binlog来实现的，这个“不一致”就会导致你的线上出现主从数据库不一致的情况。

简单说，redo log和binlog都可以用于表示事务的提交状态，而两阶段提交就是让这两个状态保持逻辑上的一致。

## 3.3. 建议: ##

1.  redo log用于保证`crash-safe`能力。`innodb_flush_log_at_trx_commit`这个参数设置成1的时候，表示每次事务的redo log都直接持久化到磁盘。这个参数我建议你设置成1，这样可以保证MySQL异常重启之后数据不丢失。
2.  `sync_binlog`这个参数设置成1的时候，表示每次事务的binlog都持久化到磁盘。这个参数我也建议你设置成1，这样可以保证MySQL异常重启之后binlog不丢失。

我还跟你介绍了与MySQL日志系统密切相关的“两阶段提交”。两阶段提交是跨系统维持数据逻辑一致性时常用的一个方案，即使你不做数据库内核开发，日常开发中也有可能会用到。

## 3.4. 学习收获 ##

redo是物理的，binlog是逻辑的；现在由于redo是属于InnoDB引擎，所以必须要有binlog，因为你可以使用别的引擎  
保证数据库的一致性，必须要保证2份日志一致，使用的2阶段式提交；其实感觉像事务，不是成功就是失败，不能让中间环节出现，也就是一个成功，一个失败  
如果有一天mysql只有InnoDB引擎了，有redo来实现复制，那么感觉oracle的DG就诞生了，物理的速度也将远超逻辑的，毕竟只记录了改动向量  
binlog几大模式，一般采用row，因为遇到时间，从库可能会出现不一致的情况，但是row更新前后都有，会导致日志变大  
最后2个参数，保证事务成功，日志必须落盘，这样，数据库crash后，就不会丢失某个事务的数据了  
其次说一下，对问题的理解  
备份时间周期的长短，感觉有2个方便  
首先，是恢复数据丢失的时间，既然需要恢复，肯定是数据丢失了。如果一天一备份的话，只要找到这天的全备，加入这天某段时间的binlog来恢复，如果一周一备份，假设是周一，而你要恢复的数据是周日某个时间点，那就，需要全备+周一到周日某个时间点的全部binlog用来恢复，时间相比前者需要增加很多；看业务能忍受的程度  
其次，是数据库丢失，如果一周一备份的话，需要确保整个一周的binlog都完好无损，否则将无法恢复；而一天一备，只要保证这天的binlog都完好无损；当然这个可以通过校验，或者冗余等技术来实现，相比之下，上面那点更重要

# 4. 事务回滚日志 undolog #

## 4.1. undolog 介绍 ##

1.  undo: 意味撤销或取消, 以撤销操作为目的, 返回指定某个状态的操作
2.  undolog: 数据库事务开始之前, 会将修改记录存放到undolog中, 当事务回滚时,或数据库崩溃时, 可以利用undolog, 撤销未提交事务对数据库产生的影响.
3.  undolog产生时间: undolog在事务开始前产生;
4.  undolog销毁时间: 事务在提交时, 并不会立刻删除undolog, 因为这个过程中可能需要用到undolog, 比如MVCC多版本控制; InnoDB会将该事务对应的undolog入到删除列表中, 后面会通过\*\*后台线程`purge thread`\*\*进行回收处理.
5.  undolog相当于逻辑日志, 记录的是变化过程, 比如做一个删除`delete`, undolog记录`insert`, 反言之, 做`insert`操作, undolog记录`delete`, 这样在出问题时, 就可以直接运行undolog回滚到起始位置
6.  undolog存储: undolog采用段方式管理和记录, 在InnoDB数据文件中包含一种`rollback segment`回滚段, 内部包含1024个`undolog segment`
7.  查看底层文件: `show variables like '%innodb_undo%'`

## 4.2. undolog 作用 ##

1.  就是把所有没有`COMMIT`的事务回滚到事务开始之前的状态
2.  为了实现事务的原子性: 事务处理过程中, 一旦出错, 或者用户执行`rollback`语句, 利用undolog备份将数据恢复到事务开始之前状态
3.  多版本并发控制(MVCC): Undolog在MySQL InnoDB存储引擎中, 用来实现多版本并发控制, 事务未提交前, UndoLog保存了未提交前的版本数据, undolog中数据可作为数据旧版本快照供其他并发事务进行快照读
    
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMyNDYwODE5_size_16_color_FFFFFF_t_70 5]
    
    事务A手动开启事务, 执行更新, 首先会把更新命中的数据备份到undo Buffer中
    
    事务B手动开启事务, 执行查询操作, 会读取Undolog日志数据返回, 进行快照读

# 5. 总结 #

redolog日志是用来实现事务持久性, 防止发生故障时间点, 尚有脏页未写入表的IBD文件中, 再重启mysql服务, 根据redolog进行重做, 从而实现事务的未写入磁盘数据进行持久化的特性, 这个特性是系统启动后自动识别并进行处理的;

binlog日志用来解决删库跑路的问题, 是手动恢复的;

undolog日志是多版本控制的MVCC底层实现, 根据不同的隔离级别, 进行callback的一个逻辑实现;

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMyNDYwODE5_size_16_color_FFFFFF_t_70]: /images/20220829/e76144b755cd4451bf629d2ae5e0c1f9.png
[redolog undolog binlog]: https://www.bilibili.com/video/BV1hB4y1F7Bx?p=2
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMyNDYwODE5_size_16_color_FFFFFF_t_70 1]: /images/20220829/26d3db6ef50c44688d121fda7cfbacee.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMyNDYwODE5_size_16_color_FFFFFF_t_70 2]: /images/20220829/d6a3885ec007432baa7c3a5d1a735db5.png
[_binlog]: https://www.bilibili.com/video/BV1tN411Z7iJ
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMyNDYwODE5_size_16_color_FFFFFF_t_70 3]: /images/20220829/a4aca4e8ebe8493799decc2b3bbc7db4.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMyNDYwODE5_size_16_color_FFFFFF_t_70 4]: /images/20220829/5c54eba9cbfb4fb68cd1a0b3b7197496.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMyNDYwODE5_size_16_color_FFFFFF_t_70 5]: /images/20220829/91fc46f2b5894ebd892453bbbd56415c.png