常见问题 FAQGraph
本文列出了使用NebulaGraph 2.6.0 时可能遇到的常见问题,用户可以使用文档中心或者浏览器的搜索功能查找相应问题。
如果按照文中的建议无法解决问题,请到Graph。
关于本手册Graph
为什么手册示例和系统行为不一致?Graph
NebulaGraph一直在持续开发,功能或操作的行为可能会有变化,如果发现不一致,请提交Graph通知NebulaGraph团队。
Note
如果发现本文档中的错误:
- 用户可以点击页面顶部右上角的"铅笔"图标进入编辑页面。
- 使用 Markdown 修改文档。完成后点击页面底部的 "Commit changes",这会触发一个 GitHub pull request。
- 完成Graph,并且至少2位reviewer审核通过即可合并。
关于历史兼容性Graph
X
版本兼容性
NebulaGraph 2.6.0 与 历史版本 (包括 NebulaGraph 1.x 和 2.0-RC) 的数据格式、客户端通信协议均双向不兼容。 数据格式升级参见Graph。 客户端与工具均需要Graph。
Y
版本兼容性
Neubla Graph 2.6.0 与 NebulaGraph 2.0 的数据格式兼容,客户端不兼容。
关于执行Graph
为什么NebulaGraph 2.6.0的返回结果每行之间没有横线分隔了?Graph
这是Nebula Console 2.6.0版本的变动造成的,不是NebulaGraph内核的变更,不影响返回数据本身的内容。
关于悬挂边Graph
悬挂边 (Dangling edge) 是指一条边的起点或者终点在数据库中不存在。
NebulaGraph 2.6.0 的数据模型中,允许存在"悬挂边";也没有 openCypher 中的 MERGE 语句。对于悬挂边的保证完全依赖应用层面。详见Graph。
如何处理错误信息 [ERROR (-1005)]: Used memory hits the high watermark(0.800000) of total system memory.
Graph
报错原因:NebulaGraph的system_memory_high_watermark_ratio
参数指定了内存高水位报警机制的触发阈值,默认为0.8
。系统内存占用率高于该值会触发报警机制,NebulaGraph会停止接受查询。
解决方案:
- 清理系统内存,使其降低到阈值以下。
-
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
报错原因通常为Graph服务向Storage服务请求了过多的数据,导致Storage服务超时。请尝试以下解决方案:
- Graph: 在
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
Graph
已知问题,通常需要重试 1-N 次(N==partition数量)。原因为 meta client 更新leader缓存需要1-2个心跳或者通过错误触发强制更新。
返回消息中 time spent
的含义是什么?Graph
将命令SHOW SPACES
返回的消息作为示例:
nebula> SHOW SPACES;
+--------------------+
| Name |
+--------------------+
| "basketballplayer" |
+--------------------+
Got 1 rows (time spent 1235/1934 us)
- 第一个数字
1235
表示数据库本身执行该命令花费的时间,即查询引擎从客户端接收到一个查询,然后从存储服务器获取数据并执行一系列计算所花费的时间。
- 第二个数字
1934
表示从客户端角度看所花费的时间,即从客户端发送请求、接收结果,然后在屏幕上显示结果所花费的时间。
可以在CREATE SPACE
时设置replica_factor
为偶数(例如设置为2)吗?Graph
不要这样设置。
Storage 服务使用 Raft 协议(多数表决),为保证可用性,要求出故障的副本数量不能达到一半。
当机器数量为1时,replica_factor
只能设置为1
。
当机器数量足够时,如果replica_factor=2
,当其中一个副本故障时,就会导致系统无法正常工作;如果replica_factor=4
,只能有一个副本可以出现故障,这和replica_factor=3
是一样。以此类推,所以replica_factor
设置为奇数即可。
建议在生产环境中设置replica_factor=3
,测试环境中设置replica_factor=1
,不要使用偶数。
是否支持停止或者中断慢查询Graph
支持。
详情请参见Graph。
使用GO
和MATCH
执行相同语义的查询,查询结果为什么不同?Graph
原因可能有以下几种:
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
语句少。
关于路径的详细说明,请参见Graph。
如何处理错误信息[ERROR (-7)]: SyntaxError: syntax error near
?Graph
大部分情况下,查询语句需要有YIELD
或RETURN
,请检查查询语句是否包含。
如何统计每种Tag有多少个点,每个Edge type有多少条边?Graph
请参见Graph。
如何获取每种Tag的所有点,或者每种Edge type的所有边?Graph
-
建立并重建索引。
> CREATE TAG INDEX i_player ON player(); > REBUILD TAG INDEX i_player;
-
使用
LOOKUP
或MATCH
语句。例如:> LOOKUP ON player; > MATCH (n:player) RETURN n;
更多详情请参见Graph。
如何在不指定Tag/EdgeType的情况下,获取所有的点和边?Graph
nGQL 没有该功能。
你必须先指定 Tag/EdgeType,才能获取对应类型的所有的点和边。
例如执行 MATCH (n) RETURN (n)
. 会返回错误 can’t solve the start vids from the sentence
。
一个办法是使用Graph.
或者指定各Tag/Edge Type,然后再自己通过 Union
拼装。
如何处理错误信息can’t solve the start vids from the sentence
Graph
查询引擎需要知道从哪些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
Graph
检查输入的VID类型是否是create space
设置的INT64
或FIXED_STRING(N)
。详情请参见Graph。
如何处理错误信息The VID must be a 64-bit integer or a string fitting space vertex id length limit.
Graph
检查输入的VID是否超过限制长度。详情请参见Graph。
如何处理错误信息 edge conflict
或 vertex conflict
Graph
Storage服务在毫秒级时间内多次收到插入或者更新同一点或边的请求时,可能返回该错误。请稍后重试。
如何处理错误信息 RPC failure in MetaClient: Connection refused
Graph
报错原因通常为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
Graph
报错原因可能是查询的数据量比较大,storaged 处理超时。请尝试以下解决方法:
- 导入数据时,手动Graph,加速读的速度。
- 增加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!
Graph
报错的原因可能是用户修改了 metad 的 ip 或者端口信息,或者 storage 之前加入过其他集群。请尝试以下解决方法:
用户到storage部署的机器所在的安装目录(默认安装目录为 /usr/local/nebula
)下面将cluster.id
文件删除,然后重启 storaged 服务。
能不能用中文字符做标识符,比如图空间、Tag、Edge type、属性、索引的名称?Graph
不能。
图空间、Tag、Edge type、属性以及索引的名称都需由大小写英文字母、数字或下划线组成,暂不支持使用中文字符。
同时,上述标识符区分大小写,且不可使用Graph 。
获取指定点的出度(或者入度)?Graph
一个点的“出度”是指从该点出发的“边”的条数。入度,是指指向该点的边的条数。
nebula > MATCH (s)-[e]->() WHERE id(s) == "given" RETURN count(e); #出度
nebula > MATCH (s)<-[e]-() WHERE id(s) == "given" RETURN count(e); #入度
是否有办法快速获取“所有”点的出度和入度?Graph
没有直接命令。
可以使用 Graph。
[ERROR (-1005)]: Schema not exist: xxxGraph
查询时提示Schema not exist
,请确认:
- Schema中是否存在该Tag或Edge type。
- Tag或Edge type的名称是否为关键字,如果是关键字,请使用反引号(`)将它们括起来。详情请参见Graph。
关于运维Graph
日志文件过大时如何回收日志?Graph
NebulaGraph 的日志默认在 /usr/local/nebula/logs/
下, 正常INFO级别日志文件为 nebula-graphd.INFO, nebula-storaged.INFO, nebula-metad.INFO
,报警和错误级别后缀为 .WARNING
和 .ERROR
。
NebulaGraph使用 Graph。
如何查看NebulaGraph版本Graph
服务运行时: nebula-console
中执行命令 SHOW HOSTS META
,详见Graph
服务未运行时: 在安装路径的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部署的NebulaGraph版本,方式和编译安装类似,只是要先进入容器内部,示例命令如下:
docker exec -it nebula-docker-compose_graphd_1 bash cd bin/ ./nebula-graphd --version
-
RPM/DEB包安装
执行
rpm -qa |grep nebula
即可查看版本。
如何扩缩容Graph
NebulaGraph 2.6.0 未提供运维命令以实现自动扩缩容,参考以下步骤:
-
metad 的扩容和缩容: metad 不支持扩缩容,也不支持迁移到新机器,也不要增加新的 metad 进程。
Note
用户可以使用Graph迁移meta服务,但是需要自行修改Graph服务和Storage服务的配置文件中的Meta设置。
- graphd 的缩容: 将该graphd 的 ip 从 client 的代码中移除,关闭该 graphd 进程。
- graphd 的扩容: 在新机器上准备 graphd 二进制文件和配置文件,在配置文件中修改或增加已在运行的 metad 地址,启动 graphd 进程。
- storaged 的缩容:(副本数都必须大于1),参考Graph。完成后关闭 storaged 进程。
- storaged 的扩容:(副本数都必须大于1) 在新机器上准备 storaged 二进制文件和配置文件,在配置文件中修改或增加已在运行的 metad 地址,启动 storaged 进程。
storaged扩缩容之后,还需要运行Graph。
修改Host名称后,旧的Host一直显示 OFFLINE
怎么办?Graph
OFFLINE
状态的 Host 将在一天后自动删除。
关于连接Graph
防火墙中需要开放哪些端口Graph
如果没有修改过Graph中预设的端口,请在防火墙中开放如下端口:
服务类型 | 端口 |
---|---|
Meta | 9559, 9560, 19559, 19560 |
Graph | 9669, 19669, 19670 |
Storage | 9777 ~ 9780, 19779, 19780 |
如果修改过配置文件中预设的端口,请找出实际使用的端口并在防火墙中开放它们。
周边工具各自使用不用的端口,请参考各工具文档。
如何测试端口是否已开放Graph
用户可以使用如下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