本文上接第二部分，本机讲述REDO日志。
REDO LOG日志文件管理的用途
REDO LOG是用来做数据库crash recovery的，这是数据库保障数据安全的重要功能之一。在数据库操作中，它保存了对InnoDB表中数据的修改记录，所以也叫日志文件。在InnoDB存储引擎中，一般默认包括2个日志文件，新建数据库之后，会有名为ib_logfile0和ib_logfile1的两个文件，如果在启动数据库时，这两个文件不存在，则InnoDB会根据配置参数或默认值，重新创建日志文件。
在InnoDB内部的日志管理中，一个很重要的概念是LSN，全名叫Log Sequence
Number，它用来精确记录日志位置信息，且是连续增长的。在InnoDB中，大小为8个字节的值，它的增长量是根据一个MTR（mini-transaction，后面会讲到）写入的日志量来计算的，写多少日志（单位字节），LSN就增长多少。日志文件轮循一圈（所有日志文件是以循环方式使用的），那么LSN的增长量大约就是整个日志文件的大小（日志文件存在文件头等会占用一部分空间）。它是一个集逻辑意义与物理意义于一身的概念。而在有些数据库中，LSN是一个完全逻辑的概念，每提交一个物理事务，LSN就加1。
上面提到，日志文件是以类似循环圈的方式使用的，如下图所示。
在InnoDB中，通过日志组来管理日志文件，是一个逻辑定义，包含若干个日志文件，一个组中的日志文件大小相等，大小通过参数来设置。现在InnoDB只⽀持一个日志组。在MySQL 5.5及之前的版本中，整个日志组的容量不能大于4G（实际上是3.9G多，因为还有一些文件头信息等），到了MySQL5.6.3版本之后，整个日志组的容量可以设置得很大，最大可以达到512G。
REDO日志的写入，都是字节连续的，虽然看上去是多个日志文件，但理解的时候，完全可以把它想象成一个文件，对每一文件掐头去尾，把剩下的空间连接起来，就是总的日志空间了。
日志组中的每一个日志文件，都有自己的格式，内部也是按照大小相等的页面切割，但这里的页面大小是512个字节，由于历史的原因，考虑到机械硬盘的块大小是512字节，日志块大小也如此设计。这是因为写日志其实就是为了提高数据库写入吞吐量，如果每次写入是磁盘块大小的倍数，效率才是最高的，并且日志将逻辑事务对数据库的分散随机写入转化成了顺序的512字节整数倍数据的写入，这样就大大提高了数据库的效率。正是因为这个原因，REDO日志才可以说是数据库管理系统与通过直接写文件来管理数据的最根本的区别之一。
下面展示的是日志文件的格式。
注：图中第一列指的是每一项在页面中的偏移位置，而下一项则是这个值再加上该值在页面中所占长度的值
上面的4个页面（2048字节），就是图中展示的内容，主要用于管理日志内容及整个数据库状态。在这2K内容之后，就是正常的用来存储日志内容的部分，也是按照512字节页面大小的方式存储，下图中展示的是正常日志页面的格式。
普通页面中，都会有12个字节用来存储页面头信息，这些信息主要用于管理这个页面本身的数据存储方式。
- LOG_BLOCK_HDR_NO：4个字节，一个与LSN有关系的块号。
- LOG_BLOCK_HDR_DATA_LEN：2个字节，表示当前页面中存储的日志长度，这个值一般都等于512-12（12为页面头的大小），因为日志在相连的块中是连续存储的，中间不会存在空闲空间，所以如果这个长度不为500，表示此时日志已经扫描完成（Crash Recovery的工作）。
- LOG_BLOCK_FIRST_REC_GROUP：2个字节，表示在当前块中是不是有一个MTR（关于这个概念的意义，会在下一节中专门介绍）的开始位置。因为一个MTR所产生的日志量有可能是超过一个块大小的，那么如果一个MTR跨多个块时，这个值就表示了这个MTR的开始位置究竟是在哪一个块中。如果为0，则表示当前块的日志都属于同一个MTR；而如果其值大于0并且小于上面LOG_BLOCK_HDR_DATA_LEN所表示的值，则说明当前块中的日志是属于两个MTR的，后面MTR的开始位置就是LOG_BLOCK_FIRST_REC_GROUP所表示的位置。
- LOG_BLOCK_CHECKPOINT_NO：4个字节，存储的是检查点的序号。具体什么是检查点，后面会详细介绍。
上面所讲述的就是日志文件的组织结构，只有前面2K是日志头，后面所有的都是一个个连续的、用来存储MTR产生的日志页面。
什么是MTR InnoDB物理事务？
本文已经够长了，且听下回分解吧。
文章来自微信公众号：DBAce
本文链接：https://www.yunweipai.com/15548.html
网友评论comments