MySQL日志模块简介

目录

1。简介

2.重做日志

三.binlog

4.内部工作流程

MySql学习专栏

1. MySQL基础架构详解

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

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

4. MySQL日志模块

1.简介

MySQL有两个重要的日志模块：重做日志(redo log)和binlog(归档日志)。

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

2. redo log

重做日志：也称为（重做日志）文件，用于记录事务操作的变化，记录是数据修改后的值，无论什么情况都会记录下来事务是否已提交。

如果发生介质故障，重做日志文件可以派上用场。如果数据库断电，InnoDB存储引擎会使用重做日志恢复到断电前的时间，以保证数据的完整性。

当一条记录需要更新时，InnoDB引擎会首先将该记录写入重做日志并更新内存。此时更新就完成了..

InnoDB引擎会在适当的时候将这条操作记录更新到磁盘上，而这次更新就是通常在系统比较空闲时完成，以提高更新效率。

这涉及到WAL或预写日志记录技术。关键点就是先写日志，再写磁盘>。

InnoDB的重做日志有固定的大小。例如，可以配置为4个文件为一组，每个文件大小为1GB，总共可以记录4GB的操作。

重做日志会从头开始写入，到达末尾时又回到开头，循环写入，如下图所示。

write pos是当前记录的位置。书写时它会向后移动。写入到 3 号文件的末尾后，返回到 0 号文件的开头。

检查点就是当前要擦除的位置，同样向后移动，循环。在删除记录之前，必须将记录更新到数据文件中。

Write pos和check point是未使用的部分，可用于记录新操作。

如果write pos赶上检查点，则说明重做日志记录已满。此时无法进行新的更新，必须先停止并擦除。删除一些记录并前进检查点。

有了重做日志，InnoDB可以保证即使数据库异常重启，之前提交的记录也不会丢失。此功能称为崩溃安全。

为什么要使用重做日志？

如果我们对数据库进行DML操作，直接将执行的SQL写入磁盘，当写入并发量较大时，数据写入磁盘的压力会受到一定的影响

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

当我使用redo log日志时，首先把我们的 DML 操作写入到日志中，经过一个“中转站”，空闲时重新连接。通过写入磁盘检查点效率会高很多；

MySQL设置Redo Log

的大小写入日的innodb_log_buffer_size：（默认8M）

innodb_log_file_size 重做日志文件的大小。

innodb_log_files_in_group指定重做日志文件组的文件数量，默认为2

innodb_mirrored_log_groups指定日志镜像文件组的数量，默认为1

innodb_flush_log_at_trx_commit 如何flush设置commit时将日志缓冲区中的日志写入日志文件（值0,1,2）默认1

3。 binlog

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

为什么有两条日志？

因为MySQL一开始并没有InnoDB引擎。 MySQL自己的引擎是MyISAM，但是MyISAM不具备崩溃安全能力，binlog日志只能用于归档。

InnoDB是另一家以插件形式引入MySQL的公司。由于仅仅依赖binlog不具备crash-safe的能力，因此InnoDB使用了另一种日志系统——即redo log来实现crash-safe的能力。

这两个日志有以下三个区别。

重做日志是InnoDB引擎特有的； binlog由MySQL的Server层实现，可供所有引擎使用。

重做日志是物理日志，记录“对某个数据页进行了哪些修改”； binlog是逻辑日志，which记录了这条语句的原始内容。初始逻辑，如“ID=2的行的c字段加1”。

重做日志是循环写入的，空间总会被用完； binlog可以另外写入。 “追加写入”是指binlog文件达到一定大小后，会切换到下一个，不会覆盖之前的日志。

4.内部工作流程

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

mysql> update T set c=c+1 where ID=2;

如下图，灯框表示是在InnoDB内部执行的，暗的框表示是在执行器中执行：

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

执行器拿到引擎给的行数据，把这个值加1，比如以前是N，现在是N+1，拿到新的一行数据，然后调用引擎接口写入这行新数据。数据。

引擎将这行新数据更新到内存中，并将更新操作记录到重做日志中。此时重做日志处于prepare状态。然后通知执行者执行完成，可以随时提交交易。

执行器生成本次操作的binlog，并将binlog写入磁盘。

执行器调用引擎的提交事务接口，引擎将刚刚写入的重做日志更改为提交状态，更新完成。

最后三个步骤看起来有点“循环”。写作重做日志分为两个步骤：准备和提交。事实上，这就是“两阶段提交”。

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

由于redo log和binlog是两个独立的逻辑，如果不需要两阶段提交，要么必须先写redo log，然后再写binlog，要么以相反的顺序。以前面的update语句为例，我们看看这两种方法都存在哪些问题。

假设当前ID=2的行中，字段c的值为0，并且还假设在执行update语句的过程中，在写入第一条日志后，在第二条日志之前发生了crash第二条日志已写入。 ， 会发生什么？

1.先写redo log，再写binlog。 假设MySQL进程在redo log写入时、binlog写入之前异常重启。重做日志写入后，即使系统崩溃，数据还是可以恢复的，所以恢复后这行c的值为1。

但是由于binlog还没写完就crash了，所以此时binlog中并没有记录这条语句。因此，后面备份日志时，保存的binlog中不会包含这条语句。

然后你会发现，如果需要使用这条binlog来恢复临时库，因为这条语句的binlog丢失了，临时库就会丢失这次更新，恢复后的c的值row为0，与原库的值不同。

2.先写binlog，再写redo log。 如果写入binlog后出现crash，由于redo log还没有写入，crash恢复后事务就会失效，所以这一行c的值为0。

但是binlog中已经记录了“Change c from 0 to 1”的日志。因此，后期使用binlog进行恢复时，一分钟重新交易就会出来。恢复后的行中c的值为1，与原始数据库中的值不同。

如您所见，如果不使用“两阶段提交”，那么数据库的状态可能与使用其日志恢复的库的状态不一致。

这篇关于《MySQL日志模块简介》的文章就分享到这里。希望以上内容能够对大家有所帮助，让大家能够学到更多的知识。如果您觉得文章不错，请转发出去，让更多的人看到。