这里有所有的 graph,meta 和 storage 的日志。
可以发一下:
SHOW HOSTS META;
SHOW HOSTS GRAPH;
SHOW HOSTS
么?排除一下版本不匹配的问题
E20231212 07:23:55.752447 1883 GeneratedCodeHelper.cpp:201] received invalid message from client: No version identifier... old protocol client in strict mode? sz=1195725856
E20231212 07:23:55.752662 1883 GeneratedCodeHelper.cpp:134] received invalid message from client: No version identifier... old protocol client in strict mode? sz=1195725856
E20231212 07:23:55.752686 1883 GeneratedCodeHelper.cpp:93] invalid message from client in function process
我是新装的,之前也出现过问题,后来重装了操作系统重新下载了3.6的版本,数据都是从studio录入的或者是java api录入的。
但是studio之前用的是3.5的版本,昨天才安装的3.8版本。
我是今天9:33分新增的一条边类型
进入到 metad 日志所在路径,然后 grep 一下 ‘Create Edge’,看看边的 id 是什么
# 示例
cd logs
grep 'Create Edge' nebula-metad.*
难道每个月边的id会重置成39?
你们有没有脚本,会自动还原 meta 的数据目录?
从日志上看,创建了 2 个 dtc_info_config_ref_fault 的边,正常来说,是创建不成功的。
但是你创建成功了,然后 id 又变回了 39,所以检查一下是不是 metad 的 data 被还原过?
另外,你们是几个 metad 服务?
我们没有还原meta的脚本,也不知如何还原
目前这个图数据库有两个space,一个TEST一个UAT,所有可能是相同的边类型被创建了两次
我们目前是单机模式,就一个meta,运行在阿里云的ECS里面
这个环境是11月末刚刚重装系统后装的,我看了阿里云的操作记录,没有重启过,也没有装过任何的运维脚本
你应该是有 2 个 space,space A 建完 schema 以后,通过
create space B as A
的方式创建了 space B,然后再 space B 上新建 edge type 后,出了问题。
如果是这个原因的话,把 space B 删了,需要重新建 schema
我指的是阿里云ECS的snapshot,因为出了问题,现在每天都给ECS建快照
原来如此,不过我感觉 volume level 的 snapshot 有可能引入 conflict,如果 snapshot 对于所有文件不能做到是真的同一个时刻的话
这个我有点忘了,请问应该怎么查日志确认是否执行了“create space B as A”
nebula-metad.iZuf68j5ei93s92673e81gZ.root.log.INFO.20231128-103144.52430:I20231128 10:40:18.787379 52623 CreateSpaceAsProcessor.cpp:103] Created space KGDI-UAT
因为现在问题已经出现了,请教下接下来的解决方案是不是只能重装图数据库和重新导入数据了?
现在边类型的id已经是39了,任何新建的边类型都会把老的覆盖到(关键是覆盖不完整,新建同名的会说已存在)