本文列出了使用Nebula Graph {{ nebula.release }} 时可能遇到的常见问题，用户可以使用文档中心或者浏览器的搜索功能查找相应问题。
如果按照文中的建议无法解决问题，请到Nebula Graph论坛提问或提交GitHub issue。
Nebula Graph一直在持续开发，功能或操作的行为可能会有变化，如果发现不一致，请提交issue通知Nebula Graph团队。
!!! note
如果发现本文档中的错误:
1. 用户可以点击页面顶部右上角的"铅笔"图标进入编辑页面。
2. 使用 Markdown 修改文档。完成后点击页面底部的 "Commit changes"，这会触发一个 GitHub pull request。
3. 完成[CLA签署](../15.contribution/how-to-contribute.md)，并且至少2位reviewer审核通过即可合并。
!!! compatibility "X版本兼容性"
Nebula Graph {{ nebula.release }} 与 历史版本 (包括 Nebula Graph 1.x 和 2.0-RC) 的数据格式、客户端通信协议均**双向不兼容**。
数据格式升级参见[升级 Nebula Graph 历史版本至 v2.0.0](../4.deployment-and-installation/3.upgrade-nebula-graph/upgrade-nebula-graph-to-250.md)。
客户端与工具均需要[下载对应版本](../20.appendix/6.eco-tool-version.md)。
!!! compatibility "Y版本兼容性"
Neubla Graph {{ nebula.release }} 与 Nebula Graph {{ nebula.base20 }} 的数据格式兼容，客户端不兼容。
悬挂边 (Dangling edge) 是指一条边的起点或者终点在数据库中不存在。
Nebula Graph {{ nebula.release }} 的数据模型中，允许存在"悬挂边"；也没有 openCypher 中的 MERGE 语句。对于悬挂边的保证完全依赖应用层面。详见INSERT VERTEX, DELETE VERTEX, INSERT EDGE, DELETE EDGE。
报错原因：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服务不支持该参数。
报错原因通常为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或者内存。
- 重试请求。
已知问题，通常需要重试 1-N 次(N==partition数量)。原因为 meta client 更新leader缓存需要1-2个心跳或者通过错误触发强制更新。
将命令SHOW SPACES返回的消息作为示例：
nebula> SHOW SPACES;
+-------------------+
| Name |
+-------------------+
| basketballplayer |
+-------------------+
Got 1 rows (time spent 1235/1934 us)
-
第一个数字
1235表示数据库本身执行该命令花费的时间，即查询引擎从客户端接收到一个查询，然后从存储服务器获取数据并执行一系列计算所花费的时间。 -
第二个数字
1934表示从客户端角度看所花费的时间，即从客户端发送请求、接收结果，然后在屏幕上显示结果所花费的时间。
不要这样设置。
Storage 服务使用 Raft 协议（多数表决），为保证可用性，要求出故障的副本数量不能达到一半。
当机器数量为1时，replica_factor只能设置为1。
当机器数量足够时，如果replica_factor=2，当其中一个副本故障时，就会导致系统无法正常工作；如果replica_factor=4，只能有一个副本可以出现故障，这和replica_factor=3是一样。以此类推，所以replica_factor设置为奇数即可。
建议在生产环境中设置replica_factor=3，测试环境中设置replica_factor=1，不要使用偶数。
支持。
详情请参见终止查询。
原因可能有以下几种：
-
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语句少。
关于路径的详细说明，请参见维基百科。
大部分情况下，查询语句需要有YIELD或RETURN，请检查查询语句是否包含。
请参见show-stats。
-
建立并重建索引。
> CREATE TAG INDEX i_player ON player(); > REBUILD TAG INDEX i_player; -
使用
LOOKUP或MATCH语句。例如：> LOOKUP ON player; > MATCH (n:player) RETURN n;
nGQL 没有该功能。
你必须先指定 Tag/EdgeType，才能获取对应类型的所有的点和边。
例如执行 MATCH (n) RETURN (n). 会返回错误 can’t solve the start vids from the sentence。
一个办法是使用Nebula Algorithm.
或者指定各Tag/Edge Type，然后再自己通过 Union 拼装。
查询引擎需要知道从哪些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。
检查输入的VID类型是否是create space设置的INT64或FIXED_STRING(N)。详情请参见create space。
检查输入的VID是否超过限制长度。详情请参见create space。
Storage服务在毫秒级时间内多次收到插入或者更新同一点或边的请求时，可能返回该错误。请稍后重试。
报错原因通常为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、属性以及索引的名称都需由大小写英文字母、数字或下划线组成，暂不支持使用中文字符。
同时，上述标识符区分大小写，且不可使用关键字和保留字 。
一个点的“出度”是指从该点出发的“边”的条数。入度，是指指向该点的边的条数。
nebula > MATCH (s)-[e]->() WHERE id(s) == "given" RETURN count(e); #出度
nebula > MATCH (s)<-[e]-() WHERE id(s) == "given" RETURN count(e); #入度
没有直接命令。
可以使用 Nebula Algorithm。
查询时提示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-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
This source code is licensed under Apache 2.0 License, attached with Common Clause Condition 1.0.-
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即可查看版本。
用户可以使用 Dashboard（企业版），在可视化页面对 graphd 和 storaged 进行快速扩缩容，详情参见 集群操作-扩缩容。
Nebula Graph {{ nebula.release }} 未提供运维命令以实现自动扩缩容，参考以下步骤：
-
metad 的扩容和缩容： metad 不支持扩缩容，也不支持迁移到新机器，也不要增加新的 metad 进程。
-
graphd 的缩容： 将该graphd 的 ip 从 client 的代码中移除，关闭该 graphd 进程。
-
graphd 的扩容： 在新机器上准备 graphd 二进制文件和配置文件，在配置文件中修改或增加已在运行的 metad 地址，启动 graphd 进程。
-
storaged 的缩容：（副本数都必须大于1），参考缩容命令。完成后关闭 storaged 进程。
-
storaged 的扩容：（副本数都必须大于1） 在新机器上准备 storaged 二进制文件和配置文件，在配置文件中修改或增加已在运行的 metad 地址，启动 storaged 进程。
storaged扩缩容之后，还需要运行Balance Data 和 Balance Leader 命令。
OFFLINE 状态的 Host 将在一天后自动删除。
如果没有修改过配置文件中预设的端口，请在防火墙中开放如下端口：
| 服务类型 | 端口 |
|---|---|
| Meta | 9559, 9560, 19559, 19560 |
| Graph | 9669, 19669, 19670 |
| Storage | 9777 ~ 9780, 19779, 19780 |
如果修改过配置文件中预设的端口，请找出实际使用的端口并在防火墙中开放它们。
周边工具各自使用不用的端口，请参考各工具文档。
用户可以使用如下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