常见问题和已知缺陷

本文档列出了 Nebula Graph v1.2 常见问题和一些已知缺陷的 workaround 方法。 底层概念、最佳实践、功能对比、性能评测等见附录知识库各文章。 如果您没有在文档中找到需要的信息,请尝试在 Nebula Graph 官方论坛中的用户问答分类下进行搜索。

参数和配置

查询返回时间解释

nebula> GO FROM 101 OVER follow;
===============
| follow._dst |
===============
| 100         |
---------------
| 102         |
---------------
| 125         |
---------------
Got 3 rows (Time spent: 7431/10406 us)

以上述查询为例,Time spent 中前一个数字 7431 为数据库本身所花费的时间,即 query engine 从 console 收到这条查询语句,到存储拿到数据,并进行一系列计算所花的时间;后一个数字 10406 是从客户端角度看花费的时间,即 console 从发送请求,到收到响应,并将结果输出到屏幕的时间。大量数据的屏幕输出是一个非常慢的过程。

如何查看二进制版本信息

  • /usr/local/nebula/bin/nebula-graphd --version
  • curl http://ip:port/status

例如

curl http://192.168.8.40:11000/status
curl http://192.168.8.40:12000/status
curl http://192.168.8.40:13000/status

一个集群内,不要安装版本不一致的二进制包,会导致未知错误。

软硬件要求

详细参考运行配置要求

是否支持 HDD 硬盘

可正常运行的硬盘要求为 SSD。在 HDD 上运行需要经过代码和参数改造,不推荐使用。有特别需求也可联系 info@vesoft.com。

参数配置

Nebula Graph 的配置机制较为复杂,简单的说有两种方式:读取本地配置文件,或者通过命令行控制。为避免错误,两者只可选其一,不要混合使用

本地配置文件 (适合新用户)

配置文件默认在 /usr/local/nebula/etc/ 下。

在三个配置文件中都加上一行 --local-config=true,这样程序启动时将只依赖于配置文件。

详细参数项见:graphd 参数storaged 参数

命令行控制调整参数(适合高级用户)

在console 中运行如下命令。

nebula> SHOW CONFIGS;

命令行控制较为繁杂,容易有疏漏。推荐新用户从本地配置文件开始。

详细操作见:配置参考配置说明CONFIGS 语法

IP 与域名

  • 本机 IP127.0.0.1

graphd, storaged 三个配置文件中的 IP 参数都需要填写实际 IP。并且只通过该 IP 访问,即使本机也不要通过 127.0.0.1 访问(会被认为是两个不同的地址)。

  • 不支持通过域名访问
  • 可以在所有的 graphd 之前架设 VIP 来做负载均衡

什么是 compact

compact 的主要目的是通过重新组织硬盘上的文件结构,从“写优先”的文件格式,变成“读优先”的文件格式。具体解释见详细介绍

partition 分布不均

partition 分布不均会导致部分主机压力过大,参考这里

日志和更改日志级别

日志文件默认在 /usr/local/nebula/logs/ 下。一般设置 v=0, 调试时可以设置为 v=4。详细参数项见:graphd 参数storaged 参数

参见 graphd 日志storaged 日志

使用多块硬盘

修改 /usr/local/nebula/etc/nebula-storage.conf。例如

--data_path=/disk1/storage/,/disk2/storage/,/disk3/storage/

多块硬盘时可以逗号分隔多个目录,每个目录对应一个 RocksDB 实例,以有更好的并发能力。参考这里

数据迁移

如需将已部署完毕的数据导入至新的机器,且原机器不再使用,请将原机器 Storage 服务 data_path 目录下的底层数据复制到新机器。运行以下命令更新 Storage 服务:

curl "http:/new_meta/replace?from=old_storage&to=new_storage"

其中,new_meta 为新机器 Storage 服务对应的 Meta 服务的 IP 和端口号。old_storage 为旧机器 Storage 服务的 IP 和端口号。new_storage 为新机器 Storage 服务的 IP 和端口号。例如:

curl "http://33.33.33.33:11000/replace?from=44.44.44.44:5000&to=55.55.55.55:6000"

如果有多个 Meta 服务,curl 命令需发至 Meta 服务的 leader。

常见错误排查

连接失败,报错 Connection refused

E1121 04:49:34.563858   256 GraphClient.cpp:54] Thrift rpc call failed: AsyncSocketException: connect failed, type = Socket not open, errno = 111 (Connection refused): Connection refused
  • 请确保以下端口可用,且未被防火墙阻止。
服务名称 端口号
Meta 服务 45500, 11000 - 11002
Storage 服务 44500, 12000 - 12002
Graph 服务 3699, 13000 - 13002

