InnoDB缓冲池预加载在MySQL 5.7中的正确打开方式

《InnoDB缓冲池预加载在MysqL 5.7中的正确打开方式》要点：
本文介绍了InnoDB缓冲池预加载在MysqL 5.7中的正确打开方式，希望对您有用。如果有疑问，可以联系我们。

DBAplus社群译者：徐肖霞(新炬网络DBA工程师)

译文审核：葛云杰

在这篇文章里,我将讨论在MysqL 5.7里如何使用InnoDB缓冲池预加载特性.

从MysqL 5.6开始,可以配置MysqL保存InnoDB缓存池的数据,并在启动时加载.在MysqL 5.7后,这是默认行为.在默认配置中,MysqL保存和恢复缓存池的一部分,不再需要任何特殊的配置.我们在Percona Server 5.6中提供了一个类似的功能,所以这个概念已经存在了相当长的时间.

坦率来说,时间已经减少了这个特性的需求.五年前,我们通常是在旋转的硬盘上存储数据库,在数据库正常工作负载下,这些磁盘经常要相当长的时间来预热,这导致在重启之后,好几个小时都是低性能的.

随着固态硬盘的崛起,预热变得很快并且减少了缓冲池中数据的加载.通常,一个系统在10分钟或更少的时间,就能达到其充分预热性能的90%.保存缓冲池内容是一个默认启用的特性,所以它的使用,不需要任何精力.

本篇文章将讨论关于这个功能的一些问题,这些问题可能无法通过字面或文档看出来.

MysqL默认在InnoDB缓冲池(而不是整个缓冲池)中仅保留最频繁访问页的25%.

在多数使用场景下,合理的选择是：保留最有用的数据页,比加载所有的页(很多页可能在后续的工作中并没有访问到)在缓冲池中要更快.

你可以更改innodb_buffer_pool_dump_pct变量的值,如果使用InnoDB作为内存数据库时,想保证所有的数据都在内存驻留,并且可以在不读取磁盘的情况下访问,就要将它设为100.

请注意,这个变量是基于内存中的实际数据量,而不是缓冲池的大小.例如,如果有100GB的缓冲池,但只有10GB的数据,默认只有10GB的25%(即2.5GB)数据保存在内存中(如手册中所述,因为磁盘上只存储页面标识符,而不是完整页内容,所以磁盘上的访问量不会太大).

MysqL启动并且在缓冲池加载完成前可以通过网络访问.同时在启动之前,大量资源用于尽快从磁盘读取到缓冲池,这个操作可能会影响性能.

如果你有多个MysqL节点(例如使用MysqL复制或Percona XTradB 集群),则可以考虑在缓冲池加载操作完成后才将他们返回生产环境.您可以通过查看GLOBAL STATUS变量来监视缓冲池加载进度.

缓冲池加载进度：

1 | Innodb_buffer_pool_load_status          | Loaded 403457/419487 pages         |

缓存池加载完成：

1 | Innodb_buffer_pool_load_status          | Buffer pool(s) load completed at 161123  9:18:

另一方面,如果MysqL能提供一个关于节点状态的清晰概念将更好：这与准备以最佳的方式服务于交换往往是不一样的.

InnoDB缓冲池预加载不是非常有效的,至少在快速存储上是这样的.在性能相当好的NVMe存储的测试环境中,在只读负荷下运行时,可以获得超过400MB的/秒的预热速率.InnoDB缓冲池预热速度达到100MB/S,我猜想问题是因为没有开许多并行IO请求的SSD存储运行时需要优化所导致的,但我没有做进一步的研究.

InnoDB缓冲池保存/恢复仅在正常关机状态下保留缓冲池内容.如果服务器崩溃,MysqL仍然会做缓冲池预加载,但仅仅是最近正常关机下的内容信息(存储在ib_buffer_pool文件中),这可能会将时间浪费在与当前工作负荷无关的数据加载上.定期运行操作,可以保证新页可以快速预热,即使是遇到MysqL崩溃的情况.

1 SET GLOBAL innodb_buffer_pool_dump_Now=ON;

保留当前缓冲池的列表.

值得注意的是,MysqL崩溃的情况并不是经常碰到的.这个问题在备份时同样存在.MysqL slave从Percona XtraBackup或是LVM快照克隆库,这会导致这些操作性能降低.

希望本文的见解,能帮助你更好地利用这个功能.

文章来自微信公众号：DBAplus社群