增量备份
Roach支持集群增量备份。全量备份会将源数据完整备份,而增量备份仅将上次备份后所做的更改进行备份,这里的上次备份可以是全量备份,也可以是全量备份后的增量备份。
- 增量备份和全量备份的差异点在于,执行增量备份命令时需要提供--prior-backup-key参数,该参数为上次备份的backup key。通过该参数,系统可以获取到上次备份信息,以判断继上次备份之后所更改的数据,用于执行本次的增量备份。详情请参阅“备份命令”章节。
- 增量备份(也包括全量备份)结果目录按时间戳命名,这个时间戳就是备份的backup key。时间戳信息可用于基于时间的数据恢复功能,该功能可将集群恢复到特定时间(全量备份点或增量备份点)的数据状态。
- 累积增量备份:如果一次全量备份之后的多次增量备份中,指定的--prior-backup-key参数值始终为全量备份的backup key,那么增量备份就是累积增量备份,累积增量备份均是基于最近一次全量备份,如图1所示。图1 累积增量备份
- 2018年2月8日6:00执行了全量备份,全量备份将备份整个集群的所有数据。
- 2018年2月8日7:00执行了增量备份,--prior-backup-key参数为6:00执行的全量备份的backup key,本次增量备份将自6:00全量备份之后所做的更改进行备份。
- 2018年2月8日8:00执行了增量备份,--prior-backup-key参数为6:00执行的全量备份的backup key,本次增量备份将自6:00全量备份之后所做的更改进行备份。
- 2018年2月8日9:00执行了增量备份,--prior-backup-key参数为6:00执行的全量备份的backup key,本次增量备份将自6:00全量备份之后所做的更改进行备份。
- 2018年2月8日10:00执行了增量备份,--prior-backup-key参数为6:00执行的全量备份的backup key,本次增量备份将自6:00全量备份之后所做的更改进行备份。
- 差分增量备份:如果一次全量备份之后的多次增量备份中,指定的--prior-backup-key参数值均为上次备份(可能是全量备份也可能是增量备份)的backup key,那么增量备份就是差分增量备份,差分增量备份均是基于最近一次备份,如图2所示。图2 差分增量备份
- 2018年2月8日6:00执行了全量备份,全量备份将备份整个集群的所有数据。
- 2018年2月8日7:00执行了增量备份,--prior-backup-key参数为6:00执行的全量备份的backup key,本次增量备份将自6:00全量备份之后所做的更改进行备份。
- 2018年2月8日8:00执行了增量备份,--prior-backup-key参数为7:00执行的增量备份的backup key,本次增量备份将自7:00增量备份之后所做的更改进行备份。
- 2018年2月8日9:00执行了增量备份,--prior-backup-key参数为8:00执行的增量备份的backup key,本次增量备份将自8:00增量备份之后所做的更改进行备份。
- 2018年2月8日10:00执行了增量备份,--prior-backup-key参数为9:00执行的增量备份的backup key,本次增量备份将自9:00增量备份之后所做的更改进行备份。
建议控制全量备份间增量备份的次数,当增量备份的次数太多时,数据恢复时需要恢复的增量备份次数太多,会导致系统性能下降。
由于增量备份需要了解先前的备份信息,因此增量备份的可靠性也取决于之前备份的可靠性。可以使用--validate-prior-backups参数在创建新的增量备份之前检查和验证先前的备份。
用户必须确保系统时间在执行全量备份后到增量备份前未曾更改。如果更改了时间,增量备份和、或恢复操作无法正常执行。
基于一次全量备份的多次增量备份,其备份命令的--meta-destination参数指定的目录要相同。
操作步骤
- 以omm用户身份登录GaussDB 100任意服务器。
- 进入$ROACH_HOME目录。
cd $ROACH_HOME
- 查看集群状态是否是Normal。
gs_om -t status
集群状态是Normal(即cluster_state : Normal)时,可以继续执行备份。
- 执行备份。
增量备份和全量备份命令的差异点在于,增量备份需要指定--prior-backup-key参数。python GaussRoach.py -t backup --master-port <master_port> --media-destination <media_destination_path> --media-type <media-type> --metadata-destination <metadata_path> --prior-backup-key <prior-backup-key>
--metadata-destination参数指定的元数据路径和--media-destination参数指定的介质数据存储路径不存在时,如果该路径的上层目录已存在且属主是数据库安装用户,Roach工具会自动创建该路径且路径属主是数据库安装用户(即使用gs_preinstall执行预安装时参数-U指定的用户);--metadata-destination参数指定的元数据路径和--media-destination参数指定的介质数据存储路径是已存在路径时,需要确保该路径的属主是数据库安装用户(即使用gs_preinstall执行预安装时参数-U指定的用户)。
各参数配置原则如表1所示。
表1 参数配置原则 参数名
配置说明
举例
--master-port
该参数用于指定Roach主代理所在主机的端口,用于Roach进程在主代理主机和其他代理主机间通信。该参数仅需配置一个无业务冲突的端口即可。
说明:集群中执行Roach命令的主机被认为是主代理。
6000
--media-type
该参数用于指定本次备份的介质。
取值范围为:
- DISK
- NBU
- OBS
DISK
--media-destination
该参数用于指定本次备份的数据存储路径。
建议将media destination和metadata destination设为不同路径。这样,即使backup key被删除,元数据信息也不会丢失。
说明:mediadata是指集群中存储的业务数据,也就是数据库文件。
/home/userA/media
--metadata-destination
该参数用于指定本次备份的元数据存储路径。
建议将media destination和metadata destination设为不同路径。这样,即使backup key被删除,元数据信息也不会丢失。
说明:metadata是指Roach在备份恢复操作中收集的配置管理类数据,也叫元数据。例如:集群节点个数、节点配置信息;数据库表个数、表的存储路径、表定义等。
/home/userA/metadata
--prior-backup-key
该参数用于指定本次增量备份的基线备份信息。
每次备份成功后都会生成一个以时间戳命名的备份文件夹,该时间戳(文件夹名称)就是backup key。
20170313_131629
--archivelog
该参数在需要备份archive log时使用。
说明:如要进行恢复到时间点,备份时必须要指定此参数备份archive log。
--archivelog
例如:
python GaussRoach.py -t backup --master-port 6000 --media-destination /home/userA/backup --media-type Disk --metadata-destination /home/userA/metadata --prior-backup-key 20170313_131629
运行Roach主代理的屏幕上显示如下信息:
Parsing the configuration file. Performing presetup activities... lfgp000801493 : ##################################################100% lfgp000801494 : ##################################################100% lfgp000801495 : ##################################################100% Successfully backup data, backup key: 20180717_112418, takes time: 00:00:34. Performing post backup cleanup activities... Cleanup completed
说明:- 同时指定-t backup选项和--prior-backup-key参数执行增量备份操作,否则将进行全量备份。有关详细信息,请参见备份命令章节。
- 如果是终端断连引起Roach备份恢复异常退出,用户可再次执行备份恢复,此时建议用户在后台执行备份恢复操作。
「喜欢这篇文章,您的关注和赞赏是给作者最好的鼓励」关注作者【版权声明】本文为墨天轮用户原创内容,转载时必须标注文章的来源(墨天轮),文章链接,文章作者等基本信息,否则作者和墨天轮有权追究责任。如果您发现墨天轮中有涉嫌抄袭或者侵权的内容,欢迎发送邮件至:contact@modb.pro进行举报,并提供相关证据,一经查实,墨天轮将立刻删除相关内容。评论
- 查看集群状态是否是Normal。