运行以下命令查看端口是否可用:

$ telnet $ip $port

如果您更改了端口的默认值(/usr/local/nebula/etc/),请重新启动服务。

  • 检查服务是否存在
$ /usr/local/nebula/scripts/nebula.service status all

进程未启动或者 crash

  • 检查硬盘空间 df -h

查看当前磁盘的使用情况。默认数据存储路径为 /usr/local/nebula/storage/,也可以在 nebula-storaged.conf 中修改 --data_path 项。

  • 检查内存是否足够 dmesg | grep nebula

使用过多内存,被系统杀掉,通过 dmesg(或者 /var/log/messages/ 查看是否有 OOM 的记录,记录是否有 nebula 关键字。

  • 检查日志,在 /usr/local/nebula/logs/

发生 storaged OOM

  1. 检查资源规划是否足够,详细参考运行配置要求
  2. /usr/local/nebula/etc/nebula-storaged.conf 中设置 --enable_partitioned_index_filter=true--local-config=true
  3. 检查 partition 分布。
  4. 设置读取截断参数。只返回部分数据。
  5. 恢复 storaged 进程后,还需重启 graphd。

已知缺陷:storaged 发生重启后,需要将 graphd 也重启

否则后续每个请求会失败若干次(最大不超过 partition 数量)。

其原因是: storaged 重启导致的 partition leader 切换,而 graphd 无法自动感知该切换,需通过重启 graphd 以更新 leader 分布信息。

发生 graphd OOM

通常情况为单个查询过大。由于 Nebula Graph 的设计是每一个查询只会由一个 graphd 处理,并从多个 storaged 获取数据。 因此,当发生大查询(例如,很深的路径探索,或者返回极大量的数据)时,graphd 可能会发生 OOM。

主机先后加入过两个不同集群 (wrong cluster)

同一台主机先后用于单机测试和集群测试,storaged 服务无法正常启动(终端上显示的 storaged 服务的监听端口为红色)。查看 storaged 服务的日志(/usr/local/nebula/nebula-storaged.ERROR),若发现 "wrong cluster" 的报错信息,则可能的出错原因是单机测试和集群测试时的 Nebula Graph 生成的 cluster id 不一致,需要删除 Nebula Graph 安装目录(/usr/local/nebula)下的 cluster.id 文件和 data 目录,然后重启服务。

Could not create logging file:... Too many open files

  1. 检查硬盘空间 df -h
  2. 修改允许打开的最大文件数 ulimit -n 100000

使用 CentOS 6.5 Nebula 服务失败

在 CentOS 6.5 部署 Nebula Graph 失败,报错信息如下:

# storage 日志
Heartbeat failed, status:RPC failure in MetaClient: N6apache6thrift9transport19TTransportExceptionE: AsyncSocketException: connect failed, type = Socket not open, errno = 111 (Connection refused): Connection refused

# meta 日志
Log line format: [IWEF]mmdd hh:mm:ss.uuuuuu threadid file:line] msg
E0415 22:32:38.944437 15532 AsyncServerSocket.cpp:762] failed to set SO_REUSEPORT on async server socket Protocol not available
E0415 22:32:38.945001 15510 ThriftServer.cpp:440] Got an exception while setting up the server: 92failed to bind to async server socket: [::]:0: Protocol not available
E0415 22:32:38.945057 15510 RaftexService.cpp:90] Setup the Raftex Service failed, error: 92failed to bind to async server socket: [::]:0: Protocol not available
E0415 22:32:38.949586 15463 NebulaStore.cpp:47] Start the raft service failed
E0415 22:32:38.949597 15463 MetaDaemon.cpp:88] Nebula store init failed
E0415 22:32:38.949796 15463 MetaDaemon.cpp:215] Init kv failed!

此时服务状态为:

[root@redhat6 scripts]# ./nebula.service status  all
[INFO] nebula-metad: Exited
[INFO] nebula-graphd: Exited
[INFO] nebula-storaged: Running as 15547, Listening on 44500

出错原因:CentOS 6.5 系统内核版本为 2.6.32,SO_REUSEPORT 仅支持 Linux 3.9 及以上版本。

将系统升级到 CentOS 7.5 问题可自行解决。

同一个主机启动了两个 storaged,并使用了相同的配置和端口

不要这样使用,会导致数据错乱

删除数据目录,重新导入数据。

存储 sst 文件是否支持拷贝给另一个图空间

storaged 所使用的 sst 文件和集群图空间是绑定的,不支持直接拷贝给一个新的图空间或者集群使用。

最佳实践和其他概念

一些其他概念和最佳实践见附录部分各文章。