Innodb parent table open时导致crash
case描述:
innodb中,父表和子表通过foreign constraint进行关联, 因为在更新数据时需要check 外键constraint,如果父表被大量的子表reference,
那么在open的时候,需要open所有的child table和所有的foreign constraint,导致时间过长,产生long semaphore wait 。
分析过程:
case 用例:
CREATE TABLE `t1` ( `f1` int(11) NOT NULL, PRIMARY KEY (`f1`) ) ENGINE=InnoDB CREATE TABLE `fk_1` ( `f1` int(11) NOT NULL, PRIMARY KEY (`f1`), CONSTRAINT `pc1` FOREIGN KEY (`f1`) REFERENCES `t1` (`f1`) ON DELETE CASCADE ON UPDATE CASCADE ) ENGINE=InnoDB ...... 这里建了fk_[0-10000]张表。
1. 背景:innodb数据字典
innodb使用系统表空间保存表相关的数据字典,系统的数据字典包括:
- SYS_TABLES
- SYS_INDEXES
- SYS_COLUMNS
- SYS_FIELDS
- SYS_FOREIGN
- SYS_FOREIGN_COLS
- SYS_STATS
在load某个表的时候,分别从这些表中把表相关的index,column, index_field, foreign, foreign_col数据保存到dictionary cache中。
对应的内存对象分别是:dict_col_struct,dict_field_struct,dict_index_struct,dict_table_struct,dict_foreign_struct。
这些对象全局唯一,在dictionary cache只保留一份,并使用dict_sys->mutex进行同步保护,所有open的handler引用到这些对象上。
注意:系统的数据字典同样是innodb的聚簇索引表,并受redo保护。
2. open过程
入口函数ha_innobase::open()
dict_load_table:
1. 通过sys_tables系统表,load table相关的定义
2. 通过sys_indexes系统表,根据table_id load 所有相关index
3. 通过sys_columns系统表,根据table_id load 所有的columns
4. 通过sys_fields系统表,根据index_id load 所有index的field
5. 通过sys_foreign系统表,load所有关联的表和foreign key
在load这些定义的时候,过程都是:
1. 通过某个字段,查找系统字典表
2. 根据查询的记录建立内存对象,并加入到全局cache中
但在load foreign的时候,会有一些不同,因为foreign key于两张表相关联。下面详细介绍下load foreign的过程。
3. load foreign的详细过程
如下图所示foreign的关联关系:
load的步骤:
3.1: 根据表名t1 查找sys_foreign. 而sys_foreign表上一共有三个索引:
index_1(id): cluster_index
index_2(for_name): secondary_index
index_3(ref_name): secondary_index
所以,根据for_name=‘t1‘, ref_name=‘t1‘检索出来所有相关的foreign_id.
3.2: 根据3.1检索出来的foreign_id, load foreign对象,并打开相关fk_[1-10000]表。
3.3: 加入cache
因为没有专门的cache,foreign分别加入到for_name->foreign_list, ref_name->refence_list
问题的关键:因为foreign是全局唯一的,但foreign又与两个表关联,所以,有可能在open 其它表的时候
已经打开过,所以,create foreign对象后,需要判断以下四个list,是否已经存在,如果存在就直接使用。
dict_foreign_find:分别查询这四个list,如果已经存在,则free新建的foreign对象,引用已经存在的。
for_name->foreign_list
for_name->refence_list
ref_name->foreign_list
ref_name->refence_list
如果不存在,把新建的foreign加入到for_name->foreign_list,ref_name->refence_list链表中。
4. 问题的原因:
因为第一次load,所以find都没有找到,但这四个都是list,随着open的越来越多,检索的代价越来越大。
而整个过程中,都一直持有trx_sys->mutex,最终导致了long semaphore wait。
5. 问题改进方法:
在MySQL 5.5.39版本中,进行了修复,修复的方法就是,除了foreign_list,referenced_list。
另外又增加了两个red_black tree,如下源码所示:
struct dict_table_struct{ table_id_t id; /*!< id of the table */ mem_heap_t* heap; /*!< memory heap */ char* name; /*!< table name */ UT_LIST_BASE_NODE_T(dict_foreign_t) foreign_list; /*!< list of foreign key constraints in the table; these refer to columns in other tables */ UT_LIST_BASE_NODE_T(dict_foreign_t) referenced_list;/*!< list of foreign key constraints which refer to this table */ ib_rbt_t* foreign_rbt; /*!< a rb-tree of all foreign keys listed in foreign_list, sorted by foreign->id */ ib_rbt_t* referenced_rbt; /*!< a rb-tree of all foreign keys listed in referenced_list, sorted by foreign->id */
在初始化list的时候,初始化一份red_black tree. 在dict_foreign_find的过程中,直接查找rbt,这样查询的代价大大降低。
郑重声明:本站内容如果来自互联网及其他传播媒体,其版权均属原媒体及文章作者所有。转载目的在于传递更多信息及用于网络分享,并不代表本站赞同其观点和对其真实性负责,也不构成任何其他建议。