关于Mysql中redo log和LSN的理解

LSN全称是Log Sequence Number，看名字可以知道是服务于log的，在mysql中log一般就是指redo log。SLN是一个8字节整形数字，存储在log_sys对象中的全局变量，可以简单理解SLN就是从开始到现在已经产生了多少字节的redo log。SLN会存在于三个地方：数据页、redo log record和redo log file，redo recovery就是依赖存在于这三个地方的SLN进行。

我们知道redo log采用逻辑环形结构来复用空间，这种环形结构一般需要两个指针：

write position：表示当前数据写入的位置；
checkpoint：编号小于checkpoint的空间可以被覆盖（这里编号特指SLN）；

这里两个指针是redo log的逻辑指针，分别对应到上面提到的两个存储位置：write position就是当前log file中最后一条redo log record对应的LSN，也即是当前log file中最大的SLN（redo log record在log file中的位置也是根据SLN计算出来的，SLN大于log file文件大小后则取模计算，也就是覆盖老数据）；checkpoint就是存放于log file头部的SLN，代表该SLN之前的脏页已经全部落盘，自然就不再需要在这之前的redo log record了，新的checkpoint会覆盖老的；

由于log file是环形结构，如果checkpoint原地不动的话，随着redo log record的不断插入，write position总会追上checkpoint，如果追上了那就没办法再写redo log了，因为checkpoint之后的redo log不能保证其对应的脏页已经被刷到磁盘，如果日志被复写了则存在数据丢失的可能。解决办法也很简单，催着checkpoint也往前走，形成一种checkpoint追赶write position的局面，checkpoint与write position之间的间隔越小，证明还未刷入磁盘的脏页越少，服务重启之后recovery所需的时间就越少，反之则越大。那么如何更新checkpoint呢？有Sharp Checkpoint和Fuzzy Checkpoint两大类，Sharp Checkpoint发生在关闭数据库时，将所有脏页刷回磁盘。Sharp Checkpoint会相对比较耗时，不适合在运行时使用，所以运行时依赖Fuzzy Checkpoint进行部分脏页的刷新。部分脏页刷新有以下几种：

Master Thread Checkpoint
FLUSH_LRU_LIST Checkpoint：用于保证buffer pool的可用空间，新版迁移到独立后台线程page cleaner thread；
Async/Sync Flush Checkpoint：用于保证redo log的可用空间，触发low water时采用async模式，触发high water采用sync模式，新版迁移到独立后台线程page cleaner thread；
Dirty Page too much Checkpoint

使用show engine innodb status \G可以查看当前数据库各部分维护的SLN值，以下是DB示例值：

---
LOG
---
Log sequence number 10438038988312
Log flushed up to   10438038988305
Pages flushed up to 10437891341412
Last checkpoint at  10437891341412
0 pending log flushes, 0 pending chkp writes
756880106 log i/o's done, 280.00 log i/o's/second

Log sequence number（LSN1）：表示在log_sys中sln字段的最新值，也就是下一个redo log record的sln值；
Log flushed up to （LSN2）：表示最新刷到磁盘的redo log record对应的sln，也即是上述的write position；
Pages flushed up to （LSN3）：表示小于此sln的脏页已经刷到磁盘，此值一般对应Flush List中最老（sln值最小）的脏页的sln；
Last checkpoint at （LSN4）：表示记录在log file中的checkpoint，recovery的时候以这个值为准，sln小于这个值的可以认为已经安全刷到磁盘不需要修复；

上述四个SLN满足如下关系：LSN1 >= LSN2 >= LSN3 >= LSN4

我在本地测试过几次，每次LSN3都等于LSN4，说明我测试的DB脏页刷盘和更新checkpoint是同步的。但是在网上存在很多示例显示LSN3 > LSN4，而且既然Mysql弄两个值出来肯定不是为了记录同一个值，那么就说明存在部分情况刷完脏页是没有更新checkpoint的，那么是否会存在由于这些情况导致checkpoint一直得不到更新，进而引发redo log可用空间耗尽的情况？答案是不会的，log buffer可用空间可以通过Async/Sync Flush Checkpoint来保证，他会针对LSN1 - LSN4 和 LSN1 - LSN3两个值分别设置高低水位，触达水位后会执行对应的操作（低水位触发异步操作，高水位触发同步操作），最终目的都是为了更新checkpoint值保证write position不要追上来：

