MySQL 5.7.5: Buffer Pool 转储、恢复 以及存在的问题

MySQL提供了一个比较有用的功能,能够把buffer pool LRU上的block对应的page id 和space id 存储到文件中。在重启时,会自动读取这个转储文件,然后把对应的<space id, page id>读入到buffer pool中,快速预热内存,以尽快提供服务。

参数

使用该特性比较简单,通过多个参数控制. 简单说下几个参数

转储到文件:

innodb_buffer_pool_dump_now  : 立刻做一次buffer pool  LRU dump

innodb_buffer_pool_dump_at_shutdown : 在正常关闭实例时做一次转储

从文件中恢复:

innodb_buffer_pool_load_at_startup : 在启动实例时读入转储文件中记录的Page

innodb_buffer_pool_load_now : 立即做一次转储文件读入

innodb_buffer_pool_load_abort:立刻中断LOAD操作

5.7新加参数(http://dev.mysql.com/worklog/task/?id=6504)

innodb_buffer_pool_dump_pct : 表示转储每个bp instance LRU上最热的page的百分比。通过设置该参数可以减少转储的page数。

实现原理:

这部分代码的实现比较简单,就是在开始实例时起一个单独的线程,做page导入工作。

入口函数为buf_dump_thread, 该线程同时负责dump 和load

LOAD:

调用函数buf_load,打开转储文件,从其中读取<space_id, page_id>,并合并成一个unsigned long long类型(BUF_DUMP_CREATE),高32位为space id , 低32位为page id。这主要是为了随后对其进行快速排序(std::sort),这样就可以最可能的顺序读磁盘文件。 这对机械硬盘是有利的。但如果我们使用的是类似SSD盘,并且随时可能abort掉load操作时,我们当然希望是按照从转储文件的记录顺序读入,因为文件头总是记录的最“热”的Page (TODO)

如果转储文件中的page数大于当前Buffer pool能够容纳的page数,则忽略多出来的page。

读取page接口函数buf_read_page_background

buf_load_throttle_if_needed: 每load  innodb_io_capacity 个page,会检查innodb是否active(有用户负载),以及距离上次检查的时间间隔是否超过了1s,如果没有超过,则sleep一段时间,目的是保证1秒内读入的page数不超过innodb_io_capacity

DUMP:

dump的入口函数是buf_dump,遍历每个bp instance,根据参数innodb_buffer_pool_dump_pct计算需要记录的page数, dump的过程中持有buffer pool instance 的mutex.

目前存在的问题(5.6,5.7)

目前BP LOAD是以同步读入page的方式载入buffer pool,因此效率比较低,在我的测试机器上,只有60M/s左右的读入速度。如果修改成异步载入,可以达到每秒400M。

具体可以参考http://bugs.mysql.com/bug.php?id=73583

5.7相关代码:

http://bazaar.launchpad.net/~mysql/mysql-server/5.7/revision/6230

原创文章,转载请注明: 转载自Simple Life

本文链接地址: MySQL 5.7.5: Buffer Pool 转储、恢复 以及存在的问题

Post Footer automatically generated by wp-posturl plugin for wordpress.


Comments

Leave a Reply

Your email address will not be published. Name and email are required


Current month ye@r day *