常见问题 FAQ

本文列出了使用Nebula Graph 2.6.1 时可能遇到的常见问题，用户可以使用文档中心或者浏览器的搜索功能查找相应问题。

如果按照文中的建议无法解决问题，请到Nebula Graph论坛提问或提交GitHub issue。

关于本手册

为什么手册示例和系统行为不一致？

Nebula Graph一直在持续开发，功能或操作的行为可能会有变化，如果发现不一致，请提交issue通知Nebula Graph团队。

Note

如果发现本文档中的错误:

1. 用户可以点击页面顶部右上角的”铅笔”图标进入编辑页面。
2. 使用 Markdown 修改文档。完成后点击页面底部的 “Commit changes”，这会触发一个 GitHub pull request。
3. 完成CLA签署，并且至少2位reviewer审核通过即可合并。

关于历史兼容性

X版本兼容性

Nebula Graph 2.6.1 与 历史版本 (包括 Nebula Graph 1.x 和 2.0-RC) 的数据格式、客户端通信协议均双向不兼容。 数据格式升级参见升级 Nebula Graph 历史版本至 v2.0.0。 客户端与工具均需要下载对应版本。

Y版本兼容性

Neubla Graph 2.6.1 与 Nebula Graph 2.0 的数据格式兼容，客户端不兼容。

关于执行

为什么Nebula Graph 2.6.0的返回结果每行之间没有横线分隔了？

这是Nebula Console 2.6.0版本的变动造成的，不是Nebula Graph内核的变更，不影响返回数据本身的内容。

关于悬挂边

悬挂边 (Dangling edge) 是指一条边的起点或者终点在数据库中不存在。

Nebula Graph 2.6.1 的数据模型中，允许存在”悬挂边”；也没有 openCypher 中的 MERGE 语句。对于悬挂边的保证完全依赖应用层面。详见INSERT VERTEX, DELETE VERTEX, INSERT EDGE, DELETE EDGE。

如何处理错误信息 [ERROR (-1005)]: Used memory hits the high watermark(0.800000) of total system memory.

报错原因：Nebula Graph的system_memory_high_watermark_ratio参数指定了内存高水位报警机制的触发阈值，默认为0.8。系统内存占用率高于该值会触发报警机制，Nebula Graph会停止接受查询。

解决方案：

• 清理系统内存，使其降低到阈值以下。

• 修改Graph配置。在所有Graph服务器的配置文件中增加system_memory_high_watermark_ratio参数，为其设置一个大于0.8的值，例如0.9。

  Note

  仅Graph服务支持system_memory_high_watermark_ratio，Storage和Meta服务不支持该参数。

如何处理错误信息 Storage Error E_RPC_FAILURE

报错原因通常为Graph服务向Storage服务请求了过多的数据，导致Storage服务超时。请尝试以下解决方案：

• 修改配置文件: 在nebula-graphd.conf文件中修改--storage_client_timeout_ms参数的值，以增加Storage client的连接超时时间。该值的单位为毫秒（ms）。例如，设置--storage_client_timeout_ms=60000。如果nebula-graphd.conf文件中未配置该参数，请手动增加。提示：请在配置文件开头添加—local_config=true再重启服务。
• 优化查询语句：减少全库扫描型的查询，无论是否用LIMIT限制了返回结果的数量；用 GO 语句改写 MATCH 语句（前者有优化，后者无优化）。
• 检查Storaged是否发生过 OOM。(dmesg |grep nebula)。
• 为 Storage 服务器提供性能更好的SSD或者内存。
• 重试请求。

如何处理错误信息 The leader has changed. Try again later

已知问题，通常需要重试 1-N 次(N==partition数量)。原因为 meta client 更新leader缓存需要1-2个心跳或者通过错误触发强制更新。

返回消息中 time spent 的含义是什么？

将命令SHOW SPACES返回的消息作为示例：

nebula> SHOW SPACES;
+--------------------+
| Name               |
+--------------------+
| "basketballplayer" |
+--------------------+
Got 1 rows (time spent 1235/1934 us)

• 第一个数字1235表示数据库本身执行该命令花费的时间，即查询引擎从客户端接收到一个查询，然后从存储服务器获取数据并执行一系列计算所花费的时间。

• 第二个数字1934表示从客户端角度看所花费的时间，即从客户端发送请求、接收结果，然后在屏幕上显示结果所花费的时间。

可以在CREATE SPACE时设置replica_factor为偶数（例如设置为2）吗？

不要这样设置。

Storage 服务使用 Raft 协议（多数表决），为保证可用性，要求出故障的副本数量不能达到一半。

当机器数量为1时，replica_factor只能设置为1。

当机器数量足够时，如果replica_factor=2，当其中一个副本故障时，就会导致系统无法正常工作；如果replica_factor=4，只能有一个副本可以出现故障，这和replica_factor=3是一样。以此类推，所以replica_factor设置为奇数即可。