概念	计算	含义
Ckp age	LSN1- LSN4	还没有做Checkpoint的日志范围，若Ckp age超过日志空间，说明被覆盖的日志（LSN1－LSN4－Log cap）对应日志和数据“可能”还没有刷到磁盘上
Buf age	LSN1- LSN3	还没有将脏页刷盘的日志的范围，若Buf age超过日志空间，说明被覆盖的日志（LSN1－LSN3－Log cap）对应数据“肯定”还没有刷到磁盘上
Buf async	日志空间大小 * 7/8	强制将Buf age-Buf async的脏页刷盘，此时事务还可以继续执行，所以为async，对事务的执行速度没有直接影响（有间接影响，例如CPU和磁盘更忙了，事务的执行速度可能受到影响）
Buf sync	日志空间大小 * 15/16	强制将2*(Buf age-Buf async)的脏页刷盘，此时事务停止执行，所以为sync，由于有大量的脏页刷盘，因此阻塞的时间比Ckp sync要长。
Ckp async	日志空间大小 * 31/32	强制写Checkpoint，此时事务还可以继续执行，所以为async，对事务的执行速度没有影响（间接影响也不大，因为写Checkpoint的操作比较简单）
Ckp sync	日志空间大小 * 64/64	强制写Checkpoint，此时事务停止执行，所以为sync，但由于写Checkpoint的操作比较简单，即使阻塞，时间也很短

当事务执行速度大于脏页刷盘速度时，Ckp age和Buf age会逐步增长，当达到async点的时候，强制进行脏页刷盘或者写Checkpoint，如果这样做还是赶不上事务执行的速度，则为了避免数据丢失，到达sync点的时候，会阻塞其它所有的事务，专门进行脏页刷盘或者写Checkpoint。

因此从理论上来说,只要事务执行速度大于脏页刷盘速度，最终都会触发日志保护机制，进而将事务阻塞，导致MySQL操作挂起。

由于写Checkpoint本身的操作相比写脏页要简单，耗费时间也要少得多，且Ckp sync点在Buf sync点之后，因此绝大部分的阻塞都是阻塞在了Buf sync点，这也是当事务阻塞的时候，IO很高的原因，因为这个时候在不断的刷脏页数据到磁盘。

以上是个人总结网上的资料做的学习记录，如有错误请及时指正，以免误导他人，感谢！

关于Mysql中redo log和LSN的理解相关推荐

【MySQL】redo log --- 刷入磁盘过程
1.redo log基本概念 redo log的相关概念这里就不再过多阐述,网上有非常多的好的资料,可以看下缥缈大神的文章:https://www.cnblogs.com/cuisi/p/652507 ...
mysql中的scn_关于SCN的理解(全面)
1.oracle正常运行时,control文件的SCN是个很大的数,与redo log文件.数据文件的SCN不同,正常关闭时,做完checkpoint后,三者的SCN值相同; Biti:日志文件中sc ...
mysql中having的意思_正确理解MySQL中的where和having的区别
展开全部 1.where和having都可以使用的32313133353236313431303231363533e4b893e5b19e31333363383964场景select goods_pr ...
精讲 MySQL 事务日志：redo log 和 undo log
来源:https://blog.csdn.net/demonson/article/details/104369733 innodb事务日志包括redo log和undo log.redo log是重 ...
mysql重做日志与binlog日志区别_MySQL日志之binlog、redo log、undo log
1. binlog(二进制日志) 1.1 binlog介绍 binlog记录了对数据库执行更改的所有操作(不包括查询),还包括了执行数据库更改操作的时间和执行时间等信息.binlog主要有两个作用:恢 ...
《MySQL——redo log 与 binlog 写入机制》
目录 binlog写入机制 redo log写入机制组提交机制实现大量的TPS 理解WAL机制如何提升IO性能瓶颈 WAL机制告诉我们:只要redo log与binlog保证持久化到磁盘里,就能确 ...
Mysql redo log 漫游
作者 | 曹金霖杏仁Java工程师,正在锻炼自制力的朴素程序猿. redo log -> 物理日志 redo log 通常是物理日志,记录的是数据页的物理修改,而不是某一行或某几行修改成怎样怎 ...
认真学习MySQL中的二进制日志(binlog)与中继日志（Relay log）
binlog即binary log,二进制日志文件,也叫作变更日志(update log).它记录了数据库所有执行的DDL和DML等数据库更新事件的语句,但是不包含没有修改任何数据的语句(如数据查询语 ...
一生挚友redo log、binlog《死磕MySQL系列二》
一生挚友redo log.binlog 系列文章前言一.redo log 二.如何根据项目情况设置innodb_log_file_size 二.binlog 三.什么是两阶段提交四.为什么需要两 ...
InnoDB之redo log
在事务的实现机制上,MySQL采用的是WAL(Write-ahead logging,预写式日志)机制来实现的. 在使用WAL的系统中,所有的修改都先被写入到日志中,然后再被应用到系统中.通常包含re ...

关于Mysql中redo log和LSN的理解

关于Mysql中redo log和LSN的理解相关推荐

最新文章

热门文章