MySQL日志

最新推荐文章于 2024-09-09 10:43:28 发布

请勿打扰、、、！

最新推荐文章于 2024-09-09 10:43:28 发布

阅读量709

点赞数 19

分类专栏： MySQL 文章标签： mysql 数据库

本文链接：https://blog.csdn.net/qq_62612520/article/details/139905612

版权

MySQL 专栏收录该内容

6 篇文章 0 订阅

订阅专栏

MySQL的日志主要有三种类型，undo log(回滚日志)，redo log(重做日志)，binlog(归档日志)。

undo log：是Innodb存储引擎层生成的日志，实现了事务中的原子性，主要用于事务回滚和mvcc。
redo log：是Innodb存储引擎层生成的日志，实现了事务中的持久性，主要用于掉电等故障恢复。
binlog：是Server层生成的日志，主要用于数据备份和主从复制。

undo log

我们平常执行一条“增删改”语句的时候，虽然没有输入 begin 开启事务和 commit 提交事务，但是 MySQL 会隐式开启事务来执行“增删改”语句的，执行完就自动提交事务的。

那么我们考虑一下，一个事务还没有提交但是发生错误了怎么回滚到之前的数据？ undo log就是用来解决这一问题的，它是实现事务ACID中原子性的大功臣。

在一个事务中执行增删改语句时，MySQL会先记录原先的数据到undo log中，然后进行操作，不同的操作需要记录的内容也是不同的，所以产生的undo log也分为不同的类型。

每条增删改操作所产生日志记录格式都包含 roll_pointer指针和一个 trx_id 事务id：

通过 trx_id 可以知道该记录是被哪个事务修改的；
通过 roll_pointer 指针可以将这些 undo log 串成一个链表，这个链表就被称为版本链；

另外，通过undo log + ReadView可以实现MVCC(多版本并发控制)。

对于读已提交和可重复读这两隔离级别来说，快照读(普通的select语句) 是通过 undo log + ReadView 实现的，它们的区别再去ReadView的生成时机不同：

读已提交：每个 select 都会生成一个新的 Read View，意味着，事务期间的多次读取同一条数据，前后两次读的数据可能会出现不一致，因为可能这期间另外一个事务修改了该记录，并提交了事务。
可重复读：启动事务时生成一个 Read View，然后整个事务期间都在用这个 Read View，这样就保证了在事务期间读到的数据都是事务启动前的记录。

这两个隔离级别实现是通过「事务的 Read View 里的字段」和「记录中的两个隐藏列（trx_id 和 roll_pointer）」的比对，如果不满足可见行，就会顺着 undo log 版本链里找到满足其可见性的记录，从而控制并发事务访问同一个记录时的行为，这就叫 MVCC（多版本并发控制）。

因此，undo log的两大作用：

实现事务回滚：事务处理过程中，如果出现了错误或者用户执行了 ROLLBACK 语句，MySQL 可以利用 undo log 中的历史数据将数据恢复到事务开始之前的状态。
实现MVCC的元素之一：undo log 为每条记录保存多份历史数据，MySQL 在执行快照读（普通 select 语句）的时候，会根据事务的 Read View 里的信息，顺着 undo log 的版本链找到满足其可见性的记录。

redo log

redo log 是物理日志，记录了某个数据页做了什么修改，比如对 XXX 表空间中的 YYY 数据页 ZZZ 偏移量的地方做了AAA 更新，每当执行一个事务就会产生这样的一条或者多条物理日志。

在事务提交时，只要先将 redo log 持久化到磁盘即可(日志的持久化比较快，是顺序写，而数据是随机写)，可以不需要等到将缓存在 Buffer Pool 里的脏页数据持久化到磁盘。

当系统崩溃时，虽然脏页数据没有持久化，但是 redo log 已经持久化，接着 MySQL 重启后，可以根据 redo log 的内容，将所有数据恢复到最新的状态。

redo log 和 undo log 区别：

redo log 记录了此次事务「完成后」的数据状态，记录的是更新之后的值；
undo log 记录了此次事务「开始前」的数据状态，记录的是更新之前的值；

事务提交之前发生了崩溃，重启后会通过 undo log 回滚事务，事务提交之后发生了崩溃，重启后会通过 redo log 恢复事务。

至此，针对为什么需要 redo log 这个问题我们有两个答案：

