请问创建好快照之后，如何在一个新集群里恢复快照数据呢

问答 问题
1

请问创建好快照之后，如何在一个新集群里恢复快照数据呢，，看文档上描述的很不清楚，快照文件需要复制到集群的哪个文件夹下呢

2

image
image894×406 71.8 KB
详见文档

3

创建好快照后，您可以看到快照目录中的文件结构和原始数据目录中的文件结构相同，由此可知，其实可以认为快照就是原始文件的一个备份。如果想要通过所创建的checkpoint恢复nebula集群，这里有两个建议：1，修改原始集群的配置，将data_path指向新checkpoint的目录；2，不改变集群配置，写shell脚本，用checkpoint的数据替换原始的data。如果需要复现集群数据损坏的问题，请保留原始data。

5

万分感谢，还有另外一个疑问，假如我有一个主备集群，备集群的集群组成和主集群不一致（例如主机群5台storage机器，从集群只有四台）请问这种情况下备集群能用主集群的快照数据复制主集群数据么？

6

在原则上是不可以的，需要保证主备集群的架构一致。因为主备集群的架构如果不一致的话，可能存在数据丢失的问题。举一个简单的例子，例如我们的space创建备划分为了5 partition 1 replica, 这样的话如果备集群是4个机器，那肯定会丢失一个part的数据。还可能会出现其它适配的问题。所以建议在恢复的过程中要确保主备集群架构一致。

8

好的，感谢，我们的初衷是想在线下先构建好图以后再去把线下快照数据推到线上，线下机器不想完全和线上一直，这样看的话线下的集群配置得是和线上集群一样才行了

9

最好是一致的，我猜测您的业务之所以这么做，是想高效的load线上数据，对吗？ 如果数据预备集群的节点少于线上集群的节点，即使不出适配性的问题，那切换快照之后系统也会做一个存储节点间partition的Balance的操作，这个操作也会耗费系统资源。会拉低整个checkpoint切换的效率，我感觉得不偿失。

10

是的，我们预期的集群的数据量会比较大，想在线下以最高的写qps写数据，然后在不影响读性能的基础上快速的load数据到线上。近期我们会测试这种方式，有问题还会继续请教，万分感谢

11

好的，有问题随时咨询，感谢您的试用。

12

顺带问一下，对于出度很多的这种图（节点有上千出度），在查询两跳查询的时候，nebula有做优化么？例如搜索第二跳的时候分片并发

13

哈哈，有优化的，第一层优化是一般系统会把leader part分配到不同的存储节点上，所以系统发出查询请求后，所有part会并发查询；第二层优化，也就是您说的分片并发，在nebula中会分成多个bucket来并发，其实就是您的分片并发。

14

:+1:好的，了解了

15

再咨询一下，如果我把主集群里的每台机器的/data目录下的所有文件都拷贝到对应的从集群，而不是利用快照信息，这种方式是不是也可以完成数据的迁移呢

16

是的，拷贝原始data目录也是可以的。其实checkpoint的实现机制是为数据文件创建hard link，这个hard link的优势就是在相同文件系统下不会占用太多的存储空间，因此本地系统上以hard link机制创建checkpoint的话，无论是存储空间还是备份性能都有很大的优势。
在您的业务中，其实是将checkpoint 拷贝到了另一个系统中，这样的话其实和直接拷贝数据文件没有太大的区别。

1 个赞
17

另外，如果您想直接拷贝数据文件的话，需要确保一件事情，那就是在拷贝的过程中，避免源集群发生写操作。

18

是的，我在试这个功能的时候突然想到的，nebula checkpoint的机制是为了保证当前集群故障的情况下数据可以恢复到某一个时间点的情况，使用hard link确实是一个很优的选择，但是我们的需求，其实是线下构建数据推送到线上，这样的话应该是直接拷贝data目标比较合适

19

是的，我们准备再线下集群构建好图，这样是不会有写数据的，线上恢复这个图的话，也会先把集群流量摘除掉的

20

:+1:

21

试了一下直接拷贝data文件夹，从a机器拷贝到b机器，然后启动b机器的nebula后报错：
F0615 15:54:35.709440 23236 RocksEngine.cpp:95] Check failed: status.ok()
*** Check failure stack trace: ***
@ 0x11dc2cc google::LogMessage::Fail()
@ 0x11e0b52 google::LogMessage::SendToLog()
@ 0x11dbfca google::LogMessage::Flush()
@ 0x11dc7b8 google::LogMessageFatal::~LogMessageFatal()
@ 0x5e9db5 nebula::kvstore::RocksEngine::RocksEngine()
@ 0x5f1a79 nebula::kvstore::NebulaStore::newEngine()
@ 0x5f74e5 nebula::kvstore::NebulaStore::init()
@ 0x52845f nebula::storage::StorageServer::getStoreInstance()
@ 0x528bbd nebula::storage::StorageServer::start()
@ 0x4dd48d main
@ 0x7ff9f3a21d1f __libc_start_main
@ 0x5050f0 (unknown)
直接包kernel.coredump 问题了

22

看着像是meta server有问题， Heartbeat failed, status:RPC failure in MetaClient: N6apache6thrift9transport19TTransportExceptionE: AsyncSocketException: connect failed, type = Socket not open, errno = 111 (Connection refused): Connection refused
F0615 15:53:54.269345 22998 RocksEngine.cpp:95] Check failed: status.ok() 但是我看端口状态meta是起来了的