MySQL内核月报 2014.10-MySQL· 功能改进·InnoDB Warmup特性

<b>提要</b>

相对于纳秒级的内存访问延时，普通的机械盘达到了毫秒级的随机访问延时，对于oltp应用来说，物理io绝对是目前数据库管理系统的最大性能杀手，所以增加内存的大小，提高io的命中率无疑可以作为一种降低时延的常用优化手段。

针对使用innodb引擎的mysql实例来说，增加buffer pool的大小，尽可能的提高buffer pool的命中率，减少物理io的概率，能极大的提升系统的吞吐量。

但是，随着内存越来越大，面临着一个很严重的问题：当内存突然失效，或者实例异常crash后，面对相同的请求压力，或者突然的大压力，系统由于内存未命中会耗尽io资源，并导致request响应变慢，形成雪崩效应。

<b>warmup特性</b>

mysql 5.6 innodb提供了warmup的功能，并增加了三个控制参数：

<dl></dl>

<dd>innodb_buffer_pool_dump_at_shutdown</dd>

<dd>innodb_buffer_pool_filename</dd>

<dd>innodb_buffer_pool_load_at_startup</dd>

<b>工作原理</b>

innodb启动一个后台线程，等待一个条件变量：

1. 当系统shutdown的时候，如果innodb_buffer_pool_dump_at_shutdown=on，系统会notify condition，从buffer pool的lru链表中，读取spaceid+page_no到innodb_buffer_pool_file文件中，然后正常关闭。

2. 当系统startup的时候，如果innodb_buffer_pool_load_at_startup=on，并且存在innodb_buffer_pool_file，会读取元信息，进行异步io读取数据加载到buffer pool中。

3. 为了防止系统运行过久，innodb_buffer_pool_file过时，无法反映当前热点数据的情况，innodb又提供了一个innodb_buffer_pool_dump_now参数，set后会即时进行一次dump，覆盖掉老的文件。

<b>那么问题来了</b>

1. warmup是否影响startup的速度：

<dl><dd>不影响.启动的时候，读取innodb_buffer_pool_file, 排序后，进行异步io，不影响startup的速度。但现实的情况是：如果你是在业务高峰期出现crash，其实对于系统来说，先warmup后，再开放提供服务，更合适。</dd></dl>

2. 异常crash的时候，使用过时的元数据：

<dl><dd>如果异常crash，那么就存在过时的innodb_buffer_pool_file，如果想避免这种情况，系统可以每隔一段时间，进行一次dump。</dd></dl>

3. dump是否导致系统抖动

<dl><dd>dump的过程，会持有mutex，扫描lru链表，读取元数据，如果在系统业务高峰期，可能会产生抖动。</dd></dl>

<b>改进</b>

mysql 5.7 又增强了warmup功能的使用：

1. 新增参数innodb_buffer_pool_dump_pct

<dl><dd>当前innodb的buffer pool可能设置的比较大，可以通过设置dump的比例，控制dump的速度和load时的量。</dd></dl>

2. innodb_io_capacity

<dd>控制load过程中，防止过量使用io资源，如果单机多实例的情况下，同时启动实例，会使io过载。</dd>