细嗦MySQL三大日志

文章目录

三大日志：binlog（归档日志）、redo log（重做日志）、undo log（回滚日志）
redo log
- 刷盘机制
- 日志文件组
binlog
- 记录格式
- 写入机制
两阶段提交
undo log
- 提供回滚操作
- 提供MVCC（多版本并发控制）

三大日志：binlog（归档日志）、redo log（重做日志）、undo log（回滚日志）

redo log

redo log是一个重做日志，是InnoDB引擎独有的，是用于MySQL在挂了之后或者宕机之后恢复数据使用的，保证了数据的持久性和一致性。
在MySQL中数据都是以页为单位的，默认一页16kb，这个参数在配置MySQL的时候可以设置，加载出来的数据页会放入Buffer Pool中，当查询数据的时候会先去Buffer Pool（缓冲池）中查找数据，如果没有，Buffer Pool会从硬盘中加载进来，之后进行修改数据时也是修改的Buffer Pool中的数据，然后将修改的记录记录在redo log buffer（重做日志缓存）中，定期将redo log buffer中的数据同步到redo log中（刷盘机制）。

刷盘机制

一般在这几种情况下会进行刷盘：通过innodb_flush_log_at_trx_commit参数进行控制

当事务提交的时候的时候会将redo log buffer中的数据刷新到redo.file文件中。
redo log buffer的空间占总容量的一半以上，就需要把这些日志刷新到磁盘中。
InnoDB使用了一个事务日志缓冲区（transaction log buffer）来暂时存储事务重做日志，当这个缓冲区满的时候会触发刷盘机制。
InnoDB会定期执行检查点操作（Chechpoint），进行刷盘操作，同时将相关重做日志一同刷新。
InnoDB 启动了一个后台线程，负责周期性（每隔 1 秒）的刷盘，同时将相关重做日志一同刷新。
正常关闭服务器：MySQL 关闭的时候会进行刷盘。

通过设置参数innodb_flush_log_at_trx_commit 可以有不同的刷盘时机：
设置为0，每次提交事务不进行刷盘操作，这种性能高，但是安全性低，因为这种只能等redo log buffer缓存占一半或InnoDB定期刷盘，如果宕机可能会丢失1S内的事务。
设置为1，每次提交事务都会进行刷盘操作，这种性能低，但是安全性高，因为只要提交事务就会进行刷盘，不会有数据丢失。如果事务执行期间MySQL挂了或宕机，这部分日志丢了，但是事务并没有提交，所以日志丢了也不会有损失。
设置为2，每次提交事务都只会把redo log buffer 中的内容写到page cache(文件系统缓存)，page cache 是专门用来缓存文件的，这里被缓存的文件就是 redo log 文件。这种方式的性能和安全性都介于前两者中间。
刷盘机制innodb_flush_log_at_trx_commit 的默认值为 1，设置为 1 的时候才不会丢失任何数据。为了保证事务的持久性，我们必须将其设置为 1。

日志文件组

硬盘上存储的redo log日志文件不止一个，而是通过一个日志文件组的形式出现的，每一个日志文件的大小相同通过环形拼接而成。
在这里插入图片描述

在日志文件组中还有两个重要属性write pos、checkpoint，相当于头尾指针，write pos 是当前记录的位置，一边写一边后移，checkpoint 是当前要擦除的位置，也是往后推移，每次刷盘记录redo log，write pos位置就会后移，每次MySQL加载日志文件组恢复数据时，会清空加载过得redo log数据，checkpoint就会后移。
如果write pos，后移追上checkpoint，表示日志文件组满了，需要清空一些记录，然后将checkpoint后移。
MySQL 8.0.30 及之后的版本中，文件数固定为了32，可以指定innodb_redo_log_capacity的值来设置每个文件的大小，即innodb_redo_log_capacity/32。
只要每次把修改后的数据页直接刷盘不就好了，还有 redo log 什么事？
数据页刷盘是随机写，因为一个数据页对应的位置可能在硬盘文件的随机位置，所以性能是很差。如果是写 redo log，一行记录可能就占几十 Byte，只包含表空间号、数据页号、磁盘文件偏移量、更新值，再加上是顺序写，所以刷盘速度很快。所以用 redo log 形式记录修改内容，性能会远远超过刷数据页的方式，这也让数据库的并发能力更强。

binlog

