利用 snapshot 进行集群迁移

利用 snapshot 进行集群迁移

Nebula Graph 提供快照(snapshot)功能,用于保存集群当前时间点的数据状态,当出现数据丢失或误操作时,可以通过快照恢复数据。

那是否可以通过 snapshot 进行数据迁移呢?本文就为大家带来利用 snapshot 进行集群迁移的实践。

前置条件

源集群与新集群同构(节点数量,磁盘数量,数据目录一致)

新集群 Nebula 已部署(无需启动服务)

本次实操以三节点集群为例:源集群(192.168.8.191,192.168.8.192,192.168.8.193)、新集群(192.168.8.91,192.168.8.92,192.168.8.93)。

操作步骤

在源集群创建 snapshot

(root@nebula) [(none)]> CREATE SNAPSHOT;
Execution succeeded (Time spent: 5.1133/5.11391 s)

Tue Nov 30 04:05:08 2021

(root@nebula) [(none)]> SHOW SNAPSHOTS;
=========================================================================================================
| Name                         | Status | Hosts                                                         |
=========================================================================================================
| SNAPSHOT_2021_11_30_04_05_03 | VALID  | 192.168.8.191:44500, 192.168.8.192:44500, 192.168.8.193:44500 |
---------------------------------------------------------------------------------------------------------
Got 1 rows (Time spent: 1.24/1.875 ms)

Tue Nov 30 04:05:34 2021

拷贝文件