实现事务的持久性，让 MySQL 有 crash-safe 的能力，能够保证 MySQL 在任何时间段突然崩溃，重启后之前已提交的记录都不会丢失；
将写操作从「随机写」变成了「顺序写」，提升 MySQL 写入磁盘的性能。

其实产生的 redo log 不是直接写入磁盘的，因为这样会产生大量的 I/O 操作，而且磁盘的运行速度远慢于内存。所以，redo log 也有自己的缓存—— redo log buffer，每当产生一条 redo log 时，会先写入到 redo log buffer，后续在持久化。

redo log的刷盘时机：

MySQL 正常关闭时；
当 redo log buffer 中记录的写入量大于 redo log buffer 内存空间的一半时，会触发落盘；
InnoDB 的后台线程每隔 1 秒进行刷盘；
每次事务提交时都将缓存在 redo log buffer 里的 redo log 直接持久化到磁盘（这个策略可由 innodb_flush_log_at_trx_commit 参数控制）

redo log 文件写满了怎么办？

默认情况下，Innodb有一个重做日志组，「重做日志文件组」由有 2 个 redo log 文件组成，这两个 redo 日志的文件名叫：ib_logfile0 和 ib_logfile1 。

每个 redo log File 的大小是固定且一致的，假设每个 redo log File 设置的上限是 1 GB，那么总共就可以记录 2GB 的操作。

重做日志文件组是以循环写的方式工作的，从头开始写，写到末尾就又回到开头，相当于一个环形。

所以 InnoDB 存储引擎会先写 ib_logfile0 文件，当 ib_logfile0 文件被写满的时候，会切换至 ib_logfile1 文件，当 ib_logfile1 文件也被写满时，会切换回 ib_logfile0 文件。

上面我们知道redo log是为了防止 Buffer Pool 中的脏页丢失而设计的，那么如果随着系统运行，Buffer Pool 的脏页刷新到了磁盘中，那么 redo log 对应的记录也就没用了，这时候我们擦除这些旧记录，以腾出空间记录新的更新操作。

redo log 是循环写的方式，相当于一个环形，InnoDB 用 write pos 表示 redo log 当前记录写到的位置，用 checkpoint 表示当前要擦除的位置，如下图：

其中：

write pos 和 checkpoint 的移动都是顺时针方向；
write pos ～ checkpoint 之间的部分（图中的红色部分），用来记录新的更新操作；
check point ～ write pos 之间的部分（图中蓝色部分）：待落盘的脏数据页记录；

如果 write pos 追上了 checkpoint 就代表redo log满了，这时候MySQL会停止更新操作，将BufferPool中的脏页刷盘，然后标记 redo log 中哪些可以被清理，清理完后checkpoint会顺时间移动。

binlog

MySQL 在完成一条更新操作后，Server 层还会生成一条 binlog，等之后事务提交的时候，会将该事物执行过程中产生的所有 binlog 统一写入 binlog 文件。

binlog 文件是记录了所有数据库表结构变更和表数据修改的日志，不会记录查询类的操作，比如 SELECT 和 SHOW 操作。

为什么有了redo log还需要binlog？

主要是产生时间的顺序，最开始 MySQL 里并没有 InnoDB 引擎，MySQL 自带的引擎是 MyISAM，但是 MyISAM 没有 crash-safe 的能力，binlog 日志只能用于归档。

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

redo log 和 binlog 有什么区别？

使用对象不同：
1. binlog 是 MySQL 的 Server 层实现的日志，所有存储引擎都可以使用；
2. redo log 是 Innodb 存储引擎实现的日志;
文件格式不同:
1. binlog 有 3 种格式类型，分别是 STATEMENT（默认格式）、ROW、 MIXED,这里就不分别介绍了；
2. redo log 是物理日志，记录的是在某个数据页做了什么修改，比如对 XXX 表空间中的 YYY 数据页 ZZZ 偏移量的地方做了AAA 更新；
使用方式不同：
1. binlog是追加写，写满一个文件会创建一个新文件继续写，保存全量日志。
2. redo log是循环写，日志空间大小是固定，全部写满就从头开始，保存未被刷入磁盘的脏页日志。
用途不同：
1. binlog用于数据备份，主从同步
2. redo log用于数据恢复

