MySQL系列:innodb引擎分析之文件IO(一)

2015-01-25 21:38:31 · 作者: · 浏览: 5

innodb作为数据库引擎,自然少不了对文件的操作,在innodb中所有需要持久化的信息都需要文件操作,例如:表文件、重做日志文件、事务日志文件、备份归档文件等。innodb对文件IO操作可以是煞费苦心,其主要包括两方面,一个是对异步io的实现,一个是对文件操作管理和io调度的实现。在MySQL-5.6版本的innodb还加入了DIRECT IO实现。做了这么多无非是优化io操作的性能。在innodb的文件IO部分中,主要实现集中在os_file.*和fil0fil.*两个系列的文件当中,其中os_file*是实现基本的文件操作、异步IO和模拟异步IO。fil0fil.*是对文件io做系统的管理和space结构化。下面依次来介绍这两个方面的内容.

1.系统文件IO

在innodb中,文件的操作是比较关键的,innodb封装了基本的文件操作,例如:文件打开与关闭、文件读写以及文件属性访问等。这些是基本的文件操作函数封装。在linux文件的读写方面,默认是采用pread/pwrite函数进行读写操作,如果系统部支持这两个函数,innodb用lseek和read、write函数联合使用来达到效果. 以下是innodb文件操作函数: os_file_create_simple 创建或者打开一个文件 os_file_create 创建或者打开一个文件,如果操作失败会重试,直到成功 os_file_close 关闭打开的文件 os_file_get_size 获得文件的大小 os_file_set_size 设置文件的大小并以0填充文件内容 os_file_flush 将写的内容fsync到磁盘 os_file_read 从文件中读取数据 os_file_write 将数据写入文件 innodb除了实现以上基本的操作以外,还实现了文件的异步IO模型,在Windows下采用的IOCP模型来进行处理(具 体可以见网上的资料),在linux下是采用aio来实现的,有种情况,一种是通过系统本身的aio机制来实现,还有一种是 通过多线程信号模拟来实现aio.这里我们重点来介绍,为了实现aio,innodb定义了slot和slot array,具体数据结构如下:
typedef struct os_aio_slot_struct
{
     ibool	 is_read;                             /*是否是读操作*/
     ulint	 pos;                                    /*slot array的索引位置*/
     ibool	 reserved;                           /*这个slot是否被占用了*/
     ulint	 len;                                     /*读写的块长度*/
     byte*	 buf;                                   /*需要操作的数据缓冲区*/
     ulint	 type;                                   /*操作类型:OS_FILE_READ OS_FILE_WRITE*/
     ulint	 offset;                                 /*当前操作文件偏移位置,低32位*/
     ulint	 offset_high;                        /*当前操作文件偏移位置,高32位*/
     os_file_t	 file;                               /*文件句柄*/
     char*	 name;                               /*文件名*/
     ibool	 io_already_done;             /*在模拟aio的模式下使用,TODO*/
     void*	 message1;
     void*	 message2;
#ifdef POSIX_ASYNC_IO
     struct aiocb	control;                 /*posix 控制块*/
#endif
}os_aio_slot_t;

typedef struct os_aio_array_struct
{
 os_mutex_t	 mutex;          /*slots array的互斥锁*/
 os_event_t	 not_full;         /*可以插入数据的信号,一般在slot数据被aio操作后array_slot有空闲可利用的slot时发送*/
 os_event_t	 is_empty;       /*array 被清空的信号,一般在slot数据被aio操作后array_slot里面没有slot时发送这个信号*/

 ulint	 n_slots;                     /*slots总体单元个数*/
 ulint	 n_segments;             /*segment个数,一般一个对应n个slot,n = n_slots/n_segments,一个segment作为aio一次的操作范围*/
 ulint	 n_reserved;              /*有效的slots个数*/
 os_aio_slot_t*	slots;         /*slots数组*/

 os_event_t*	 events;         /*slots event array,暂时没弄明白做啥用的*/
}os_aio_array_t;
内存结构关系图:
\

2.文件管理的内存结构

在innodb中定义三种文件类型:表空间文件(ibdata*)、重做日志文件(ib_logfile*)和归档文件(ib_arch_log*)。一般innodb在运行的过程中,会同时打开很多个文件,这就要求对文件进行系统的管理和控制。在innodb中定义了一套基于fil_system_t、fil_space_t和fil_node_t的内存管理结构。每个文件对应的是一个fil_node_t,fil_node是存储的最小单元,多个同一模块的fil_node组成一个fil_space_t,所有的space组成一个fil_system_t,在innodb引擎里,只有一个fil_system_t对象。

fil_system_t管理着全局的文件操作资源,例如:文件打开的数量、打开文件的信号控制、fil_space_t的管理和索引等。以下是fil_system_t的结构定义:

?

typedef struct fil_system_struct
{
     mutex_t	 mutex;              /*file system的保护锁*/
     hash_table_t*	spaces;     /*space的哈希表,用于快速检索space,一般是通过space id查找*/
     ulint	 n_open_pending;  /*当前有读写IO操作的fil_node个数*/
     ulint	 max_n_open;         /*最大允许打开的文件个数*/
     os_event_t	 can_open;    /*可以打开新的文件的信号*/
 
    UT_LIST_BASE_NODE_T(fil_node_t) LRU;       /*最近被打开操作过的文件,用于快速定位关闭的fil_node*/
    UT_LIST_BASE_NODE_T(fil_node_t) space_list;	 /*file space的对象列表*/
}fil_system_t;
值得注意的是space的哈希表和LRU,这里为什么会出现用hash table来索引space呢?因为在实际的数据库系统中,fil_space_t是会非常多的,用哈希表能快速定位到需要操作的fil_space_t。LRU是用于保存最近被打开和被操作过的fil_node,为了避免频发的关闭和打开文件,LRU保存一定数量(500)的最近打开过的文件,这样可以提高系统的效率。

?

fil_space_t是用于管理同一模块的file_node,上层模块操作文件不是以文件名来做操作关联的,而是用space_id,

也就是说,所有的文件操作是通过space为单位进行操作的。fil