MySQL数据库InnoDB存储引擎 Buffer Pool Flush List详解

Buffer Pool Flush List

add page to flush list

　　buffer pool中的page，有三种状态：

　　l  free：  当前page未被使用

　　l  clean：  当前page被使用，对应于数据文件中的一个页面，但是页面未被修改

　　l  dirty： 当前page被使用，对应于数据文件中的一个页面，同时页面被修改

　　free类型的page，一定位于buf pool的free链表中。

　　clean，dirty两种类型的page，一定位于buf pool的LRU链表中。

　　与此同时，dirty page还位于buf pool的flush链表中。flush list中的dirty page，按照page的oldest_modificattion时间排序，oldest_modification越大，说明page修改的时间越晚，就排在flush 链表的头部；oldest_modification越小，说明page修改的时间越早，就排在flush链表的尾部。当InnoDB进行flush list的flush操作时，从flush list链表的尾部开始，写出足够数量的dirty pages，推进Checkpoint点，保证系统的恢复时间。

　　那么，dirty page是在什么时候进入flush list的呢？看过我以前文档的同学，一定知道InnoDB存储引擎有一个所谓的mini-transaction，页面访问/修改都被封装为一个mini-transaction，当mini-transactin提交的时候，也就是该mini-transaction修改的页面进入flsuh list的时候。

　　mtr_commit -> mtr_memo_note_modification();

　　// 若当前page已经是dirty page，不是第一次修改，那么说明当前page已经在

　　// flush list之中，因此不需要再次加入flush list

　　if (block->page.oldest_modification)

　　ut_ad(block->page.oldest_modification <= mtr_start_lsn);

　　else

　　// 若当前page是第一次修改，oldest_modification = 0，则将page加入flush list

　　buf_flush_insert_into_flush_list();

　　buf_flush_list_mutex_enter(buf_pool);

remove page from flush list

　　有两种操作，可以将dirty page从flush list中移除。一是LRU list flush；二是Flush list flush。其中，LRU list flush已经在前面的章节中分析。

　　而Flush list flush，也就是我们通常所说的InnoDB fuzzy Checkpoint，可以参考我以前的一个文档：MySQL InnoDB Insert Buffer Checkpoint AIO实现分析 。

Buffer Pool LRU/Flush List flush对比

　　总结来说，Flush lish flush与LRU list flush有以下几个不同之处：

Buffer Pool Dump/Load

　　在MySQL 5.6.3及之后的版本中，MySQL数据库InnoDB存储引擎提供了将buf pool dump到一个外存文件中的功能。其实对应的操作十分简单，在Buf0dump.cc文件中。

　　l  Buffer Pool Dump

　　遍历buf pool的LRU list，对于其中的每一个page，读取page的[space_id, page_no]，组成一个64位的数，写到外存文件即可。

　　l  Buffer Pool Load

　　读取外存Dump文件，并完成排序(buf_dump_sort)。对于排序后的DUMP数组中的的每一个[space_id, page_no]组合，发起一个异步读IO (buf_read_page_async())，每64个pages，做一次写同步(os_aio_simulated_wake_handler_threads())

　　总得来说，操作十分简单，但是对应的优势却很明显。通过dump/load可以实现buffer pool的预热，解决了系统重启/切换之后令人头疼的buffer pool预热问题。

Buffer Pool Usage Limitations

　　此章节记录Buffer Pool的各种使用缺陷，及不同版本的优化策略。

Drop Table

　　在Mark Callaghan的最新一篇博文：Stalls during DDL中[6]（备注：mysqlops网站上也有相关文章分析这个严重问题，链接地址：http://www.mysqlops.com/2012/04/01/mysql-innodb-file-per-table.html），其提到InnoDB存储引擎在进行Drop Table操作时，会短暂hang住整个系统，而且这个hang的时间的长短与Buffer Pool的大小相关。主要原因在于InnoDB在drop table时，会连续两次遍历buf pool LRU 链表，遍历的过程加锁，因此导致系统hang住。那么MySQL数据库InnoDB存储引擎在drop table时为何需要遍历LRU链表呢？

　　测试准备：

　　set global innodb_file_per_table=1;

　　create table todrop (a int, b int, c int) engine = innodb;

　　insert into todrop select c1,c2,c3 from nkeys;

　　drop table todrop;

　　ha_innobase::delete_table -> fil0fil.c::fil_delete_tablespace()

　　// 不允许后续的Insert Buffer Merge操作，并等待现有Merge操作完成

　　space->stop_ibuf_merges = TRUE;

　　// 不允许Tablespace上后续的I/O与flush操作，并等待现有操作完成

　　space->is_being_deleted = TRUE;

　　buf_LRU_invalidate_tablespace();

　　// 此函数的主要功能，是用于是否drop table在adpative hash中的所有记录

　　buf_LRU_drop_page_hash_for_tablespace();

　　// 获取当前buf pool的mutex，遍历buf pool LRU list的准备

　　buf_pool_mutex_enter();

　　// 本函数接下来的功能包括：

　　// 1. 从LRU链表尾部开始遍历

　　// 2. 对于每一个属于Drop Table的page，判断page中是否有项进入

　　//  adaptive hash，若有，则收集当前page

　　// 3. 收集到1024个这样的page后，释放buf pool mutex，集中调用函数

　　//  buf_LRU_drop_page_hash_batch，释放page在adaptive hash中的项

　　// 4. 重新获取buf pool mutex，继续遍历buf pool LRU 链表，直至链表头

　　// 5. 最终，是否buf pool mutex，退出

　　…

　　// 再次遍历buf pool LRU 链表，释放所有drop table对应的page

　　buf_LRU_invalidate_tablespace_buf_pool_instance();

　　// 简要的处理流程描述：

　　// 1. 获取buf pool mutex

　　// 2. 遍历buffer pool LRU链表

　　// 3. 若为dirty page，则将dirty page设置为clean page，并从flush list中移除

　　// 4. 将page从LRU list中移除，并且添加入free list

　　// 5. 最后，释放buf pool mutex

　　总结：

　　l  确实需要遍历两遍buf pool LRU 链表

　　一遍用于释放adaptive hash中的记录；二遍是用于释放page。

　　l  第一遍遍历LRU链表，会定期释放buf pool mutex，因此对于系统hang的影响较小；而第二遍会一直持有，对系统hang的影响较大。