建议在生产环境中设置replica_factor=3，测试环境中设置replica_factor=1，不要使用偶数。

是否支持停止或者中断慢查询

支持。

详情请参见终止查询。

使用GO和MATCH执行相同语义的查询，查询结果为什么不同？

原因可能有以下几种：

• GO查询到了悬挂边。

• RETURN 命令未指定排序方式。

• 触发了Storage服务中max_edge_returned_per_vertex定义的稠密点截断限制。

• 路径的类型不同，导致查询结果可能会不同。

  • GO语句采用的是walk类型，遍历时点和边可以重复。

  • MATCH语句兼容openCypher，采用的是trail类型，遍历时只有点可以重复，边不可以重复。

因路径类型不同导致查询结果不同的示例图和说明如下。

从点A开始查询距离5跳的点，都会查询到点C（A->B->C->D->E->C），查询6跳的点时，GO语句会查询到点D（A->B->C->D->E->C->D），因为边C->D可以重复查询，而MATCH语句查询为空，因为边不可以重复。

所以使用GO和MATCH执行相同语义的查询，可能会出现MATCH语句的查询结果比GO语句少。

关于路径的详细说明，请参见维基百科#Walk,_trail,_path)。

如何处理错误信息[ERROR (-7)]: SyntaxError: syntax error near？

大部分情况下，查询语句需要有YIELD或RETURN，请检查查询语句是否包含。

如何统计每种Tag有多少个点，每个Edge type有多少条边?

请参见show-stats。

如何获取每种Tag的所有点，或者每种Edge type的所有边?

1. 建立并重建索引。

   > CREATE TAG INDEX i_player ON player();
   > REBUILD TAG INDEX i_player;

2. 使用LOOKUP或MATCH语句。例如：

   > LOOKUP ON player;
   > MATCH (n:player) RETURN n;

更多详情请参见INDEX、LOOKUP和MATCH。

如何在不指定Tag/EdgeType的情况下，获取所有的点和边？

nGQL 没有该功能。

你必须先指定 Tag/EdgeType，才能获取对应类型的所有的点和边。

例如执行 MATCH (n) RETURN (n). 会返回错误 can’t solve the start vids from the sentence。

一个办法是使用Nebula Algorithm.

或者指定各Tag/Edge Type，然后再自己通过 Union 拼装。

如何处理错误信息can’t solve the start vids from the sentence

查询引擎需要知道从哪些VID开始图遍历。这些开始图遍历的VID，或者通过用户指定，例如：

> GO FROM ${vids} ...
> MATCH (src) WHERE id(src) == ${vids}
# 开始图遍历的VID通过如上办法指定

或者通过一个属性索引来得到，例如：

# CREATE TAG INDEX i_player ON player(name(20));
# REBUILD TAG INDEX i_player;
> LOOKUP ON player WHERE player.name == "abc" | ... YIELD ...
> MATCH (src) WHERE src.name == "abc" ...
# 通过点属性name的索引，来得到VID

否则，就会抛出这样一个异常 can’t solve the start vids from the sentence。

如何处理错误信息Wrong vertex id type: 1001

检查输入的VID类型是否是create space设置的INT64或FIXED_STRING(N)。详情请参见create space。

如何处理错误信息The VID must be a 64-bit integer or a string fitting space vertex id length limit.

检查输入的VID是否超过限制长度。详情请参见create space。

如何处理错误信息 edge conflict 或 vertex conflict

Storage服务在毫秒级时间内多次收到插入或者更新同一点或边的请求时，可能返回该错误。请稍后重试。

如何处理错误信息 RPC failure in MetaClient: Connection refused

报错原因通常为metad服务状态异常，或是metad和graphd服务所在机器网络不通。请尝试以下解决方案：

• 在metad所在服务器查看下 metad 服务状态，如果服务状态异常，可以重新启动metad服务。

• 在报错服务器下使用telnet meta-ip:port查看网络状态。

• 检查配置文件中的端口配置，如果端口号与连接时使用的不同，改用配置文件中的端口或者修改配置。

如何处理 nebula-graph.INFO 中错误日志 StorageClientBase.inl:214] Request to "x.x.x.x":9779 failed: N6apache6thrift9transport19TTransportExceptionE: Timed Out

报错原因可能是查询的数据量比较大，storaged 处理超时。请尝试以下解决方法：

• 导入数据时，手动compaction，加速读的速度。

• 增加Graph服务与Storage服务的RPC连接超时时间，在nebula-storaged.conf文件里面修改--storage_client_timeout_ms参数的值。该值的单位为毫秒（ms），默认值为60000毫秒。

如何处理 nebula-storaged.INFO 中错误日志 MetaClient.cpp:65] Heartbeat failed, status:Wrong cluster! 或者 nebula-metad.INFO 含有错误日志HBProcessor.cpp:54] Reject wrong cluster host "x.x.x.x":9771!

