nebula 3.2.1
报错如图，一直在打日志过一会就会把日志盘的空间打满，又重启了storage节点无法解决这个问题
日志级别是1，也就是warning
后来实在受不了了50G的日志盘过一会就打满了，而且CPU占用很高，我给他改成了3
然后CPU下去了
现在不清楚该不该调回去。。。毕竟实际使用时还是要看日志排查问题的
所以想问下原因
是几个小时么。我的建议可能只是个参考哈，你是不是可以找点便宜的机械盘存储下相关的日志，然后机器的那个日志比较实时，可能只存储一天之内的日志信息呢？
主要是想问下他一直在打同一个日志
就是spaceId99的part36一直是过期状态
这个报错有办法人工修复吗？看起来是有问题的但是不知道该如何修复
我能想到的就是删掉space后重新导数，这样可能能解决问题？但是这种代价有点高，因为数据已经在使用了
想请教下有没有其他方法
官方有大神，可以提供解决方法吗？
你的运行环境是集群还是单机？
集群的，
3 graph
3 meta
7 storage
目前是其中一个storage一直报错，通过show parts可以看到是part36的leader所在的storage一直报错
你去某个图空间 show parts 下，得到 part36 对应机器的数据，然后把这个机器的 data 数据删下，然后等待数据同步过来。
为了保证稳妥，操作之前记得先备份下数据。
1 个赞
我是3副本数据
show parts后看到在报错的节点是part36的leader
我删掉他的数据后会从另外两个从节点选主，然后同步数据给当前删数据的节点吗？
可以，你先备份下数据，能选得出来主。不过，如果你对这块不是特别了解的话，建议谨慎操作，最好不要做这个危险的操作。
再深入请教一下哈，这里清理数据是指删掉data里的space99文件夹？还是吧space99文件夹里的数据删除？两者有区别吗？
两个没有区别。如果你是三副本三节点的话，你直接拷贝其他 storage 节点的数据到有问题节点就好了。但是你是 7 节点，你就等其他节点同步数据过来好了。
此话题已在最后回复的 30 天后被自动关闭。不再允许新回复。