# 拷贝 meta 文件
-- ⚠️snapshot 只会在 meta leader 节点生成 checkpoints 目录,这里是 192.168.8.191,需要拷贝至新集群所有 meta 节点
-- 在 192.168.8.91,92,93 执行以下命令
$ cd /usr/local/nebula/data/meta/nebula/0/
$ sudo scp -r vesoft@192.168.8.191:/usr/local/nebula/data/meta/nebula/0/checkpoints/SNAPSHOT_2021_11_30_04_05_03/* ./

# 拷贝 storage 文件
-- ⚠️目录中 14 为对应 space 的 ID,192.168.8.191,192,193 -> 192.168.8.91,92,93 一对一拷贝
-- 192.168.8.91
$ cd /usr/local/nebula/data/storage/nebula/
$ sudo mkdir 14
$ cd 14
$ sudo scp -r vesoft@192.168.8.191:/usr/local/nebula/data/storage/nebula/14/checkpoints/SNAPSHOT_2021_11_30_04_05_03/* ./

-- 192.168.8.92
$ cd /usr/local/nebula/data/storage/nebula/
$ sudo mkdir 14
$ cd 14
$ sudo scp -r vesoft@192.168.8.192:/usr/local/nebula/data/storage/nebula/14/checkpoints/SNAPSHOT_2021_11_30_04_05_03/* ./

-- 192.168.8.93
$ cd /usr/local/nebula/data/storage/nebula/
$ sudo mkdir 14
$ cd 14
$ sudo scp -r vesoft@192.168.8.193:/usr/local/nebula/data/storage/nebula/14/checkpoints/SNAPSHOT_2021_11_30_04_05_03/* ./

新集群启动 meta 和 graph 服务

$ sudo /usr/local/nebula/scripts/nebula.service start metad
$ sudo /usr/local/nebula/scripts/nebula.service start graphd

查看新集群 meta leader 节点

# 查看 meta 日志,如果看到“The partition is elected as the leader”说明改节点为 leader
$ grep "leader" /usr/local/nebula/logs/nebula-metad.INFO
I1130 08:45:48.413197 26299 RaftPart.cpp:1179] [Port: 45501, Space: 0, Part: 0] The partition is elected as the leader

修改 meta 信息

# 192.168.8.92 为上一步查到的 meta leader 节点,from 和 to 参数分别对应源 IP 和目标 IP。如果返回“Replace Host successfully”即为成功。
-- ⚠️这里使用的是 1.2 版本,http 端口为 11000,如果是 2.x 版本端口为 19559
curl -G "http://192.168.8.92:11000/replace?from=192.168.8.191&to=192.168.8.91"
curl -G "http://192.168.8.92:11000/replace?from=192.168.8.192&to=192.168.8.92"
curl -G "http://192.168.8.92:11000/replace?from=192.168.8.193&to=192.168.8.93"

新集群启动 storage 服务

$ sudo /usr/local/nebula/scripts/nebula.service start storaged

检查服务是否正常

# show hosts 查看服务和 partition 分布
(root@nebula) [basketballplayer]> show hosts;
==================================================================================================
| Ip            | Port  | Status  | Leader count | Leader distribution  | Partition distribution |
==================================================================================================
| 192.168.8.91  | 44500 | online  | 30           | basketballplayer: 30 | basketballplayer: 30   |
--------------------------------------------------------------------------------------------------
| 192.168.8.92  | 44500 | online  | 0            |                      | basketballplayer: 30   |
--------------------------------------------------------------------------------------------------
| 192.168.8.93  | 44500 | online  | 0            |                      | basketballplayer: 30   |
--------------------------------------------------------------------------------------------------
| Total         |       |         | 30           | basketballplayer: 30 | basketballplayer: 90   |
--------------------------------------------------------------------------------------------------
Got 8 rows (Time spent: 1.298/2.199 ms)

Tue Nov 30 09:09:58 2021

# 如果 leader 分布不均匀,手工 balance
(root@nebula) [basketballplayer]> balance leader;
Execution succeeded (Time spent: 5.02013/5.0213 s)

Tue Nov 30 09:13:31 2021

# 检查业务数据
(root@nebula) [basketballplayer]> fetch prop on player 100;
=======================================
| VertexID | player.name | player.age |
=======================================
| 100      | Tim Duncan  | 42         |
---------------------------------------
Got 1 rows (Time spent: 9.689/10.488 ms)

Tue Nov 30 09:09:55 2021

以上便是实操的全部过程。最后提醒下各位,Nebula Graph 的身份认证功能默认是关闭的,此时任何用户都能使用快照功能。如果身份认证开启,仅 God 角色用户可以使用快照功能。


交流图数据库技术?加入 Nebula 交流群请先填写下你的 Nebula 名片,Nebula 小助手会拉你进群~~


这是一个从 https://nebula-graph.com.cn/posts/use-snapshot-to-migrate-cluster/ 下的原始话题分离的讨论话题
1 个赞

大佬,你好,我也是想按照此方法进行集群迁移。但是失败?
nebula 版本:2.0.1
源服务器:192.168.2.181、192.168.2.184、192.168.26.123
新服务器:192.168.2.183、192.168.20.45、192.168.26.75
拷贝meta与storage目录下的SNAPSHOT_xxx之后,启动失败?

所有服务都启动失败吗?有报错信息吗?日志看看呢。

metad-stderr.log

F0420 10:42:11.984426 27759 RocksEngine.cpp:116] Check failed: status.ok() Corruption: Can’t access /000057.sst: IO error: No such file or directorywhile stat a file for size: data/meta/nebula/0/data/000057.sst: No such file or directory
Can’t access /000055.sst: IO error: No such file or directorywhile stat a file for size: data/meta/nebula/0/data/000055.sst: No such file or directory
Can’t access /000053.sst: IO error: No such file or directorywhile stat a file for size: data/meta/nebula/0/data/000053.sst: No such file or directory
*** Check failure stack trace: ***
@ 0x20041bc google::LogMessage::Fail()
@ 0x2008d2d google::LogMessage::SendToLog()
@ 0x2003e8d google::LogMessage::Flush()
@ 0x20046e8 google::LogMessageFatal::~LogMessageFatal()
@ 0x12d42fd nebula::kvstore::RocksEngine::RocksEngine()
@ 0x12de9ce nebula::kvstore::NebulaStore::newEngine()
@ 0x12e606d nebula::kvstore::NebulaStore::loadPartFromDataPath()
@ 0x12e8435 nebula::kvstore::NebulaStore::init()
@ 0x1114fee initKV()
@ 0x10dd89b main
@ 0x7fbf33cf1554 __libc_start_main
@ 0x1113bad (unknown)

./data/meta/nebula/0/data/目录下000057.sst、000055.sst、000053.sst这些文件是存在的。

大佬,这个还需要磁盘数量一致?原因是什么

因为这是做了个快照,meta里面存的都是原来的信息。如果data path不一致的话会识别不到。

大佬,192.168.8.194与192.168.8.191、192.168.8.192、192.168.8.193是什么关系?192.168.8.194 为上一步查到的 meta leader 节点,这意思不应该是192.168.8.191、192.168.8.192、192.168.8.193其中一台吗?

是的,这里写错了

1 个赞

如果目标集群存在和源集群相同的图空间,且存在数据。如果要用源集群的数据覆盖目标集群,目标集群同名图库的数据是否需要清理掉?

或者更准确的说,使用快照做集群迁移,最终就是会用源集群的数据,覆盖掉目标集群,目标集群之前的meta和data都会丢失。

是的,快照就是源集群meta和data的一个备份,现在企业版有集群同步功能,可以做到不覆盖。

1 个赞

请问一下,在3.0.1版本此方法是否适用

适用的

请教一下,我对这一块不太理解,192.168.8.194应该是新集群中meta leader吧?91,92,93中的一个,假如源集群metad一台,新集群metad三台是否可行

是的,194这个调整了,之前写错了。源集群metad一台,新集群metad三台应该也是可以的,因为meta的快照数据也只是在meta leader节点上生成,然后copy到目前集群的所有meta节点的。你可以实际测试下。

2 个赞

请教一下,我在按照本方法迁移数据后,图空间数据和查询上都没有问题,但是最近我发现metad日志一直在报:Get Space SpaceId: -900374782 error: E_KEY_NOT_FOUND。storaged日志一直在报:Get parts allocation failed for spaceId -900048638, status Key not existed!。这个原因是啥呀?

什么版本,这个跟snapshot迁移本身没关系,算是个bug吧,应该是3.x版本引入的,在3.1已经修复了。

3.0.1

意思是得升级到3.1才能避免该问题是吧?

嗯,这个升级的话,直接替换二进制文件就好了,很方便的。

浙ICP备20010487号