love wife love life —Roger的Oracle/MySQL/PostgreSQL数据恢复博客

Phone:18180207355 提供专业Oracle/MySQL/PostgreSQL数据恢复、性能优化、迁移升级、紧急救援等服务

How_to_use_zsql_backup_gaussdb?

本站文章除注明转载外,均为本站原创: 转载自love wife love life —Roger的Oracle/MySQL/PostgreSQL数据恢复博客

本文链接地址: How_to_use_zsql_backup_gaussdb?

任何数据库我们最关注的是数据安全;毫无疑问gaussdb也提供了较多的备份恢复工具;其中最常见的就是命令行zsql工具;我们首先尝试用zsql工具对数据库进行备份恢复;如下是相关测试,供大家参考。

–开始归档

–差异增量0 级备份(压缩)

这里需要注意的是,我使用的是差异增量备份方式。

–查看备份进程情况

–check备份文件是否产生

这里比较奇怪的是以为指定是备份集文件名字,其实是会创建该名称的目录,然后在目录下存放备份文件;可以看到是针对每个文件进行了备份。

—继续进行1级增量备份

 

+++ 恢复测试

[roger@mysqldb gaussdata]$ rm -rf user*

提示控制文件已经存在。在nomount下,居然不能覆盖控制文件。。。。好吧,我rm掉。

 

–继续恢复测试

 

好吧。restore 跟log居然也有关系。好吧。 重新删干净后再次运行(注意:我这里只是删除了redo log;并没有删除归档日志文件)。

可以看到全备恢复成功了。此时的全备restore的log信息如下:

可以看到默认情况下即会启动4个进程进行恢复操作。同时我们可以看到restore进程在完成数据文件restore之后,还自动注册了归档

+++进行数据恢复操作

可以看到,成功恢复了最新数据,无丢失。进一步观察此时recover的操作日志:

可以看到recover的起点:lfn:27160;recover的终点:lfn 27247 。

为了更好的熟悉gaussdb的备份相关原理;我进行了第二次恢复测试!

++++ 第二次恢复测试

删掉所有数据文件,redo文件,控制文件以及归档文件。

–启动实例到nomount

 

–进行restore & recover

为什么会这样呢?我们进一步看一下此时的日志:

我们可以看到此时恢复到的点居然是:onsistent point 27160 这比之前归档存在的情况下恢复的点要小的多。因此最后一条增量数据丢失。这里应该是没有应用到增量备份。

为了进一步探明原因;我再次模拟了测试,恢复到mount状态后;dump了控制文件,发现内容如下:

我们可以控制文件记录的arc信息是比较旧的。我甚至再次进行了测试,在open之前对进程进行strace跟踪;

由此可见应该是gaussdb在restore时默认是使用0级备份去进行恢复数据文件和控制文件;而不会寻找最新的控制文件备份。

测试了几次,strace跟踪发现根本就不会读最新的备份集合;应该是控制文件惹的祸。 0级备份的控制文件中信息是比较旧的。或者是我恢复的方法不对;还请知道的朋友指点一下;谢谢!

 

那么正确的姿势应该是什么样呢,我再次进行了测试,找到了原因

 

–restore(直接指定增量备份备份集;而不是指定全备的备份集

 

可以看到可以恢复出最新的数据。我们可以看到restore时直接使用增量备集时可以恢复到最新时间点的数据的

那么这种情况下,gaussdb会自动去从0级全备中先恢复文件;然后再应用增量吗 ?我们先来看下此时的日志:

 

可以看到日志中并没有记录有过去访问0级备份的信息。还好我再restore时开启了strace跟踪;下面看trace log:

不难看出;确实会去寻找0级备份;然后再应用增量。这也验证了前面的分析。

由此可见;对于使用zsql来进行备份和恢复;再进行restore恢复时,正确的姿势是直接使用增量备份进行恢复;而不是指定全备

然后再去应用增量,这也会报错。

Leave a Reply

You must be logged in to post a comment.