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

这篇文章给大家介绍innobackupex的备份和恢复是怎么样的,内容非常详细,感兴趣的小伙伴们可以参考借鉴,希望对大家能有所帮助。

原理

阶段:备份backup – 预恢复prepare  — 恢复restore

表文件时可能包含不完整事务,需要prepare将其变为consistent数据文件,这样复制出来的文件肯定是不一致的,然后对每个文件进行崩溃恢复处理,最终达到一致.

在启动的时候会记录一个LSNlog 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

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

原创文章,作者:3628473679,如若转载,请注明出处:https://blog.ytso.com/202062.html

(0)
上一篇 2021年11月25日
下一篇 2021年11月25日

相关推荐

发表回复

登录后才能评论