共计 1602 个字符，预计需要花费 5 分钟才能阅读完成。
这篇文章给大家介绍 innobackupex 的备份和恢复是怎么样的，内容非常详细，感兴趣的小伙伴们可以参考借鉴，希望对大家能有所帮助。
原理
阶段：备份 backup – 预恢复 prepare — 恢复 restore
表文件时可能包含不完整事务，需要 prepare 将其变为 consistent 数据文件，这样复制出来的文件肯定是不一致的，然后对每个文件进行崩溃恢复处理，最终达到一致.
在启动的时候会记录一个 LSN（log sequence number），然后就把所有的 Innodb 数据文件复制出来，这样复制出来的数据文件是不一致的，但是 XtraBackup 会在后台运行一个进程把所有对 redo
log file 的修改记录下来；
二进制程序（比如 xtrabackup_55）完成的，如果使用 innobackupex 脚本，刚才的步骤完成以后，innobackupex 就会去备份 MyISAM 表和.frm 文件，这时要保证数据的一致性就会先锁表了，通过 FLUSH
TABLES WITH READ LOCK 命令锁表然后把文件复制出来，再释放掉这个锁。
（recovery）和 restore 两个步骤。在 prepare 结束以后，Innodb 的表恢复到了复制 Innodb 文件结束的时间点，这个时间点也就是锁表复制 MyISAM 表的起点，所以最终数据是一致的。一般我们在恢复的时候执行两次 prepare，是因为第二次 prepare 会帮助我们生成 redo log 文件，从而加快 MySQL 数据库启动的速度。
将数据库备份放在 BACKUP-DIR 目录，默认新建一个子目录，–no-timestamp 会跳过此功能；选项指定所用内存以加快进度，默认 100M；读取 datadir/innodb_data_home_dir/innodb_data_file_path 等变量；
表是 innodb 表，最后为 logfile；–data-dir 目录必须为空
增量备份文件，内容如下
文件内容如下
有点复杂，如果对 base
backup 执行事务一致性恢复，则其不能再用于增量备份恢复，为此须指定—redo-only 选项；
恢复单表提供了 restore datafile，针对坏块也有 blockrecover，即尽可能的避免全库恢复；也提供了类似功能，允许恢复单个表空间；让 innodb 采用 slow shutdown(full purge +
change buffer merge)，以保证表空间处于一致性并被 import；
数据字典的 dump，5.6 起不是必需；
创建相同结构的表复制到数据目录
基于时间点的恢复，记录备份 binlog 时数据库当前位置，这也是数据库一致性恢复的终点；
执行时间点恢复
–start-position=57
–stop-datetime= 11-12-25 01:00:00 | mysql -u root –p
在 slave 执行备份
须留意以下两个参数
– 从属信息
此选项在备份复制从属服务器时非常有用。它打印主服务器的二进制日志位置和名称。它还将此信息作为更改主命令写入 xtrabackup_slave_info 文件。通过在此备份上启动从属服务器，并使用保存在 xtrabackup\u slave\u info 文件中的二进制日志位置发出 CHANGE master 命令，可以设置此主服务器的新从属服务器。
– 安全从备份
停止从属 SQL 线程并等待启动备份，直到“显示”状态下的从属打开临时表为零。如果没有打开的临时表，将进行备份，否则将启动和停止 SQL 线程，直到没有打开的临时表。如果在 –safe Slave backup timeout 秒后 Slave_open_temp_tables 未变为零，备份将失败。备份完成后，从属 SQL 线程将重新启动。
关于 innobackupex 的备份和恢复是怎么样的就分享到这里了，希望以上内容可以对大家有一定的帮助，可以学到更多知识。如果觉得文章不错，可以把它分享出去让更多的人看到。
