数据的备份与恢复
基础介绍以及语法规则
GBAR (Graph Backup And Restore)是用于备份和恢复数据的工具。它可以针对单个TigerGraph主机上的数据或数据字典(包括数据库纲目,加载作业和查询等)进行备份和恢复操作。在备份模式下,该工具会将数据和配置信息打包为一个单独的文件,并将其保存在本地或者远程的亚马逊S3存储桶中。我们可以针对同一份数据备份多个文件,随后,便可以通过恢复操作将系统回滚到任何一个备份时间点的状态。该工具还能够与Linux cron命令共同工作,实现自动定时备份。
当前版本的GBAR工具只能在同一台机器上备份和恢复数据。若用户需要克隆一个数据库(即在A主机上备份,在B主机上恢复),则需要联系我们的技术人员获取帮助:support@tigergraph.com
“-y” 参数表示GBAR会自动跳过所有问题并选择默认答案。当前版本中,问题只有一个:
在恢复数据之前,GBAR总是会询问是否停止并重置TigerGraph服务: (是/否)? 默认答案为”是“。
v2.1与v2.0的变化 <a id="GBAR-GraphBackupandRestorev2.1-Changesbetweenv2.0andv2.1"></a>
配置
对于S3连接的配置而言,不再提供AWS的Access Key和Secret Key,而使用附属的IAM role。
可以规定备份和恢复进程的并行数量。
如果启用了GSQL验证,则必须输入用户名和密码。
备份
一个数据备份副本以数个文件的形式存放在一个文件夹下,而不是以单个文件保存。
改进了分布式备份动作的性能
恢复
当选择备份副本时,必须提供完整的文件名
减少了恢复数据过程中需要回答的问题:
用户必须提供备份副本的完整文件名;不再让用户从一系列备份文件中选择最新的那个。
GBAR恢复数据时不再预估解压后的数据大小,也不再检查空间是否足够。
配置
GBAR Config必须在备份或恢复数据之前执行。它会在一个文本编辑器中打开下面的交互式配置模板。你可以根据注释中的解释按需修改不同参数。
备份
该命令中的备份标签(即backup_tag)表示即将生成的备份副本的文件名前缀。完整的文件名格式为backup_tag-timestamp。它实际上是备份文件夹下的一个子文件夹。如果store_local
参数为true,则该副本存储在本地,避免了大量数据在节点间相互传输。因此,它也需要集群内的每个节点都拥有亚马逊S3存储的访问权限。如果想将IAM的策略用于用户验证,则每个节点上都必须实施该IAM策略。
GBAR备份是实时进行的,也就是说备份动作和数据库运行同时进行。当备份开始时,GBAR向gadmin发出一个请求,命令GPE组件和GSE组件对它们的数据创建快照。GPE和GSE随后将它们的数据保存到GBAR的工作目录中。GBAR同时也直接联系Dictionary组件并获取一份系统配置信息的拷贝。另外,GBAR还会记录TigerGraph系统的版本。这一切做完之后,GBAR将所有数据和配置信息压缩到一个tgz压缩包中,并将其储存到所在节点的backup_tag-timestamp 子文件夹下。最后,GBAR按照事先的配置,将该文件复制到本地存储或亚马逊S3上,并删除一切备份时产生的临时文件。
当前版本的GBAR备份工具以极快的速度在所有组件(GPE,GSE和Dictionary)上”几乎“同时生成快照,然而,我们不能完全保证快照间的一致性。所以我们强烈建议用户在启动备份操作是暂停数据库写入操作。该”无写入状态“的时间只需要5秒就足够了。
备份操作不会为Rest++或Kafka保存输入消息队列。
列出备份副本
该命令列出了在用户配置的存储位置上现存的所有已存档备份副本。每个文件都包含一个完整标签,易读的文件大小数字以及生成时间。
数据恢复
数据恢复必须离线操作,它需要用户将数据服务暂时下线。用户必须指定备份副本的完整文件名(以backup_tag-timestamp格式)。当GBAR开始一个恢复动作时,它首先存储副本的文件夹下找到对应的副本文件,随后将其解压缩到一个工作目录。然后,GBAR会将现有的TigerGraph版本与备份副本中的版本相比较,以确保副本的系统版本与现有版本兼容。接下来,GBAR会暂时关闭TigerGraph服务器的组件(例如GSE, RESTPP等),并将现有数据做个拷贝以防万一。准备动作完成后,GBAR导出副本内的数据并复制到GPE和GSE中,同时通知Dictionary组件加载所需的配置文件。最后,GBAR会重启TigerGraph服务器。
的来说,GBAR工具的设计初衷就是为了方便用户为数据和配置文件创建副本,以便未来的某个时间可以将系统回滚到之前的状态中。这其中有一个假定:备份和恢复发生在同一台主机上,且TigerGraph的文件结构没有改变。具体的要求如下所示:
恢复操作的要求和限制
在备份时的系统版本和现有系统版本之间只能有小版本的变动。
TigerGraph的版本号格式为X.Y[.Z]。其中X表示大版本,Y表示小版本。
副本文件能够用于恢复操作的前提是:与现有系统比较,两者大版本相同,且副本文件的小版本不新于现有版本。
在0.8.x版本中备份的数据不能恢复到1.x的系统中。
例:
备份副本的系统版本
现有系统版本
是否允许从该副本恢复数据?
0.8
1.0
否 - 大版本不同
1.1
1.1
是 - 大版本相同,小版本也相同
1.1
1.2
是 - 大版本相同; 现有小版本 备份文件小版本
1.1
1.0
否 - 大版本相同; 现有小版本 备份文件小版本
用于恢复数据的空余空间必须能够同时容纳旧的gstore和即将恢复的gstore。
一个GBAR的实际案例
接下来是一个实际案例,针对一个给定图数据库,我们给出了整个备份和恢复过程中所需要的所有命令,期望结果,消耗的时间以及空间使用情况。在这个案例中使用的是亚马逊EC2主机,其配置如下:
单个EC2实例拥有:32个vCPU + 244GB 内存 + 2TB硬盘空间
通常情况下,备份和恢复的时间会根据硬件条件的不同而变化。
GBAR 备份操作详细步骤
我们启动一个日常备份作业,备份标签为 daily 。
整个备份动作耗时约31分钟,生成的备份文件为49GB。GPE和GSE将数据转储到磁盘耗时约12分钟。压缩文件操作耗时约20分钟。
GBAR 恢复操作详细步骤
在开始恢复操作之前,我们必须提供副本文件的完整名称,例如daily-20180607232159。默认情况下,系统会在恢复数据前询问用户是否要继续。如果想跳过确认,可在命令中添加 “-y” 参数,此时GBAR会自动选择默认选项。
在本案例中,恢复数据耗时约23分钟。其中大多数时间(约20分钟)花在了解压缩数据上。
请注意,当恢复操作结束后,GBAR会告诉你恢复之前的数据拷贝的保存的位置。如果你确认恢复动作后的数据正确,则旧的恢复前的数据拷贝可以被删除,避免占用磁盘空间。
性能总结
GStore大小 | 备份副本大小 | 备份操作耗时 | 恢复操作耗时 |
219GB | 49GB | 31 分钟 | 23 分钟 |
Last updated