innobackupex的备份和恢复是怎么样的

这篇文章给大家介绍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的备份和恢复是怎么样的就分享到这里了，希望以上内容可以对大家有一定的帮助，可以学到更多知识。如果觉得文章不错，可以把它分享出去让更多的人看到。