【面试八股总结】MySQL日志:undo log、redo log、binlog

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 也没有关系,一样会被认为事务已经执行成功。

相关推荐
i道i18 分钟前
MySQL win安装 和 pymysql使用示例
数据库·mysql
小怪兽ysl18 分钟前
【PostgreSQL使用pg_filedump工具解析数据文件以恢复数据】
数据库·postgresql
wqq_9922502771 小时前
springboot基于微信小程序的食堂预约点餐系统
数据库·微信小程序·小程序
爱上口袋的天空1 小时前
09 - Clickhouse的SQL操作
数据库·sql·clickhouse
Oak Zhang2 小时前
sharding-jdbc自定义分片算法,表对应关系存储在mysql中,缓存到redis或者本地
redis·mysql·缓存
聂 可 以2 小时前
Windows环境安装MongoDB
数据库·mongodb
web前端神器2 小时前
mongodb多表查询,五个表查询
数据库·mongodb
门牙咬脆骨2 小时前
【Redis】redis缓存击穿,缓存雪崩,缓存穿透
数据库·redis·缓存
门牙咬脆骨2 小时前
【Redis】GEO数据结构
数据库·redis·缓存
wusong9993 小时前
mongoDB回顾笔记(一)
数据库·笔记·mongodb