YHR
1
- nebula 版本:3.2.0
- 部署方式:分布式
- 安装方式:Docker
- 是否为线上版本:Y
- 硬件信息
- 数据插入成功后,studio页面图可以查到,过了一段时间发现图查不到了,排查日志后没有发现delete相关操作,统计了一下点边总量,排查一会后再次统计点边数量,发现点边数量再次减少。目前部署了五套环境,有两套环境出现了这种问题,而且都是同一个space缺少数据,缺少的数据中只有边,点没有缺少。ttl设置的秒,graph和storage服务、机器时间经过排查都没有问题。
-ddl部分语句代码:
CREATE SPACE root_cause_analysis (partition_num = 100, replica_factor = 3, charset = utf8, collate = utf8_bin, vid_type = FIXED_STRING(128)) comment = "根因分析结果拓扑图空间""代码 / 终端输出 /
CREATE TAG ai_rca_server_tag ( name string NULL, type string NULL, alert_status bool NULL, alert_num int64 NULL, create_time timestamp NULL, is_appended bool NULL, metric_type string NULL, basic_info string NULL, incident_vid string NULL, alert_start_time timestamp NULL, alert_end_time timestamp NULL, technology_type string NULL, service_metric_type string NULL, service_id string NULL ) ttl_duration = 2592000, ttl_col = "create_time""
CREATE EDGE ai_rca_edge_tag ( type string NULL, weight int64 NULL, create_time timestamp NULL ) ttl_duration = 2592000, ttl_col = "create_time""
1 个赞
首先检查下机器时间呢,这块现在可能有问题,看你只有两套环境出现问题,如果数据一样的话,可能会有这方面的因素。
排查过时间的话,确实比较奇怪。
1 个赞
机器时间排查过了,一套环境时间一致,另一套环境5台机器,4台一致,其中一台快了3秒
稍等,我上传插入边的语句,目前看数据就是隔了一段时间丢一批,间隔时间目前没发现规律,然后被丢弃的这一批数据也没有发现用做ttl的时间也没有什么规律。还想问一下vid比较长会有影响吗?
稍等啊,我在捞这些边的插入记录。稍后上传上来,然后把最近丢的数据记录也上传上来
插入语句.txt (136.0 KB)
丢失数据详情.txt (40.9 KB)
我们在13号晚上清过一次库,然后大概晚上八九点又重新入的数据,同时将ai_rca_edge_tag 这个边的ttl改成了2593000(当时怀疑是某台机器ttl同步有问题,所以改动了这个时间,然后又清了库), ttl_col = “create_time” 这一列是我们数据写入的时间
MuYi
10
@xjc 方便的话明天安排人一起看下?这个问题我觉得还比较诡异
1 个赞
xjc
11
有没有装dashboard来监控?可以看下num_edges_deleted和num_delete_edges这两个指标,排查是否确实有主动删除。
@shanlai 请关注下是否和TTL有关系。
1 个赞
所以之前 ttl 的时间不是 2593000?那之前是多少?
- 你集群的心跳时间设置的是多少?
- 之前 ttl 时间是多少?
- 每次导入,导入时间一共是多少?
设置完 TTL 后,要等心跳 storage 才能获取到新的 ttl 设置,如果在 storage 没获取到 ttl,然后你已经导入完成,有可能还是原来的 ttl 时间过期。
(只是一个猜测,如果你导入时间很长,大于心跳的时间,那应该不是这个问题)
1 个赞
集群心跳默认值10秒
之前的ttl在帖子开头哦,是2592000
每次导入很快,几秒钟吧
MuYi
14
我昨天晚上仔细看他丢的数据,感觉和TTL没有关系,因为在2分钟的时间内,丢的数据有13号、也有14号的
MuYi
15
14号导入的数据,16号发现没有的,感觉和schema的心跳同步也没有关系
翻了下代码 需要那边确认几个事 删数据就这两个来源
- delete
- compaction
所以麻烦确认几个事
- 没有delete
- 在storage加个参数–vmodule=CompactionFilter=3 然后观察日志中是否真的有数据在compaction时候删掉
- 同事说全量数据很少,所以先不要加limit,对比数据是否有减少的情况
1 个赞
- storage配置参数里加上
--vmodule=CompactionFilter=3
重启下
- stats那个不会非常准,是基于一个快照进行统计的。如果数据很少,不加limit对比条数就行
还有一个点在于你提到的5套环境里面有两套出现这个问题,环境需要检查下NTP之类的是否在用。或者你可以试下github master的代码,最近这块把TTL的时间都统一了。
好的,我等会加一下这个参数,那么日志过滤什么关键字呢?
出现问题的环境机器时间排查过了,一套环境时间一致,另一套环境5台机器,4台一致,其中一台快了3秒
就搜CompactionFilter就行。你用的版本里,我们计算时间差是用的CPU石英震荡的那个时间戳,最新版本里都是用系统的时间了(比如date看到的),所以我不确定是不是跟之前用的时间有关。
要是数据量不大,可以把数据脱下敏发给我们,可以帮着看下