InnoDB存储引擎文件

MySql中每个表存储引擎都有自己独有的文件,InnoDB存储引擎相关的文件主要包括:重做日志文件,表空间文件。

1、表空间文件

InnoDB采用将存储的数据按表空间(tablespace)进行存放的设计。在默认配置下会有一个初始大小为10MB,名为ibdata1的文件。该文件就是默认的表空间文件(tablespace file),用户可以通过参数innodb_data_file_path对其进行设置.

mysql> show variables like 'innodb_data_file_path';
+-----------------------+------------------------+
| Variable_name         | Value                  |
+-----------------------+------------------------+
| innodb_data_file_path | ibdata1:10M:autoextend |
+-----------------------+------------------------+
1 row in set (0.00 sec)

用户可以通过多个文件组成一个表空间,同时制定文件的属性。
innodb_data_file_path=/db/ibdata1:200M;/dr2/db/ibdata2:2000M:autoextend
这里/db/ibdata1和/dr2/db/ibdata2两个文件用来组成表空间。若这两个文件位于不同的磁盘上,磁盘的负载可能被平均,因此可以提高数据库的整体性能。同时,两个文件的文件名后都跟了属性,表示文件ibdata1大小为200M, ibdata2大小为20000M,如果用完了这2000M,该文件可以自动增长(autoextend)。

设置innodb_data_file_path参数后,所有基于InnoDB存储引擎的表的数据都会记录到该共享表空间中。若设置了擦拭农户innodb_file_per_table,则用户可以将每个基于InnoDB存储引擎的表产生一个独立表空间。
独立表空间的命名规则为:表名.ibd。通过这样的方式,用户不用将所有数据都存放于默认的表空间中。
这些单独的表空间仅仅存储该表的数据、索引和插入缓冲BITMAP等信息,其余信息还是存放在默认的表空间中。
默认该参数是关闭的。

mysql> show variables like 'innodb_file_per_table';
+-----------------------+-------+
| Variable_name         | Value |
+-----------------------+-------+
| innodb_file_per_table | OFF   |
+-----------------------+-------+
1 row in set (0.00 sec)

下图显示了InnoDB存储引擎对于文件的存储方式:
InnoDB存储引擎文件_第1张图片

2、重做日志文件

在默认情况下,在InnoDB存储引擎的数据目录下会有两个名为ib_logfile0和ib_logfile1的文件。在MySql官方手册中将其称为InnoDB存储引擎的日志文件,不过更准确的定义应该是重做日志文件(redo log file)。
重做日志文件对于InnoDB存储引擎很重要,它们记录了对于InnoDB存储引擎的事务日志。

当实例或介质(media failure)时,重做日志文件就派上用场了。例如,数据库由于所在主机掉电导致实例失败,InnoDB存储引擎会使用重做日志恢复到掉电前的时刻,以此来保证数据的完整性。

每个InnoDB存储引擎至少有1个重做日志文件组,每个文件组下至少有2个重做日志文件,如默认的ib_logfile0和ib_logfile1。

root@TryHard:~# find / -name ib_logfile*;
/var/lib/mysql/ib_logfile1
/var/lib/mysql/ib_logfile0

为了得到更高的可靠性,用户可以设置多个镜像日志组,将不同的文件组放在不同的磁盘上,以此提高日志的高可用性。在日志组中每个重做日志文件的大小一致,并以循环写入的方式运行。InnoDB存储引擎先写重做日志文件1,当达到文件的最后时,会切换至重做日志文件2,再当重做日志文件2也被写满时,会再切换到重做日志文件1中。下图显示了一个拥有3个重做日志文件的重做日志文件组。
InnoDB存储引擎文件_第2张图片

下面参数影响着重做日志文件的属性:
(1)innodb_log_file_size
(2)innodb_log_files_in_group
(3)innodb_mirrored_log_groups
(4)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_goup_home_dir指定了日志文件组所在路径,默认为./,表示在MySql数据库的数据目录下。

mysql> show variables like 'innodb%log%';
+--------------------------------+---------+
| Variable_name                  | Value   |
+--------------------------------+---------+
| innodb_flush_log_at_trx_commit | 1       |
| innodb_locks_unsafe_for_binlog | OFF     |
| innodb_log_buffer_size         | 8388608 |
| innodb_log_file_size           | 5242880 |
| innodb_log_files_in_group      | 2       |
| innodb_log_group_home_dir      | ./      |
| innodb_mirrored_log_groups     | 1       |
+--------------------------------+---------+
7 rows in set (0.00 sec)

