应该是机器 ip 保持一致了吧？只要 ip 保持一致应该就是可以的
对，是一致的
那IP不一致的情况，我实测就会删除数据，这种IP不一致的情况该怎么做呢？
我们重新又做了尝试：
预置条件：
- 机器/集群A和机器/集群B IP不一致
- 节点及数据完全一致
结论：
-
用docker-compose的部署方式，单机4节点，数据不会丢失，正常启动
-
使用 Kubectl 部署 NebulaGraph 集群，单机单节点x4，启动的时候数据会被删除
会不会是NebulaGraph Operator的问题？
docker-compose的部署方式也是将快照恢复到了新集群？然后还正常起来了？
docker-compose的部署方式,把数据数据复制过去，以docker-compose的部署方式启动新集群没有问题，正常启动，数据也还在
将Kubectl 部署 NebulaGraph 集群数据迁移到docker-compose的部署方式，启动时数据不会删除，但是会出现Heartbeat failed, status:Machine not existed!，用了add hosts ip:port 后删除数据
将Kubectl 部署 NebulaGraph 集群数据迁移到docker-compose的部署方式
- 节点一致
- IP不同
- 数据一致
- Kubectl的nebula版本为2.6.2
- docker-compose的nebula版本为3.3
- docker-compose.yaml https://github.com/vesoft-inc/nebula-docker-compose/blob/master/docker-compose.yaml
结果
nebula-storaged.ERROR
E20221226 02:14:33.599078 1 MetaClient.cpp:112] Heartbeat failed, status:Machine not existed!
E20221226 02:14:51.630936 1 MetaClient.cpp:112] Heartbeat failed, status:Machine not existed!
核心问题应该在于，只要使用和快照中保存的 ip 一致的 ip 就可以正常启动，否则就会删数据，就算不删启动起来也是不能用的。和 docker kubectl 关系就算有也是间接的。
用这个接口确实可以试试，但不保证一定能行，因为这个接口当初目的不是对外提供的，也不怎么维护。br 工具是可以的。
目前维护的数据迁移工具有吗？我看br不支持3.0以下的
所以在你的场景下，是不支持原地升级吗？
目前来说是不支持的，现在线上是2.6正在运行，我们不知道直接原地升级到3.3后
- 原地升级会不会有问题
- 升级后的服务也需要对应升级，
- 2.6到3.3的相关兼容性问题
所以我们是打算单独部署一个3.3用来过渡测试，然后没问题了后再去升级线上服务
您说的原地升级就是用kubectl直接拉3.3的镜像，然后先启动meta，然后启动剩下的服务去完成升级吗？
嗯，我说的原地升级就是在原有线上服务直接升级；这样的确会影响线上，那可能就只能：
- 使用新的环境，但保持机器拓扑和 IP 都一样（可以用 k8s 模拟）
- 使用快照+replace 接口替换 host，但暂时不太推荐。
- 使用 br（但只支持 3.x)
1 个赞
此话题已在最后回复的 7 天后被自动关闭。不再允许新回复。