innodb 01 redo 日志详解

ゝ一世哀愁。 2023-01-04 14:44 224阅读 0赞

### redo 和binlog的区别。 ###

1、二进制日志server层产生，redo是innodb层产生。并且binlog先于redolog被记录  
2、binlog记录操作的方法是逻辑性的语句，基于行格式。redolog是innodb层产生的日志，记录数据库每个页的修改。  
3、binlog是事务提交的时候，一次性写入，redolog是数据准备修改的时候写入redobuffer,然后才对缓存中数据操作。并且保证，事务提交时：redobuffer冲刷到磁盘  
4、binlog是一次性写入，所以有顺序。redolog是物理页的修改，所以可能同一个事务多次记录，并且redolog是并发写入的，不同事务之间的不同版本会穿插到redolog中。  
5、事务日志记录的是物理页的情况，它具有幂等性，因此记录日志的方式极其简练。而二进制日志记录的是所有影响数据的操作，记录的内容较多。

### redo基本概念： ###

redo包含两个部分：内存中的日志缓冲redobuffer + 磁盘上的日志文件redolog.事务提交的时候，必须把该事务的所有日志都写入到磁盘的redolog中。  
redobuffer 在用户区，先复制到内核取，然后fsync刷盘。  
关于为何要经过内核缓冲区的理解：使用O\_DIRECT表示写磁盘绕过OS Buffer，但是这样会降低顺序写的效率(写abcde，将发起五次fsync)。

### redolog：double write写入，保证写入一定是成功的。redolog是循环写的。 ###

Double Write的思路很简单:  
A. 在覆盖磁盘上的数据前，先将Page的内容写入到磁盘上的其他地方(InnoDB存储引擎中的doublewrite buffer，这里的buffer不是内存空间，是持久存储上的空间).  
B. 然后再将Page的内容覆盖到磁盘上原来的数据。  
如果在A步骤时系统故障，原来的数据没有被覆盖，还是完整的。  
如果在B步骤时系统故障，原来的数据不完整了，但是新数据已经被完整的写入了doublewrite buffer. 因此系统恢复时就可以用doublewrite buffer中的新Page来覆盖这个不完整的page。

doublewrite由两部分组成,一部分是内存中的 doublewrite buffer,大小为2MB,另部分是物理磁盘上共享表空间中连续的128个页,  
即2个区( extent),大小同样为2MB。在对缓冲池的脏页进行刷新时,并不直接写磁盘,而是会通过 memcpy函数将脏页先复制到内存中的  
doublewrite buffer,之后通过 doublewrite buffer再分两次,每次1MB顺序地写入共享表空间的物理磁盘上,然后马上调用 fsync函数,  
同步磁盘,避免缓冲写带来的问题。在这个过程中,因为 doublewrite页是连续的,因此这个过程是顺序写的,开销并不是很大。  
在完成 doublewrite页的写入后,再将 doublewrite buffer中的页写入各个表空间文件中,此时的写入则是离散的。

### redolog commit 后，有三种写入模式： ###

innodb\_flush\_log\_at\_trx\_commit参数决定：  
0：提交事务的时候，并不把redolog刷新到磁盘上去。而是等待主线程每秒的刷新  
1：提交事务的时候，同时刷盘redolog。  
2：表示将事务异步写到磁盘，即写到文件系统的缓存中去。

### 日志块512字节： ###

redo buffer 或者redo file 由很多日志块组成。  
block = 块头(12字节) + 块(492) + 块尾(8字节)  
块头 = 日志块在buffer中的ID + 日志块已写日志的大小 + 日志块中第一个日志的位置 +写入检查点信息的位置、  
块尾 = 日志块在buffer中的ID

### log group 和 redo log file ###

一个log group由多个完全相同的redolog file 组成。log group是逻辑的。redo log file是物理的。  
innodb\_log\_files\_group 参数决定 redo log file 的数量  
innodb\_log\_group\_home\_dir 参数决定 redo log file的位置  
每个redo log file前2KB都是预留空间。第一个redo log file记录了group的信息。其他redo log file的这2KB为空。

### redo\_log 的格式。 ###

在redo block 中，中间的块部分是log body（492字节）  
log body = 日志类型（1字节）+ 表空间ID(4字节) + 页的偏移量 + 数据  
其中数据部分，插入和删除格式是不一样的。

### redo日志刷盘时机： ###

1.发出commit动作时。已经说明过，commit发出后是否刷日志由变量 innodb\_flush\_log\_at\_trx\_commit 控制。  
2.每秒刷一次。这个刷日志的频率由变量 innodb\_flush\_log\_at\_timeout 值决定，默认是1秒。要注意，这个刷日志频率和commit动作无关。  
3.当log buffer中已经使用的内存超过一半时。  
4.当有checkpoint时，checkpoint在一定程度上代表了刷到磁盘时日志所处的LSN位置。

### innodb数据刷盘（checkpoint机制）： ###

在innodb中，数据刷盘的规则只有一个：checkpoint。但是触发checkpoint的情况却有几种。  
两种触发：  
sharp(锐利的; 急剧的) checkpoint：在数据库关闭的时候，将所有脏页刷盘  
fuzzy(毛茸茸的) checkpoint：  
master ：线程每秒或者每10秒，进行刷新。  
flush\_lRU\_list :保证LRU中有100个空闲(数量可调整)。page clearner thread 刷新  
Async/Sync Flush：重做日志文件不可用的时候进行的刷新(75%—>异步、90%—>同步)。（redo log是循环使用的，避免覆盖，见上文）  
Dirty Page too much：脏页太多了，导致缓冲区没有足够可用的页。MySQL 5.6默认的值为75，即当脏页占缓冲池的百分之75后，就强制刷一部分脏页到磁盘。

### MySQL停止时是否将脏数据和脏日志刷入磁盘： ###

由变量innodb\_fast\_shutdown=\{ 0|1|2 \}控制，默认值为1，即停止时只做一部分purge，忽略大多数flush操作(但至少会刷日志)，在下次启动的时候再flush剩余的内容，实现fast shutdown。

### LSN ###

log sequence number就是当前的redo log(in buffer)中的lsn；  
log flushed up to是刷到redo log file on disk中的lsn；  
pages flushed up to是已经刷到磁盘数据页上的LSN；  
last checkpoint at是上一次检查点所在位置的LSN。  
但是其实：内存数据页也有LSN。所以  
内存数据页的LSN >= redo log(buffer)的LSN >= redo log(disk)的LSN >= 已经刷到磁盘数据页上的LS >= 上一次检查点所在位置的LSN(上一次checkpoint)

### 宕机恢复： ###

1、重启innodb时，checkpoint表示已经完整刷到磁盘上data page上的LSN，因此恢复时仅需要恢复从checkpoint开始的日志部分  
2、还有一种情况，在宕机前正处于checkpoint的刷盘过程，且数据页的刷盘进度超过了日志页的刷盘进度。这时候一宕机，数据页中记录的LSN就会大于日志页中的LSN，在重启的恢复过程中会检查到这一情况，这时超出日志进度的部分将不会重做，因为这本身就表示已经做过的事情，无需再重做。  
3、另外，事务日志具有幂等性，所以多次操作得到同一结果的行为在日志中只记录一次。而二进制日志不具有幂等性，多次操作会全部记录下来，在恢复的时候会多次执行二进制日志中的记录，速度就慢得多。

### 大佬博客 https://www.cnblogs.com/f-ck-need-u/p/9001061.html\#blog5 ###