redo log是物理日志，记录的是在什么数据上做了什么修改，属于InnoDB引擎。binlog属于逻辑日志，主要记录的是原始的逻辑语句，不管什么存储引擎，只要发生了表数据更新操作，都会产生binlog日志，binlog主要用于数据库的备份，主从数据同步，之类的用来保证数据的一致性。

记录格式

binlog日志有三种格式，可以通过binlog_format参数指定。statement row mixed。

如果指定statement，binlog中记录的就是sql语句原文，在同步数据的时候会执行sql语句。但是当遇到像记录当前时间的sql，如果是直接执行sql语句的话就会和原数据不一致。
指定为row就不仅仅是记录执行的sql语句，在记录的时候还会包括具体的数据，这样就保证了记录数据的一致性，通常情况下都是指定为row，但是这种格式，需要更大的容量来记录，比较占用空间，恢复与同步数据时会更消耗IO资源，影响执行速度。
指定为mixed是前两种的折中方案，当设置为mixed的时候，binlog中的记录是前两种的混合记录，在记录之前MySQL会先判断这条sql语句是否会引起数据不一致，然后根据判断结果记录相应的格式。

写入机制

binlog写入的过程是，在事务执行过程中，先把日志写到binlog cache中，事务提交的时候再将binlog cache写入到binlog文件中。可以通过binlog_cache_size参数配置binlog cache的大小，如果存储的内容超过这个容量就需要将内容暂时存储在磁盘中。在这里插入图片描述

将数据写入到page cache中是比较快的，只有数据从page cache写入到binlog中才是真正的持久化磁盘的操作。至于这两者的时机，由参数sync_binlog控制，默认是1。

当这个参数为0的时候，每次提交事务都只会将binlog cache中的记录写入page cache，具体什么时候从page cache写入binglog由系统自行判断。虽然性能得到提升，但是机器宕机，page cache里面的 binlog 会丢失。
当参数设置为1的时候，每次提交事务都会将binlog cache中的记录写入page cache并且刷盘到磁盘binlog中。
还有一种方式就是可以设置参数为n，表示每提交n个事务之后进行一次刷盘操作。但是如果机器宕机，就会丢失最近n个事务的binlog日志。

两阶段提交

redo log（重做日志）让InnoDB引擎拥有崩溃恢复的能力，binlog（归档日志）保证了MySQL集群架构的数据一致性。虽然都是属于持久化的保证，但是两者的侧重点不同。
在执行更新语句过程中，会记录redo log和binlog两个日志，以基本的事务为单位，redo log在事务执行过程中可以不断写入，而binlog只有在事务提交时候才写入，所以redo log和binlog写入时机不一样。
因为两者的写入时机不一致，所以会出现一些问题。比如当执行某update语句，将一个n从0修改为了1，在事务提交前redo log日志记录了这次操作，而在事务提交后写入binlog时发生了异常。之后恢复数据的时候主库使用redo log恢复数据n=1，而从库使用binlog恢复数据n=0，出现了数据不一致。

为了解决两份日志之间的逻辑一致问题，InnoDB存储引擎使用两阶段提交方案。
原理很简单，将redo log的写入拆成了两个步骤prepare和commit，这就是两阶段提交。

在事务执行过程中redo log写入会先处于prepare状态，当事务提交记录binlog日志时就会将redo log改为commit状态。在宕机恢复数据时会查看redo log日志的状态，如果发现redo log日志处于prepare状态，并且没有对应的binlog日志，就会回滚该事务。
如果redo log在设置commit阶段发生异常，在恢复数据时，虽然redo log是出于prepare状态，但是能通过事务id找到对应的binlog日志，所以就认为事务是完整的，不会发生回滚，直接提交事务恢复数据。

undo log

我们知道如果想要保证事务的原子性，就需要在异常发生时，对已经执行的操作进行回滚，在 MySQL 中，恢复机制是通过回滚日志（undo log）实现的，所有事务进行的修改都会先记录到这个回滚日志中，然后再执行相关的操作。如果执行过程中遇到异常的话，我们直接利用回滚日志中的信息将数据回滚到修改之前的样子即可！并且，回滚日志会先于数据持久化到磁盘上。这样就保证了即使遇到数据库突然宕机等情况，当用户再次启动数据库的时候，数据库还能够通过查询回滚日志来回滚将之前未完成的事务。