记录MySQL日志模块

免费学习推荐：mysql视频教程 目录 一、简介 二、redo log 三. binlog 四. 内部工作流程 MySql学习专栏 1. MySQL基础架构详解 2. MySQL索引底层数据结构与算法 3. MySQL5.7开启binlog日志，及数据恢复

    <img src="https://img.mryunwei.com/uploads/2023/04/20230419033919639.jpg"><blockquote><p>免费学习推荐：mysql视频教程</p></blockquote>

目录

一、简介

二、redo log

三. binlog

四. 内部工作流程

MySql学习专栏

1. MySQL基础架构详解

2. MySQL索引底层数据结构与算法

3. MySQL5.7开启binlog日志，及数据恢复简单示例

4. MySQL日志模块

一、简介

MySQL 有两大重要的日志模块：redo log（重做日志）和 binlog（归档日志）。

redo log是InnoDB存储引擎层的日志，binlog是MySQL Server层记录的日志， 两者都是记录了某些操作的日志，但两者记录的格式不同。

二、redo log

redo log: 又称（重做日志）文件，用于记录事务操作的变化，记录的是数据修改之后的值，不管事务是否提交都会记录下来。

在media failure时，redo log文件就能派上用场，如数据库掉电，InnoDB存储引擎会使用redo log恢复到掉电前的时刻，以此来保证数据的完整性。

当有一条记录需要更新的时候，InnoDB 引擎就会先把记录写到 redo log 里面，并更新内存，这个时候更新就算完成了。

InnoDB 引擎会在适当的时候，将这个操作记录更新到磁盘里面，而这个更新一般是在系统比较空闲的时候完成的，以此来提升更新效率。

这里涉及到 WAL 即 Write-Ahead Logging 技术，他的关键点就是 先写日志，再写磁盘。

InnoDB 的 redo log 是固定大小的，比如可以配置为一组 4 个文件，每个文件的大小是 1GB，那么总共就可以记录 4GB 的操作。

redo log会从头开始写，写到末尾就又回到开头循环写，如下图所示。

write pos 是当前记录的位置，一边写一边后移，写到第 3 号文件末尾后就回到 0 号文件开头。

check point 是当前要擦除的位置，也是往后推移并且循环的，擦除记录前要把记录更新到数据文件。

write pos 和 check point 之间的是未使用的部分，可以用来记录新的操作。

如果 write pos 追上 check point，表示redo log记录满了，这时候不能再执行新的更新，得停下来先擦掉一些记录，把 check point 推进一下。

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

为什么要使用redo log日志？

假如我们对数据库进行DML操作，直接把执行SQL写入磁盘，当写入并发较大时，对数据写入磁盘的压力会造成一定影响，

当我们插入操作是，发现当前非叶子节点一页数据量不够时，要进行分页算法，效率会比较低；

当我使用redo log日志，先把我们DML操作写入日志，通过一个"中转站",空闲时候再通过check point 写入磁盘，效率会高很多；

MySQL设置Redo Log

三. binlog

redo log 是 InnoDB 引擎特有的日志，而 Server 层也有自己的日志，称为 binlog（归档日志）。

为什么会有两份日志呢？

因为最开始 MySQL 里并没有 InnoDB 引擎。MySQL 自带的引擎是 MyISAM，但是 MyISAM 没有 crash-safe 的能力，binlog 日志只能用于归档。

而 InnoDB 是另一个公司以插件形式引入 MySQL 的，既然只依靠 binlog 是没有 crash-safe 能力的，所以 InnoDB 使用另外一套日志系统——也就是 redo log 来实现 crash-safe 能力。

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

以一个表的更新语句为例，来看一下执行器和 InnoDB 引擎的内部工作流程：

为什么日志需要 "两阶段提交"？这里可以用反证法来进行解释。

由于 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，与原库的值不同。

可以看到，如果不使用“两阶段提交”，那么数据库的状态就有可能和用它的日志恢复出来的库的状态不一致。

推荐：mysql数据库(视频)

以上就是记录MySQL日志模块的详细内容，更多请关注每日运维其它相关文章！