数据库物理结构包括三种文件,数据结构包括哪三方面

导读

作为MySQL DBA都应该知道,Redo Log是可被覆盖的,是ACID中的D的最重要的构成部分,也就是关系型数据库中的WAL中的L。

Redo Log记录的是redo,那么redo是什么呢?通俗来讲,redo记录的是对应的记录改变的物理操作。说实话,过去的很长一段时间内,数据库物理结构包括三种文件我对redo的认识也仅限于此,并没有好好深入理解redo记录的到底是什么。这次从redo的物理结构上深入理解下redo到底是什么。

Redo Log逻辑&物理结构

数据库物理结构包括三种文件

从逻辑上来讲,redo log记录是连续递增的,但是对应到物理文件就不一样数据库物理结构包括三种文件了,考虑到磁盘空间,redo log被设计成了多个可循环写入的文件。InnoDB要求Redo Log,文件至少有2个,初始文件为 ib_logfile0和 ib_logfile1, ib_logfile0写完以后写 ib_logfile1,等到 ib_logfile1也写完了,从头又开始写 ib_logfile0,这样就形成了一个环形写入的结构。但是覆盖写入的前提是要确定哪个位置点是可以覆盖写的,哪些位置是不能覆盖写的,这个就是check point的工作了,关于checkpoint可以关注我上一篇文章《MySQL Checkpoint》。

Log File物理结构

数据库物理结构包括三种文件

数据库物理结构包括三种文件

从 ib_logfile0和 ib_logfile1这两个文件的物理结构可以看出,在Log Header部分还是有些许差异的, ib_logfile0会多一些额外的信息,主要是checkpoint信息。

并且每个Block的单位是512字节,对应到磁盘每个扇区也是512字节,因此redo log写磁盘是原子写,保证能够写成功,而不像index page一样需要double write来保证安全写入。

我们依次从上到下来看每个Block的结构

Log File Header Block

数据库物理结构包括三种文件

Log Goup ID,可能会配置多个redo组,每个组对应一个id,当前都是0,占用4字节Start LSN,这个redo log文件开始日志的lsn,占用8字节Log File Number,总是为0,占用4字节Created By,备份程序所占用的字节数,占用32字节

另外在ib_logfile0中会有两个checkpoint block,分别是 LOG_CHECKPOINT_1/ LOG_CHECKPOINT_2,两个记录InnoDB Checkpoint信息的字段,分别从文件头的第二个和第四个block开始记录,并且只在每组log的第一个文件中存在,组内其他文件虽然没有checkpoint相关信息,但是也会预留相应的空间出来。这里为什么有两个checkpoint的呢?原因是设计为交替写入,避免因为介质失败而导致无法找到可用的checkpoint的情况。

Log blocks数据库物理结构包括三种文件

log block结构分为日志头段、日志记录、日志尾部

Block Header,占用12字节Data部分Block tailer,占用4字节Block Header

这个部分是每个Block的头部,主要记录的块的信息

Block Number,表示这是第几个block,占用4字节,是通过LSN计算得来的,占用4字节Block data len,表示该block中有多少字节已经被使用了,占用2字节First Rec offet,表示该block中作为第一个新的mtr开始的偏移量,占用2字节Checkpoint number,表示该log block最后被写入时的检查点的值,占用4字节

Data部分

这部分才开始真正记录我们理解的redo log,实际真正可用字节数为512-12-4=496字节,用户的redo是以一条一条的记录存放在这个block的data部分,并且一条redo记录可能会占用多个block

Block tailfer

tailer部分就比较简单了,只是记录一个checksum值,用于正确性校验,占用4字节

Log Record

数据库物理结构包括三种文件

数据库物理结构包括三种文件

没错,redo记录就是这个结构,分为头部、body部分

通用headerredo_log_type,重做日志的类型space ID,表空间IDPage Numer,用于定位哪个page

redo包括几种类型,M_LOG_WRITE_1BYTE、M_LOG_WRITE_2BYTE、M_LOG_WRITE_4BYTE和M_LOG_WRITE_STRING等,其头部格式如下所示

数据库物理结构包括三种文件

数据库物理结构包括三种文件

一条完整的INSERT redo record数据库物理结构包括三种文件

关于LSN

LSN几乎是redo中最重要的概念之一了,LSN表示redo的写入量,标识了checkpoint的位置,标识了page的版本。LSN不仅存在与redo log中,还存在于每个page中。在每个page的头部,有一个 FIL_PAGE_LSN,记录了page的LSN,表示该页最后刷新时的LSN大小。redo中记录的是每个page的日志,因此page中的LSN用来判断是否需要进行恢复操作,这对于MySQL的崩溃恢复及其重要。

关于redo刷盘机制

大概有以下几种情况会触发redo log刷盘

log buffer空间用完了,这就会将已经产生的log buffer中的日志刷到磁盘中,这是最普遍的一种方式;master线程在后台每秒钟刷一次,将当前log buffer中的日志刷到磁盘中;每次执行DML操作时,都会主动检查日志空间是否足够,如果使用空间的量已经超过了一个预设的经验值,就会主动刷日志,以保证在后面真正执行时,不会再执行过程中被动的刷盘,但这里只会是写文件(写入OS缓冲中)不会刷盘在做checkpoint的时候,要保证所有要刷的页面中LSN值最小的日志已经刷入到磁盘,不然,如果此时数据库宕机,日志不存在,但数据页面已经被修改,从而导致数据不一致,就违背了写日志的原则;提交逻辑事务时,会因为参数 innodb_flush_log_at_trx_commit值的不同,产生不同的行为。如果设置0,则在事务提交时,不会去刷日志缓冲区,等待master thread以固定频率去刷盘,这种设置是最危险的 如果设置2,则在事务提交时会将日志写入到文件中,但不会去刷盘,只要操作系统不挂,即使数据库挂了,数据还是不会丢失 如果设置1,则在事务提交的时候将日志写入文件同时fsync,保证redo log落盘,生产环境主库强烈建议设置为1几个建议:innodb_flush_log_at_trx_commit设置为1redo log建议设置2G,组数建议为3组以上,避免因为redo log切换导致性能抖动redo log buffer建议设置32M以上(根据实际情况至少能够缓存1秒的redo)
发布于 2024-08-17 18:08:22
收藏
分享
海报
0 条评论
51
目录

    0 条评论

    本站已关闭游客评论,请登录或者注册后再评论吧~