重做日志文件
在默认情况下,在 InnodB存储引擎的数据目录下会有两个名为 ib logfile0和
logfile1的文件。在 MySQL官方手册中将其称为 InnoDB存储引擎的日志文件,不过更准确的定义应该是重做日志文件( redo log file)。为什么强调是重做日志文件呢?因为重做日志文件对于 InnodB存储引擎至关重要,它们记录了对于 innodb存储引擎的事务日志。
当实例或介质失败(media faliure)时,重做日志文件就能派上用场。例如,数据库由于所在主机掉电导致实例失败，innodb存储引擎会使用重做日志恢复到掉电前的时刻,以此来保证数据的完整性。
每个innoDB存储引擎至少有1个重做日志文件组( group),每个文件组下至少有2
个重做日志文件,如默认的 ib logfile0和 lib logfile1。为了得到更高的可靠性,用户可以设置多个的镜像日志组( mirrored log groups),将不同的文件组放在不同的磁盘以此提高重做日志的高可用性。在日志组中每个重做日志文件的大小一致,并以循环写入的方式运行。 InnodB存储引擎先写重做日志文件1,当达到文件的最后时,会切换至重做日志文件2,再当重做日志文件2也被写满时,会再切换到重做日志文件1中图3-2显示了一个拥有3个重做日志文件的重做日志文件组
下列参数影响着重做日志文件的属性
- innodb_log_file_size
- Innodb_log_files_in_group
- Innodb_mirrored_log_groups
- Innodb_log_group_home_dir
参数 innodb_log_file_size指定每个重做日志文件的大小。在 InnodB1.2.x版本之前,重做日志文件总的大小不得大于等于4GB,而1.2.x版本将该限制扩大为了512GB
参数 innodb log_ files in_ group指定了日志文件组中重做日志文件的数量,默认为2。
参数 innodb_ mirrored_log_ groups指定了日志镜像文件组的数量,默认为1,表示有一个日志文件组,没有镜像。若磁盘本身已经做了高可用的方案,如磁盘阵列,那么以不开启重做日志镜像的功能。
最后,参数 Innodb_log_group_home_dir指定了日志文件组所在路径,默认为./,表示在 MySQL数据库的数据目录下。
重做日志文件的大小设置对于 Innodb存储引擎的性能有着非常大的影响。一方面重做日志文件不能设置得太大,如果设置得很大,在恢复时可能需要很长的时间;另一方面又不能设置得太小了,否则可能导致一个事务的日志需要多次切换重做日志文件。此外,重做日志文件太小会导致频繁地发生async checkpoint,导致性能的抖动。
也许有人会问,既然同样是记录事务日志,和之前介绍的二进制日志有什么区别?
首先,二进制日志会记录所有与 MySQL数据库有关的日志记录,包括 InnoDB
MyISAM、Heap等其他存储引擎的日志。而IηnoDB存储引擎的重做日志只记录有关该存储引擎本身的事务日志。
其次,记录的内容不同,无论用户将二进制日志文件记录的格式设为 STATEM
还是ROW,又或者是MXED,其记录的都是关于一个事务的具体操作内容,即该日志
是逻辑日志。而noDB存储引擎的重做日志文件记录的是关于每个页(Page)的更改
的物理情况。
此外,写入的时间也不同,二进制日志文件仅在事务提交前进行提交,即只写磁盘一
次,不论这时该事务多大。而在事务进行的过程中,却不断有重做日志条目(redo
entry)被写入到重做日志文件中
在 InnodB存储引擎中,对于各种不同的操作有着不同的重做日志格式。到 InnoDB 1.2.x版本为止,总共定义了51种重做日志类型。虽然各种重做日志的类型不同,但是它们有着基本的格式,表3-2显示了重做日志条目的结构
从表3-2可以看到重做日志条目是由4个部分组成
- redo_log_type占用1字节,表示重做日志的类型
- space表示表空间的|D,但采用压缩的方式,因此占用的空间可能小于4字节
- page_no表示页的偏移量,同样采用压缩的方式
- redo_log_body表示每个重做日志的数据部分,恢复时需要调用相应的函数进行
解析.
写入重做日志文件的操作不是直接写,而是先写入一个重做日志缓冲( redo log buffer)中,然后按照一定的条件顺序地写入日志文件。图3-3很好地诠释了重做日志的写入过程
前面提到了从日志缓冲写入磁盘上的重做日志文件是按一定条件进行的,那这些条
件有哪些呢?
在主线程中每秒会将重做日志缓冲写入磁盘的重做日志文件中,不论事务是否已经提交。另一个触发写磁盘的过程是由参数 Innodb_flush_log_at_trx_commit控制,表示在提交( commit)操作时,处理
重做日志的方式。
参数 Innodb_flush_log_at_trx_commit的有效值有0、1、2。0代表当提交事务时并不将事务的重做日志写入磁盘上的日志文件,而是等待主线程每秒的刷新。1和2不同的地方在于: 1表示在执行 commit时将重做日志缓冲同步写到磁盘,即伴有 fsync的调用。2表示将重做日志异步写到磁盘,即写到文件系统的缓存中。因此不能完全保证在执行comm时肯定会写入重做日志文件,只是有这个动作发生。
因此为了保证事务的AC|D中的持久性,必须将 Innodb_flush_log_at_trx_commit设置为1,也就是每当有事务提交时,就必须确保事务都已经写入重做日志文件。那么当数据库因为意外发生宕机时,可以通过重做日志文件恢复,并保证可以恢复已经提交的事务。而将重做日志文件设置为0或2,都有可能发生恢复时部分事务的丟失。不同之处在于,设置为2时,当MySqL数据库发生宕机而操作系统及服务器并没有发生宕机时由于此时未写入磁盘的事务日志保存在文件系统缓存中,当恢复时同样能保证数据不丟失