报错的原因可能是用户修改了 metad 的 ip 或者端口信息，或者 storage 之前加入过其他集群。请尝试以下解决方法：

用户到storage部署的机器所在的安装目录（默认安装目录为 /usr/local/nebula）下面将cluster.id文件删除，然后重启 storaged 服务。

能不能用中文字符做标识符，比如图空间、Tag、Edge type、属性、索引的名称？

不能。

图空间、Tag、Edge type、属性以及索引的名称都需由大小写英文字母、数字或下划线组成，暂不支持使用中文字符。

同时，上述标识符区分大小写，且不可使用关键字和保留字 。

获取指定点的出度（或者入度）?

一个点的“出度”是指从该点出发的“边”的条数。入度，是指指向该点的边的条数。

nebula > MATCH (s)-[e]->() WHERE id(s) == "given" RETURN count(e); #出度
nebula > MATCH (s)<-[e]-() WHERE id(s) == "given" RETURN count(e); #入度

是否有办法快速获取“所有”点的出度和入度？

没有直接命令。

可以使用 Nebula Algorithm。

[ERROR (-1005)]: Schema not exist: xxx

查询时提示Schema not exist，请确认：

• Schema中是否存在该Tag或Edge type。

• Tag或Edge type的名称是否为关键字，如果是关键字，请使用反引号（`）将它们括起来。详情请参见关键字。

关于运维

日志文件过大时如何回收日志？

Nebula Graph 的日志默认在 /usr/local/nebula/logs/ 下, 正常INFO级别日志文件为 nebula-graphd.INFO, nebula-storaged.INFO, nebula-metad.INFO，报警和错误级别后缀为 .WARNING 和 .ERROR。

Nebula Graph使用 glog 打印日志。glog 没有日志回收的功能，用户可以使用 crontab 设置定期任务回收日志文件，详情请参见Glog should delete old log files automatically。

如何查看Nebula Graph版本

服务运行时: nebula-console 中执行命令 SHOW HOSTS META，详见SHOW HOSTS

服务未运行时: 在安装路径的bin目录内，执行./<binary_name> --version命令，可以查看到version和GitHub上的commit ID，例如：

$ ./nebula-graphd --version
nebula-graphd version 2.5.0, Git: c397299c, Build Time: Aug 19 2021 11:20:18

• Docker Compose部署

  查看Docker Compose部署的Nebula Graph版本，方式和编译安装类似，只是要先进入容器内部，示例命令如下：

  docker exec -it nebula-docker-compose_graphd_1 bash
  cd bin/
  ./nebula-graphd --version

• RPM/DEB包安装

  执行rpm -qa |grep nebula即可查看版本。

如何扩缩容

Nebula Graph 2.6.1 未提供运维命令以实现自动扩缩容，参考以下步骤：

• metad 的扩容和缩容： metad 不支持扩缩容，也不支持迁移到新机器，也不要增加新的 metad 进程。

  Note

  用户可以使用脚本工具迁移meta服务，但是需要自行修改Graph服务和Storage服务的配置文件中的Meta设置。

• graphd 的缩容： 将该graphd 的 ip 从 client 的代码中移除，关闭该 graphd 进程。

• graphd 的扩容： 在新机器上准备 graphd 二进制文件和配置文件，在配置文件中修改或增加已在运行的 metad 地址，启动 graphd 进程。

• storaged 的缩容：（副本数都必须大于1），参考缩容命令。完成后关闭 storaged 进程。

• storaged 的扩容：（副本数都必须大于1） 在新机器上准备 storaged 二进制文件和配置文件，在配置文件中修改或增加已在运行的 metad 地址，启动 storaged 进程。

storaged扩缩容之后，还需要运行Balance Data 和 Balance Leader 命令。

修改Host名称后，旧的Host一直显示 OFFLINE 怎么办？

OFFLINE 状态的 Host 将在一天后自动删除。

关于连接

防火墙中需要开放哪些端口

如果没有修改过配置文件中预设的端口，请在防火墙中开放如下端口：

如果修改过配置文件中预设的端口，请找出实际使用的端口并在防火墙中开放它们。

周边工具各自使用不用的端口，请参考各工具文档。

如何测试端口是否已开放

用户可以使用如下telnet命令检查端口状态：

telnet <ip> <port>

Note

如果无法使用telnet命令，请先检查主机中是否安装并启动了telnet。

示例：

// 如果端口已开放：
$ telnet 192.168.1.10 9669
Trying 192.168.1.10...
Connected to 192.168.1.10.
Escape character is '^]'.
// 如果端口未开放：
$ telnet 192.168.1.10 9777
Trying 192.168.1.10...
telnet: connect to address 192.168.1.10: Connection refused

最后更新: November 3, 2021