2.4

数据的备份与恢复

基础介绍以及语法规则

GBAR (Graph Backup And Restore)是用于备份和恢复数据的工具。它可以针对单个TigerGraph主机上的数据或数据字典（包括数据库纲目，加载作业和查询等）进行备份和恢复操作。在备份模式下，该工具会将数据和配置信息打包为一个单独的文件，并将其保存在本地或者远程的亚马逊S3存储桶中。我们可以针对同一份数据备份多个文件，随后，便可以通过恢复操作将系统回滚到任何一个备份时间点的状态。该工具还能够与Linux cron命令共同工作，实现自动定时备份。

当前版本的GBAR工具只能在同一台机器上备份和恢复数据。若用户需要克隆一个数据库（即在A主机上备份，在B主机上恢复），则需要联系我们的技术人员获取帮助：support@tigergraph.com

语法规则
Usage: gbar backup [options] -t <backup_tag>
       gbar restore [options] <backup_tag>
       gbar config
       gbar list
​
Options:
  -h, --help     Show this help message and exit
  -v             Run with debug info dumped
  -vv            Run with verbose debug info dumped
  -y             Run without prompt
  -t BACKUP_TAG  Tag for backup file, required on backup

“-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

GBAR Config必须在备份或恢复数据之前执行。它会在一个文本编辑器中打开下面的交互式配置模板。你可以根据注释中的解释按需修改不同参数。

Synopsis
 # Configure file for GBAR
 # you can specify storage method as either local or s3.
​
 # Assign True if you want to store backup files on local disk.
 # Assign False otherwise, in this case no need to set path.
 store_local: False
 path: PATH_TO_BACKUP_REPOSITORY
​
 # Assign True if you want to store backup files on AWS S3.
 # Assign False otherwise, in this case no need to set AWS key and bucket.
 # AWS access key and secret is optional. If not specified, it will use
 # attached IAM role of the instance.
 store_s3: False
 aws_access_key_id:
 aws_secret_access_key:
 bucket: YOUR_BUCKET_NAME
​
 # The maximum timeout value to wait for core modules(GPE/GSE) on backup.
 # As a roughly estimated number,
 # GPE & GSE backup throughoutput is about 2GB in one minute on HDD.
 # You can set this value according to your gstore size.
 # Interval string could be with format 1h2m3s, means 1 hour 2 minutes 3 seconds,
 # or 200m means 200 minutes.
 # You can set to 0 for endless waiting.
 backup_core_timeout: 5h
​
 # The number of processes to be created during compressing backup archive.
 # Compressing in parallel can gain improved performance.
 # The same number of processes will be spawned for decompression on restore.
 compress_process_number: 8
​
 # Need to put gsql user/passwd here if gsql authentication is on
 gsql_user:
 gsql_passwd:

备份

gbar backup -t <backup_tag>

该命令中的备份标签（即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保存输入消息队列。

列出备份副本 

gbar list

该命令列出了在用户配置的存储位置上现存的所有已存档备份副本。每个文件都包含一个完整标签，易读的文件大小数字以及生成时间。

数据恢复

gbar restore <archive_name>

数据恢复必须离线操作，它需要用户将数据服务暂时下线。用户必须指定备份副本的完整文件名(以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的系统中。

  • 例:

用于恢复数据的空余空间必须能够同时容纳旧的gstore和即将恢复的gstore。

一个GBAR的实际案例

接下来是一个实际案例，针对一个给定图数据库，我们给出了整个备份和恢复过程中所需要的所有命令，期望结果，消耗的时间以及空间使用情况。在这个案例中使用的是亚马逊EC2主机，其配置如下：

单个EC2实例拥有：32个vCPU + 244GB 内存 + 2TB硬盘空间

通常情况下，备份和恢复的时间会根据硬件条件的不同而变化。

GBAR 备份操作详细步骤

我们启动一个日常备份作业，备份标签为 daily 。

$ gbar backup -t daily
[23:21:46] Retrieve TigerGraph system configuration
[23:21:51] Start workgroup
[23:21:59] Snapshot GPE/GSE data
[23:33:50] Snapshot DICT data
[23:33:50] Calc checksum
[23:37:19] Compress backup data
[23:46:43] Pack backup data
[23:53:18] Put archive daily-20180607232159 to repo-local
[23:53:19] Terminate workgroup
Backup to daily-20180607232159 finished in 31m33s.

整个备份动作耗时约31分钟，生成的备份文件为49GB。GPE和GSE将数据转储到磁盘耗时约12分钟。压缩文件操作耗时约20分钟。

GBAR 恢复操作详细步骤

在开始恢复操作之前，我们必须提供副本文件的完整名称，例如daily-20180607232159。默认情况下，系统会在恢复数据前询问用户是否要继续。如果想跳过确认，可在命令中添加 “-y” 参数，此时GBAR会自动选择默认选项。

$ gbar restore daily-20180607232159
[23:57:06] Retrieve TigerGraph system configuration
GBAR restore needs to reset TigerGraph system.
Do you want to continue?(y/N):y
[23:57:13] Start workgroup
[23:57:22] Pull archive daily-20180607232159, round #1
[23:57:57] Pull archive daily-20180607232159, round #2
[00:01:00] Pull archive daily-20180607232159, round #3
[00:01:00] Unpack cluster data
[00:06:39] Decompress backup data
[00:17:32] Verify checksum
[00:18:30] gadmin stop gpe gse
[00:18:36] Snapshot DICT data
[00:18:36] Restore cluster data
[00:18:36] Restore DICT data
[00:18:36] gadmin reset
[00:19:16] gadmin start
[00:19:41] reinstall GSQL queries
[00:19:42] recompiling loading jobs
[00:20:01] Terminate workgroup
Restore from daily-20180607232159 finished in 22m55s.
Old gstore data saved under /home/tigergraph/tigergraph/gstore with suffix -20180608001836, you need to remove them manually.

在本案例中，恢复数据耗时约23分钟。其中大多数时间（约20分钟）花在了解压缩数据上。

请注意，当恢复操作结束后，GBAR会告诉你恢复之前的数据拷贝的保存的位置。如果你确认恢复动作后的数据正确，则旧的恢复前的数据拷贝可以被删除，避免占用磁盘空间。

性能总结

Previous使用gadmin工具管理Next系统维护中的常见问题

Last updated