Skip to content


This topic lists the frequently asked questions for using Nebula Graph. You can use the search box in the help center or the search function of the browser to match the questions you are looking for.

If the solutions described in this topic cannot solve the problem, ask for help on the Nebula Graph forum or submit an issue on GitHub.

About manual updates

Why is the behavior of manual not consistent with the system?

Nebula Graph is still under development. Its behavior changes from time to time. Please tell us if the manual and the system are not consistent.

Some errors in this manula
  1. Click the pencil button at the top right side of this page.
  2. Use markdown to fix this error。Then "Commit changes" at the bottom, which will start a Github pull request.
  3. Sign the CLA. This pull request (and the fix) will be merged after to reviewer's accept.

About forward and backward compatibility

Major version compatibility

Neubla Graph master is not compatible with Nebula Graph 1.x nor 2.0-RC in both data formats and RPC-protocols, and vice versa. Check how to upgrade to Neubla Graph master. You must upgrade all clients.

Micro version compatibility

Neubla Graph master is compatible with Nebula Graph in both data formats and RPC-protocols.

About executions

How is the time spent value at the end of each return message calculated?

Take the return message of SHOW SPACES as an example:

nebula> SHOW SPACES;
| Name              |
| basketballplayer  |
Got 1 rows (time spent 1235/1934 us)
  • The first number 1235 shows the time spent by the database itself, that is, the time it takes for the query engine to receive a query from the client, fetch the data from the storage server and perform a series of calculations.
  • The second number 1934 shows the time spent from the client's perspective, that is, the time it takes for the client from sending a request, receiving a response, and displaying the result on the screen.
Can I set replica_factor as an even number in CREATE SPACE statements, e.g., replica_factor = 2?


The Storage Service garantees its availability based on the Raft consensus protocol. The number of failed replicas must not exceed half of the total replica number.

When replica_factor=2, if one replica fails, the Storage Service fails. No matter replica_factor=3 or replica_factor=4, if more than one replica fails, the Storage Service fails, so replica_factor=3 is recommended.

To prevent unnecessary waste of resources, we recommend that you set an odd replica number.

We suggest that you set replica_factor to 3 for the production environment and 1 for the test environment. Do not use an even number.

How to resolve [ERROR (-7)]: SyntaxError: syntax error near?

In most cases, a query statement requires a YIELD or a RETURN. Check your query statement to see if YIELD or RETURN is provided.

How to count the vertices/edges number of each tag/edge type?

See show-stats.

How to get all the vertices/edge of each tag/edge type?
  1. Create and rebuild the index.

    > CREATE TAG INDEX i_player ON player();
    > REBUILD TAG INDEX i_player;
  2. Use LOOKUP or MATCH.

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


How to resolve the can’t solve the start vids from the sentence error?

The graphd requires start vids to begin a graph traversal. The start vids can either be specified by the user, for example,

> GO FROM ${vids} ...
> MATCH (src) WHERE id(src) == ${vids}
# The start vids are explicitly given by ${vids}.

or be found from a (property) index, for example,

# CREATE TAG INDEX i_player ON player(name(20));

> LOOKUP ON player WHERE == "abc" | ... YIELD ...
> MATCH (src) WHERE == "abc" ... 
# The start vids are found from the property index on name.

Otherwise, an error like can’t solve the start vids from the sentence will be raised.

How to resolve error Storage Error: The VID must be a 64-bit integer or a string.?

Check your vid is an integer or a fix_string(N). If it is a string type, make sure your input is not longer than N (default value is 8). See create space.

How to resolve error edge conflict or vertex conflict?

Nebula Graph returns such errors when the Storage Service receives multiple requests to insert or update the same vertex or edge within milliseconds. Try the failed requests again later.

Storage Error E_RPC_FAILURE

Storaged returns too many data back to graphd。Possible solutions:

  1. Check whether storaged is Out-of-memory. (dmesg| grep nebula).
  2. In nebula-graphd.conf, modify or add the item --storage_client_timeout_ms=60000 to change the timeout(ms)。
  3. Modify your nGQL to reduce full scans (including limit sentence).
  4. Use better hardware (NVMe, more memory).
  5. retry。
The leader has changed. Try again later

Known Issue. Just retry 1 to N times, where N is the partition number。The reason is that meta client needs some heartbeats to update or errors to trigger the new leader information.

How to stop a slow query

You can't. Even killing a client will not stop the running slow query. You have to wait the query to complete.

About operation and maintenance

The log files are too large. How to recycle the logs?

Nebula Graph uses glog to print logs. glog can't recycle the outdated files. You can use crontab to delete them by yourself. Refer to the discussions of Glog should delete old log files automatically.

How to check the Nebula Graph version?
  1. Use the <binary_path> --version command to get the Git commit IDs of the Nebula Graph binary files.

    For exmaple, to check the version of the Graph Service, go to the directories where the nebula-graphd binary files are stored, and run ./nebula-graphd --version as follows to get the commit IDs.

    $ ./nebula-graphd --version
    nebula-graphd version Git: ab4f683, Build Time: Mar 24 2021 02:17:30
    This source code is licensed under Apache 2.0 License, attached with Common Clause Condition 1.0.
  2. Search for the commit ID obtained in the preceding step on the GitHub commits page.

  3. Compare the commit time of the binary files with the release time of Nebula Graph versions to find out the version of the Nebula Graph services.

How to scale out or scale in?

Nebula Graph master doesn't provide any commands or tools to support automatic scale out/in. You can do by the following steps:

  1. metad: metad can not be scaled out or scale in. The process can't be moved to a new machine. You can not add a new metad process to the service.

  2. Scale in graphd : remove graphd from client's code. Close this graphd process.

  3. Scale out graphd: prepare graphd's binary and config files in the new host. Modify the config files and add all existing metad's addresses. Then start the new graphd process.

  4. Scale in storaged:(All spaces' replace number must be greater than 1),ref to Balance remove command. After the command finish, stop this storaged process.

  5. Scale out storaged:(All spaces' replace number must be greater than 1)prepare storaged's binary and config files in the new host, Modify the config files and add all existing metad's adDresses. Then start the new storaged process.

You may also need to run Balance Data and Balance leader after scaling in/out storaged.

About connections

Which ports should be opened on the firewalls?

If you have not changed the predefined ports in the configurations, open the following ports for the Nebula Graph services:

Service Ports
Meta 9559, 9560, 19559, 19560
Graph 9669, 19669, 19670
Storage 9777 ~ 9780, 19779, 19780

If you have customized the configuration files and changed the predefined ports, find the port numbers in your configuration files and open them on the firewalls.

How to test whether a port is open or closed?

You can use telnet as follows to check for port status.

telnet <ip> <port>

For example:

// If the port is open:
$ telnet 9669
Connected to
Escape character is '^]'.

// If the port is closed or blocked:
$ telnet 9777
telnet: connect to address Connection refused

If you cannot use the telnet command, check if telnet is installed or enabled on your host.

Last update: July 7, 2021
Back to top