MySQL中存在三种日志:
- undo log(回滚日志) :是 Innodb 存储引擎层生成的日志,实现了事务中的原子性 ,主要用于事务回滚和 MVCC。
- redo log(重做日志) :是 Innodb 存储引擎层生成的日志,实现了事务中的持久性 ,主要用于掉电等故障恢复;
- binlog (归档日志) :是 Server 层生成的日志,主要用于数据备份和主从复制;
一、回滚日志undo log
undo log(回滚日志),它保证了事务的ACID中的原子性(Atomicity) 。undo log 是一种用于撤销回退的日志。在事务没提交之前,MySQL 会先记录更新前的数据到 undo log 日志文件里面,当事务回滚时,就读取 undo log 里的数据,然后做原先相反操作。
一条记录的每一次更新操作产生的 undo log 格式都有一个roll_pointer 指针 和一个 trx_id 事务id:
- 通过 trx_id 可以知道该记录是被哪个事务修改的;
- 通过 roll_pointer 指针可以将这些 undo log 串成一个链表,这个链表就被称为版本链;
另外,可以通过 ReadView + undo log 实现 MVCC(多版本并发控制)。对于「读提交」和「可重复读」隔离级别的事务来说,它们的快照读(普通 select 语句)是通过 Read View + undo log 来实现的,它们的区别在于创建 Read View 的时机不同:
- 读提交 隔离级别是在每个 select 都会生成一个新的 Read View,也意味着,事务期间的多次读取同一条数据,前后两次读的数据可能会出现不一致,因为可能这期间另外一个事务修改了该记录,并提交了事务。
- 可重复读 隔离级别是启动事务时生成一个 Read View,然后整个事务期间都在用这个 Read View,这样就保证了在事务期间读到的数据都是事务启动前的记录。
undo log 两大作用:
- 实现事务回滚,保障事务的原子性。事务处理过程中,如果出现了错误或者用户执 行了 ROLLBACK 语句,MySQL 可以利用 undo log 中的历史数据将数据恢复到事务开始之前的状态。
- 实现 MVCC(多版本并发控制)关键因素之一 。MVCC 是通过 ReadView + undo log 实现的。undo log 为每条记录保存多份历史数据,MySQL 在执行快照读(普通 select 语句)的时候,会根据事务的 Read View 里的信息(trx_id 和 roll_pointer),顺着 undo log 的版本链找到满足其可见性的记录,从而控制并发事务访问同一个记录时的行为。
undo log 是如何刷盘(持久化到磁盘)的?
undo log 和数据页的刷盘策略是一样的,都需要通过 redo log 保证持久化。
buffer pool 中有 undo 页,对 undo 页的修改也都会记录到 redo log。redo log 会每秒刷盘,提交事务时也会刷盘,数据页和 undo 页都是靠这个机制保证持久化的。
Buffer Pool
MySQL 的数据都是存在磁盘中的,要更新一条记录的时候,得先要从磁盘读取该记录,然后在内存中修改这条记录。将修改完的记录缓存起来,下次查询语句命中这条记录时,直接读取缓存中的记录,不需要从磁盘获取数据了。Innodb 存储引擎设计了一个缓冲池(Buffer Pool),来提高数据库的读写性能。
InnoDB 会把存储的数据划分为若干个「页」,以页作为磁盘和内存交互的基本单位,一个页的默认大小为 16KB。因此,Buffer Pool 同样需要按「页」来划分。
在 MySQL 启动的时候,InnoDB 会为 Buffer Pool 申请一片连续的内存空间,然后按照默认的16KB
的大小划分出一个个的页, Buffer Pool 中的页就叫做缓存页。此时这些缓存页都是空闲的,之后随着程序的运行,才会有磁盘上的页被缓存到 Buffer Pool 中。
Buffer Pool 除了缓存「索引页」和「数据页」,还包括了 Undo 页,插入缓存、自适应哈希索引、锁信息等等。
InnoDB 引擎会在适当的时候,由后台线程将缓存在 Buffer Pool 的脏页刷新到磁盘里,这就是 WAL (Write-Ahead Logging)技术 。WAL 技术指的是, MySQL 的写操作并不是立刻写到磁盘上,而是先写日志,然后在合适的时间再写到磁盘上。
二、重做日志redo log
redo log 保证了事务四大特性中的持久性。redo log 是物理日志,记录了某个数据页做了什么修改,例如对 XXX 表空间中的 YYY 数据页 ZZZ 偏移量处做了AAA 更新,每当执行⼀个事务就会产生⼀条或多条物理日志。在事务提交时,只要先将 redo log 持久化到磁盘即可。
redo log和undo log的区别是什么?
undo log 和 redo log 这两个日志都是 Innodb 存储引擎生成的。
- redo log 记录了此次事务「完成后」的数据状态,记录的是更新之后的值;
- undo log 记录了此次事务「开始前」的数据状态,记录的是更新之前的值;
事务提交之前发生崩溃,重启后会通过 undo log 回滚事务,事务提交之后发生崩溃,重启后会通过 redo log 恢复事务。
redo log 作用:
- 实现事务的持久性,让 MySQL 有 crash-safe 的能力,能够保证 MySQL 在任何时间段突然崩溃,重启后之前已提交的记录都不会丢失;
- 将写操作从「随机写」变成了「顺序写」,提升 MySQL 写入磁盘的性能。
三、归档日志 binlog
binlog 文件是记录了所有数据库表结构变更和表数据修改的日志,不会记录查询类的操作。
MySQL 在完成一条更新操作后,Server 层还会生成一条 binlog,等之后事务提交的时候,会将该事物执行过程中产生的所有 binlog 统一写 入 binlog 文件。
redo log和bin log有什么区别?
1. 适用对象不同:
binlog 是 MySQL 的 Server 层实现的,所有存储引擎都可以使用;
redo log 是 Innodb 存储 引擎实现的日志。
2. 文件格式不同:
redo log 是物理日志,记录的是在某个数据页做了什么修改;
binlog 主要包括三种格式: Statement 、 Row 和 Mixed 。
3. 写入方式不同:
binlog 是追加写,写满⼀个⽂件,就创建⼀个新的文件继续写,不会覆盖以前的⽇志,保存 的是全量的日志。
redo log是循环写,日志空间大小是固定,全部写满就从头开始,保存未被刷⼊磁盘的脏页日志。
4. 用途不同:
binlog 用于备份恢复、主从复制;
redo log 用于掉电等故障恢复。
binlog 什么时候刷盘?
事务执行过程中,先把日志写到 binlog cache(Server 层的 cache),事务提交的时候,再把 binlog cache 写到 binlog 文件中。
一个事务的 binlog 是不能被拆开的,因此无论这个事务有多大也要保证一次性写入。这是因为有一个线程只能同时有一个事务在执行的设定,所以每当执行一个 begin/start transaction 的时候,就会默认提交上一个事务,这样如果一个事务的 binlog 被拆开的时候,在备库执行就会被当做多个事务分段执行,这样破坏了原子性,是有问题的。
MySQL 给每个线程分配了一片内存用于缓冲 binlog ,该内存叫 binlog cache,参数 binlog_cache_size 用于控制单个线程内 binlog cache 所占内存的大小。如果超过了这个参数规定的大小,就要暂存到磁盘。
四、两阶段提交
事务提交后,redo log 和 binlog 都要持久化到磁盘,但是这两个是独立的逻辑,可能出现半成功的状态,这样就造成两份日志之间的逻辑不一致。
- 如果在将 redo log 刷入到磁盘之后, MySQL 突然宕机了,而 binlog 还没有来得及写入。MySQL 重启后,通过 redo log 能将 Buffer Pool 恢复到新值,但是 binlog 里面没有记录这条更新语句,在主从架构中,binlog 会被复制到从库,由于 binlog 丢失了这条更新语句,从库的这一行 name 字段是旧值,与主库的值不一致性;
- 如果在将 binlog 刷入到磁盘之后, MySQL 突然宕机了,而 redo log 还没有来得及写入。由于 redo log 还没写,崩溃恢复以后这个事务无效,所以数据字段还是旧值,而 binlog 里面记录了这条更新语句,在主从架构中,binlog 会被复制到从库,从库执行了这条更新语句,那么这一行新值,与主库的值不一致性;
redo log 影响主库的数据,binlog 影响从库的数据,所以 redo log 和 binlog 必须保持一致才能保证主从数据一致。
两阶段提交把单个事务的提交拆分成了 2 个阶段,分别是「准备(Prepare)阶段」和「提交(Commit)阶段」,每个阶段都由协调者(Coordinator)和参与者(Participant)共同完成。
两阶段提交过程
MySQL 会同时维护 binlog 日志与 InnoDB 的 redo log,为了保证这两个日志的一致性,MySQL 使用了内部 XA 事务,内部 XA 事务由 binlog 作为协调者,存储引擎是参与者。
事务的提交过程有两个阶段,将 redo log 的写入拆成了两个步骤:prepare 和 commit,中间再穿插写入binlog,具体如下:
-
prepare 阶段:将 XID(内部 XA 事务的 ID) 写入到 redo log,同时将 redo log 对应的事务状态设置为 prepare,然后将 redo log 持久化到磁盘(innodb_flush_log_at_trx_commit = 1 的作用);
-
commit 阶段:把 XID 写入到 binlog,然后将 binlog 持久化到磁盘(sync_binlog = 1 的作用),接着调用引擎的提交事务接口,将 redo log 状态设置为 commit,此时该状态并不需要持久化到磁盘,只需要 write 到文件系统的 page cache 中就够了,因为只要 binlog 写磁盘成功,就算 redo log 的状态还是 prepare 也没有关系,一样会被认为事务已经执行成功。