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看到的），所以我不确定是不是跟之前用的时间有关。
要是数据量不大，可以把数据脱下敏发给我们，可以帮着看下