MYSQL Xtrabackup 做备份的时候你忘了点什么吗？

众所周知Xtrabackup 是mysql 中重要的备份工具，而数据库的备份中，尤其大内存的 MYSQL 备份中，都有一个问题的存在就是 innodb_buffer_pool 的存在。备份后的MYSQL 在恢复后，一般innodb_buffer_pool 的数据都不会再恢复的数据库上出现，越大的内存和繁忙的MYSQL 在数据恢复后，就会有一个缓冲期，需要预热一段时间。一般来说我们都是希望备份的数据恢复后能带有内存中的数据。其实MYSQL 本身是有这个设置的，就是在关机和开机的时候，将 innodb buffer pool 写入文件，在开始的时候读取这些文件，装载到内存中。

但到备份就不大现实了，终不能为了这个功能，把数据库关机，在备份吧。

自从 XTRABACKUP 2.4.13后，xtrabackup 软件就可以支持将innodb_buffer_pool 的数据备份到备份中并且在恢复的时候装入到内存。

这项功能在对大内存和急需恢复后使用的MYSQL是十分有意义的，试想你恢复完一台128G的MYSQL 后，查询并没有预热，在此期间的查询会大量开始走磁盘，这当然不是一个专业的做法，并且在这段时间很可能出现一些你不想遇到的问题。

所以 XTRABACKUP 提供了再备份的时候，直接将innodb_buffer_pool 进行一个备份，并且在恢复的时候，将其恢复到MYSQL中，等恢复的MYSQL 启动后，你的innodb_buffer_pool 会和源机具有一样的 innodb_buffer_pool 来应对马上到来的大量查询。

我们使用下面的命令就可以进行相关的备份

xtrabackup --defaults-file=/etc/my.cnf --user=root --password='password' --socket=/data/mysql/mysql.sock --backup --dump-innodb-buffer-pool --target-dir=/data/backup/2019-08-31

添加了 --dump-innodb-buffer-pool 但有些同学却抱怨这是一个垃圾的无效的命令，使用这条命令恢复后的MYSQL 并没有和预想的一样，有了 innodb_buffer_pool 的数据。

到底是是命令有问题，还是.......

其实这个功能是MYSQL 5.7 后的本身提供的功能，XTRABACKUP 仅仅是将这个功能在XTRABACKUP 进行了体现而已。

到底是什么原因造成的这里卖个关子

我上面的备份怎么证明我备份了innodb_buffer_pool

SHOW STATUS LIKE 'Innodb_buffer_pool_dump_status';

通过上面的命令就可以展现你最后一次 dump buffer pool 的时间

上面可以证明我的确在我早上 6:59的时候，在备份的期间，将buffer_pool dump下来了。

所以可以证明那个参数是有效的，也可以通过查看你恢复后的数据库的bufferpooldata 来正你恢复了数据

OK 到这里为止，可以证明这个参数是有效的，到底什么原因会导致有些同学的命令无效。

你可以尝试打开下面的参数

SET GLOBAL innodb_buffer_pool_dump_now=ON;

默认此参数是关闭的状态

同时也可以设置到备份的时候要download 多少的 buffer_pool

所以如果你备份的时候不能进行innodb_buffer_pool download 的原因主要是你的那个在线download buffer_pool 的参数是否是打开的状态。

其实有些时候，某些事情的操作看似不成功莫名其妙，其实如果往深挖，往下看，大多是能找到问题的所在的。