重做日志文件的大小设置对于InnoDB存储引擎的性能有着非常大的影响。一方面重做日志不能设置的太大。如果设置的很大,在恢复时可能需要很长的时间;另一方面又不能设置的太小了,否则可能导致一个事务的日志需要多次切换重做日志文件。此外,重做日志文件太小会导致频繁地发生async checkpoint,导致性能的抖动。
因为重做日志有一个capacity变量,该值代表了最后的检查点不能超过这个阀值,如果超过则必须将缓冲池中脏页列表中的部分脏数据页写回磁盘,这时会导致用户线程的阻塞。


重做日志也是记录事务日志,那么它和二进制日志有什么区别?

首先,二进制日志会记录所有与MySql数据库有关的日志记录,包括InnoDB,MyISAM,Heap等其它存储引擎的日志。而InnoDB存储引擎的重做日志只记录有关该存储引擎本身的事务日志。

其次,记录的内容不同。无论用户将二进制日志文件记录的格式设置为STATEMENT还是ROW,又或者是MIXED,其记录的都是关于一个事务的具体操作内容,即该日志是逻辑日志。而InnoDB存储引擎的重做日志文件记录的是关于每个页的更改的物理情况。

最后,写入的时间也不同,二进制日志文件仅在事务提交前进行提交,即只写磁盘一次,不论这时该事务多大。而在事务进行的过程中,却不断有重做日志条目被写入重做日志文件中。

在InnoDB存储引擎中,对于各种不同的操作有着不同的重做日志格式。到InnoDB1.2.x版本为止,总共定义了51种重做日志类型。虽然各种重做日志的类型不同,但是他们有着基本的格式,下表显示了重做日志条目的结构:
这里写图片描述
重做日志条目由4个部分组成:
redo_log_type占用1个字节,表示重做日志的类型。
space表示表空间的ID,但采用压缩的方式,因此占用的空间可能小于4字节。
page_no表示页的偏移量,同样采用压缩的方式
redo_log_body表示每个重做日志的数据部分,恢复时需要调用相应的函数进行解析。

写入重做日志文件的操作不是直接写,而是先写入一个重做日志缓冲(redo log buffer)中,然后按照一定的条件顺序地写入日志文件。下图显示了重做日志的写入过程。
InnoDB存储引擎文件_第3张图片

从重做日志缓冲往磁盘写入时,是按512字节,也就是一个扇区的大小进行写入。因为扇区是写入的最小单位,因此可以保证写入必定是成功的。因此在重做日志的写入过程中不需要有doublewrite。


前面说,从日志缓冲写入磁盘上的重做日志文件是按一定条件进行的,那么这些条件有哪些呢?
主线程每秒会将重做日志缓冲写入磁盘的重做日志文件中,不论事务是否已经提交。
另一个触发写磁盘的过程是由参数innodb_flush_log_at_trx_commit控制,表示在提交操作时,处理重做日志的方式。

mysql> show variables like 'innodb_flush_log_at_trx_commit';
+--------------------------------+-------+
| Variable_name                  | Value |
+--------------------------------+-------+
| innodb_flush_log_at_trx_commit | 1     |
+--------------------------------+-------+
1 row in set (0.00 sec)

参数innodb_flush_log_at_trx_commit的有效值有0,1,2。
0代表当前提交事务时,并不将事务的重做日志写入磁盘上的日志文件,而是等待主线程每秒的刷新。
1和2不同的地方在于:1表示在执行commit时将重做日志缓冲同步写到磁盘,即伴有fsync的调用。2表示将重做日志异步写到磁盘,即写到文件系统的缓存中。因此不能完全保证在执行commit时肯定会写入重做日志文件,只是有这个动作发生。

因此为了保证事务的ACID中的持久性,必须将innodb_flush_log_at_trx_commit设置为1,也就是每当有事务提交时,就必须确保事务都已经写入重做日志文件。那么当数据库因为意外发生宕机时,可以通过重做日志文件恢复,并保证可以恢复已经提交的事务。而设置为0或2,都有可能发生恢复时部分事务的丢失。不同之处在于,设置为2时,当MySql数据库发生宕机而操作系统及服务器并没有发生宕机时,由于此时未写入磁盘的事务日志保存在文件系统缓存中,当恢复时同样能保证数据不丢失。


总结
InnoDB存储引擎相关的文件,包括表空间文件和重做日志文件。表空间文件是用来管理InnoDB存储引擎的存储,分为共享表空间和独立表空间。
重做日志非常的重要,用来记录InnoDB存储引擎的事务日志,也因为重做日志的存在,才使得InnoDB存储引擎可以提供可靠的事务。

你可能感兴趣的:(数据库-MySql)