因为线上图数据库目前为单集群，数据量比较大，有以下缺点：

1. 单点风险，一旦集群崩溃或者因为某些查询拖垮整个集群，就会导致所有图操作受影响

2. 很多优化类但会影响读写的操作不好执行，比如：compact、balance leader 等；

3. 双集群在升级的时候也非常有优势，完全可以做到不影响业务运行，比如先升级备集群再升级主集群。总之为了线上数据库更加稳定和高可用需要搭建双集群。

## 选择 BR 工具的原因

目前，我这边了解到复制集群方案有：

1. 新集群重新写入数据，这种情况要么就是写程序 scan 再导入新集群（太慢了），要么就基于底表数据通过 [nebula-exchange](https://github.com/vesoft-inc/nebula-exchange) 再导入新集群（必须得有历史数据）

2. （不可靠）完整复制 nebula 数据拷贝到新集群，参考：[【复制 data 方式导入】](https://discuss.nebula-graph.com.cn/t/topic/11887)（不过，这个方式我在测试环境测试失败了）

3. 通过 [nebula-br](https://github.com/vesoft-inc/nebula-br) 备份，再还原到新集群（本文就是基于这种方式）

因为我们**线上很难回溯出完整的历史数据，无法基于底表重新构建**，此外 scan 方式又太慢了，所以选择了 BR 的方式。

**注意**：

* 本文基于测试环境搭建验证，数据量比较小，线上还未做验证，仅供参考。此外附上官方的[简单 BR 实践](https://discuss.nebula-graph.com.cn/t/topic/12569)。

* （**很重要**）使用 BR 工具备份一定要先去了解其限制，[BR 文档](https://github.com/vesoft-inc/nebula-br)

## 环境介绍

* nebula 版本：3.6.0

* nebula 安装路径：`/usr/local/nebula`

* nebula-metad 服务端口：9559 (可以通过安装目录下的 `scripts/nebula-metad status` 查看)

* backup 目录：`/usr/local/nebula_backup`

备份方式：full（全图备份，也可以指定部分 space）

* 3 台老集群机器（已经有历史数据的）：192.168.1.2、192.168.1.3、192.168.1.4

* 3 台新集群机器（没有数据，待从老集群复制数据）：192.168.2.2、192.168.2.3、192.168.2.4

备份前新集群 show hosts 情况：


备份前老集群 show hosts 情况：


## 大体步骤

1. 老集群安装 agent（每台机器都要安装）和 br（选择任何其中一台机器安装）工具；

2. 新集群安装 agent（每台机器都要安装）；

3. 在老集群安装 br 的机器上，利用 br 工具生成备份文件，备份 meta 执行老集群的 meta 地址；

4. 复制 meta 文件，老集群中只有一台机器的备份目录有 meta，需要将 meta 复制到老集群其他机器；

5. 在新集群机器创建和老集群一样的备份目录，比如：老集群备份目录为 `/usr/local/nebula_bak/BACKUP_2023_09_14_13_57_33`，新集群机器需要创建相同的目录：`/usr/local/nebula_bak/BACKUP_2023_09_14_13_57_33`；

6. 复制老集群备份文件到新集群中，这里需要注意因为老集群每台机器都有自己的备份文件，这里需要将所有的备份文件复制到新集群中整合到一起，因为每台机器的 data 下的目录名称都是以 `IP + PORT` 的形式，所以不会有重复；

7. 在老集群安装 br 的机器上，利用 br 工具恢复备份文件，恢复时 meta 指向新机器 meta 地址；

## 详细步骤

在老集群所有机器安装 agent，安装方法参考：[angent 安装介绍](https://github.com/vesoft-inc/nebula-agent)，以当前示例为例，下载 nebula-agent 之后存放在 `/usr/local/nebula/bin` 目录下, 使用 chmod +x nebula-agent 赋予可执行权限：

192.168.1.2

```

nohup ./nebula-agent -agent="192.168.1.2:9999" -debug -meta="192.168.1.2:9559" > agent.log 2>&1 &

```

192.168.1.3

```

nohup ./nebula-agent -agent="192.168.1.3:9999" -debug -meta="192.168.1.3:9559"  > agent.log 2>&1 &

```

192.168.1.4

```

nohup ./nebula-agent -agent="192.168.1.4:9999" -debug -meta="192.168.1.4:9559"  > agent.log 2>&1 &

```

下载 br 工具到 nebula 的 bin 目录下，并命名为 nebula-br，并使用 chmod 命令赋予可执行权限。

此时老集群机器拓扑图：


（老集群）选择安装 br 工具的 192.168.1.4 机器执行如下命令进行备份：

```

./nebula-br backup full --meta="192.168.1.4:9559" --storage="local:///usr/local/nebula_backup"

```

（老集群）备份后每台机器的备份目录详情如图：


（老集群）复制 meta 到其他机器的备份目录下：

这里是从 192.169.1.2（只有这台机器生成了 meta，这玩意只有在 meta 的 leader 节点生成）机器复制到 192.168.1.3 和 192.168.1.4 机器目录下：


新集群安装 agent：

192.168.2.2

```

nohup ./nebula-agent -agent="192.168.2.2:9999" -debug -meta="192.168.2.2:9559" > agent.log 2>&1 &

```

192.168.2.3

```

nohup ./nebula-agent -agent="192.168.2.3:9999" -debug -meta="192.168.2.3:9559"  > agent.log 2>&1 &

```

192.168.2.4

```

nohup ./nebula-agent -agent="192.168.2.4:9999" -debug -meta="192.168.2.4:9559"  > agent.log 2>&1 &

```

新集群服务拓扑图：


复制老集群的备份文件到新集群机器下，完成后的拓扑图：

从老集群机器 `/usr/local/nebula_backup` 拷贝数据到新集群机器 `/usr/local/nebula_backup` 目录下


(老集群) 选择安装 br 工具的 192.168.1.4 机器执行如下命令进行还原到新集群，这里的 meta 指向新集群机器其中一台 meta 地址，storage 地址为上一步新集群创建的备份地址：

```

./nebula-br restore full --meta="192.168.2.4:9559" --storage="local:///usr/local/nebula_backup" --name="BACKUP_2023_09_14_13_57_33"

```

观察日志，不报错的情况下完成了从老集群机器还原到了新集群，可使用 nebula-console 连接新集群查看 space 情况。

新集群 show hosts 情况：


## 小结

官方其实不推荐 local 模式去做备份还原，操作太过复杂，很容易出错，建议使用 S3 或者 NTF 进行挂载，这样就没必要做老集群拷贝到新集群的工作。

> 本文正在参加 NebulaGraph 技术社区年度征文活动，征文详情：[https://discuss.nebula-graph.com.cn/t/topic/13970](https://discuss.nebula-graph.com.cn/t/topic/13970)

> 如果你觉得本文对你有所启发，记得给我点个 ❤️ ，谢谢你的鼓励