MySQL

MySQL redo与undo日志解析

2020-08-28  本文已影响0人  K_un

前言:

前面文章讲述了 MySQL 系统中常见的几种日志,其实还有事务相关日志 redo log 和 undo log 没有介绍。相对于其他几种日志而言, redo log 和 undo log 是更加神秘,难以观测的。本篇文章将主要介绍这两类事务日志的作用及运维方法。

1.重做日志(redo log)

我们都知道,事务的四大特性里面有一个是 持久性 ,具体来说就是只要事务提交成功,那么对数据库做的修改就被永久保存下来了,不可能因为任何原因再回到原来的状态。那么 MySQL 是如何保证一致性的呢?最简单的做法是在每次事务提交的时候,将该事务涉及修改的数据页全部刷新到磁盘中。但是这么做会有严重的性能问题,主要体现在两个方面:

因此 MySQL 设计了 redo log ,具体来说就是只记录事务对数据页做了哪些修改,这样就能完美地解决性能问题了(相对而言文件更小并且是顺序IO)。

redo log 包括两部分:一个是内存中的日志缓冲(redo log buffer),另一个是磁盘上的日志文件(redo log file)。MySQL 每执行一条 DML 语句,先将记录写入 redo log buffer ,后续某个时间点再一次性将多个操作记录写到 redo log file 。

默认情况下,redo log 在磁盘上由名为 ib_logfile0ib_logfile1 的两个物理文件展示。redo log 相关参数简单介绍如下:

更改 redo log 及其 buffer 大小是需要重启数据库实例的,建议初始化时做好评估。可以适当加大 redo log 组数和大小,特别是你的数据库实例更新比较频繁的情况下。但也不推荐 redo log 设置过大。

2.回滚日志(undo log)

undo log 主要用于保证数据的原子性,保存了事务发生之前的数据的一个版本,可以用于回滚。比如一条 INSERT 语句,对应一条 DELETE 的 undo log ,对于每个 UPDATE 语句,对应一条相反的 UPDATE 的 undo log ,这样在发生错误时,就能回滚到事务之前的数据状态。同时,undo log 也是 MVCC (多版本并发控制) 实现的关键。

MySQL 5.7 版本中,undo log 默认存放在共享表空间 ibdata 中。也可以在初始化时通过配置参数改成独立的文件,简单介绍几个 undo log 相关参数:

undo log 相关参数一般很少改动。MySQL 8.0 默认启用了独立表空间,可能 undo log 表空间的大小设置更灵活些。

总结:

本篇文章主要介绍了 redo log 及 undo log 的作用和相关参数设置,文章写的比较匆忙,如有错误,可以留言指出。关于这两类日志更深层次的内容,可能笔者功力还不到,未能写到更加透彻。好了,MySQL 相关日志的两篇文章已经写完了,希望各位能学到一点知识。

参考:

上一篇下一篇

猜你喜欢

热点阅读