从上面的区别也可以知道，如果整个数据库数据都被删除了，使用redo log是恢复不了的，因为redo log 记录的是BufferPool中的脏页数据，并没有以前在就持久化的数据，所以只能使用binlog来进行恢复。

binlog什么时候刷盘？

事务执行过程中，先把日志写到 binlog cache（Server 层的 cache），事务提交的时候，再把 binlog cache 写到 binlog 文件中。

一个事务的 binlog 是不能被拆开的，因此无论这个事务有多大（比如有很多条语句），也要保证一次性写入。因为如果拆开多事务执行的话就破坏了原子性。

虽然每个线程有自己 binlog cache，但是最终都写到同一个 binlog 文件：

图中的 write，指的就是指把日志写入到 binlog 文件，但是并没有把数据持久化到磁盘，因为数据还缓存在文件系统的 page cache 里，write 的写入速度还是比较快的，因为不涉及磁盘 I/O。
图中的 fsync，才是将数据持久化到磁盘的操作，这里就会涉及磁盘 I/O，所以频繁的 fsync 会导致磁盘的 I/O 升高。

MySQL提供一个 sync_binlog 参数来控制数据库的 binlog 刷到磁盘上的频率：

sync_binlog = 0 的时候，表示每次提交事务都只 write，不 fsync，后续交由操作系统决定何时将数据持久化到磁盘；
sync_binlog = 1 的时候，表示每次提交事务都会 write，然后马上执行 fsync；
sync_binlog =N(N>1) 的时候，表示每次提交事务都 write，但累积 N 个事务后才 fsync。

两阶段提交

redo log 和 binlog都需要持久化到磁盘，可能出现半成功的状态，这样就造成两份日志之间的逻辑不一致。

所以可能会出现两种情况：

redo log刷盘成功，MySQL宕机，binlog刷盘失败，MySQL重启后，通过redo log可以恢复数据，但是主从架构中，从数据库通过binlog复制数据，因为binlog中没有新数据记录，所以从数据库的数据与主数据库会出现不一致。
binlog刷盘成功，MySQL宕机，redo log刷盘失败，MySQL重启后，因为redo log中没有新数据记录，通过redo log不可以恢复数据，但是主从架构中，从数据库通过binlog复制数据，因为binlog中有新数据记录，所以从数据库的数据与主数据库会出现不一致。

以上两种情况都会出现主从不一致情况。

那么怎么解决上述问题，MySQL使用了两阶段提交来解决，阶段提交其实是分布式事务一致性协议，它可以保证多个逻辑操作要不全部成功，要不全部失败，不会出现半成功的状态。

两阶段提交把单个事务的提交拆分成了 2 个阶段，分别是「准备（Prepare）阶段」和「提交（Commit）阶段」

准备阶段：将 XID（内部 XA 事务的 ID）写入到 redo log，同时将 redo log 对应的事务状态设置为 prepare，然后将 redo log 持久化到磁盘（innodb_flush_log_at_trx_commit = 1 的作用）；
提交阶段：把 XID 写入到 binlog，然后将 binlog 持久化到磁盘（sync_binlog = 1 的作用），接着调用引擎的提交事务接口，将 redo log 状态设置为 commit，此时该状态并不需要持久化到磁盘，只需要 write 到文件系统的 page cache 中就够了，因为只要 binlog 写磁盘成功，就算 redo log 的状态还是 prepare 也没有关系，一样会被认为事务已经执行成功；

异常重启

不管是时刻 A（redo log 已经写入磁盘， binlog 还没写入磁盘），还是时刻 B （redo log 和 binlog 都已经写入磁盘，还没写入 commit 标识）崩溃，此时的 redo log 都处于 prepare 状态。

MySQL重启后，会扫描redo log中是否有prepare状态的记录，有则会拿着该记录的XID去binlog中查找是否存在相同的记录：

如果 binlog 中没有当前内部 XA 事务的 XID，说明 redolog 完成刷盘，但是 binlog 还没有刷盘，则回滚事务。对应时刻 A 崩溃恢复的情况。
如果 binlog 中有当前内部 XA 事务的 XID，说明 redolog 和 binlog 都已经完成了刷盘，则提交事务。对应时刻 B 崩溃恢复的情况。

所以，两阶段提交是以binlog是否写入成功为标志的。redo log为prepare，重启后可能回滚也可能提交是看能不能在binlog中查找到相同的XID记录。