Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

operation and maintenance statements #615

Merged
merged 1 commit into from
Aug 23, 2021
Merged

operation and maintenance statements #615

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
88 changes: 35 additions & 53 deletions docs-2.0/3.ngql-guide/18.operation-and-maintenance-statements/.1.configs-syntax.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,50 +1,60 @@
# CONFIG syntax
# CONFIG

This document gives some introductions to `CONFIG` syntax in nGQL.
When you start the Nebula Graph cluster for the first time, the system reads the configuration from the local and saves it in the Meta service. After restarting the cluster, it will also read the configuration from the Meta service. The `CONFIG` statement can modify the Nebula Graph configuration saved in the Meta service without modifying your local files.

!!! Note

According to past practice, we suggest you fetch the configuration from the local. For details, see [Configuration](../../5.configurations-and-logs/1.configurations/1.configurations.md#Modify configurations).

## SHOW CONFIGS

`SHOW CONFIGS` shows the configuration information for the specified service. When the service is not specified, Nebula Graph returns all the service configurations.

You do not need any privileges for the graph space to run this statement. But the returned results are different based on [privileges](../../7.data-security/1.authentication/3.role-list.md).

### Syntax

```ngql
SHOW CONFIGS [ {META|GRAPH|STORAGE} ]
SHOW CONFIGS [ {META|GRAPH|STORAGE} ];
```

`SHOW CONFIGS` shows the configurations for the specified service. When the service is not specified, Nebula Graph returns all the service configurations. You do not need any privileges for the graph space to run this statement. But the returned results are different based on [role privileges](../../7.data-security/1.authentication/3.role-list.md).

For example:
### Examples

```ngql
nebula> SHOW CONFIGS GRAPH;
+---------+---------------------------+-------+-----------+-------+
| module | name | type | mode | value |
+---------+---------------------------+-------+-----------+-------+
| "GRAPH" | "v" | "int" | "MUTABLE" | 0 |
+---------+---------------------------+-------+-----------+-------+
| "GRAPH" | "minloglevel" | "int" | "MUTABLE" | 0 |
+---------+---------------------------+-------+-----------+-------+
| "GRAPH" | "slow_op_threshhold_ms" | "int" | "MUTABLE" | 50 |
+---------+---------------------------+-------+-----------+-------+
| "GRAPH" | "heartbeat_interval_secs" | "int" | "MUTABLE" | 3 |
+---------+---------------------------+-------+-----------+-------+
| "GRAPH" | "meta_client_retry_times" | "int" | "MUTABLE" | 3 |
+---------+---------------------------+-------+-----------+-------+
+---------+---------------------------+--------+-----------+-------+
| module | name | type | mode | value |
+---------+---------------------------+--------+-----------+-------+
| "GRAPH" | "v" | "int" | "MUTABLE" | 0 |
+---------+---------------------------+--------+-----------+-------+
| "GRAPH" | "minloglevel" | "int" | "MUTABLE" | 0 |
+---------+---------------------------+--------+-----------+-------+
| "GRAPH" | "slow_op_threshhold_ms" | "int" | "MUTABLE" | 50 |
+---------+---------------------------+--------+-----------+-------+
| "GRAPH" | "accept_partial_success" | "bool" | "MUTABLE" | false |
+---------+---------------------------+--------+-----------+-------+
| "GRAPH" | "heartbeat_interval_secs" | "int" | "MUTABLE" | 10 |
+---------+---------------------------+--------+-----------+-------+
| "GRAPH" | "meta_client_retry_times" | "int" | "MUTABLE" | 3 |
+---------+---------------------------+--------+-----------+-------+
```

```ngql
nebula> SHOW CONFIGS META;
Empty set (time spent 2059/3429 us)
```

The preceding query returns an empty set because the configurations for Meta Service are immutable in the Console.

## GET CONFIGS

`GET CONFIGS` gets the specified configuration information for the specified service. When the service is not specified, Nebula Graph returns all the configurations that have the same name.

### Syntax

```ngql
GET CONFIGS [ {GRAPH|STORAGE} :] <configuration_name>
GET CONFIGS [ {GRAPH|STORAGE} :] <configuration_name>;
```

`GET CONFIGS` gets the specified configuration information for the specified service. When the service is not specified, Nebula Graph returns all the configurations that have the same name.

For example:
### Examples

```ngql
nebula> GET CONFIGS STORAGE:wal_ttl;
Expand All @@ -65,31 +75,3 @@ nebula> GET CONFIGS heartbeat_interval_secs;
| "STORAGE" | "heartbeat_interval_secs" | "int" | "MUTABLE" | 3 |
+-----------+---------------------------+-------+-----------+-------+
```

## UPDATE CONFIGS

```ngql
UPDATE CONFIGS [ {GRAPH | STORAGE} :] <configuration_name>=<new_value>
```

`UPDATE CONFIGS` updates the specified configuration value for the specified service. `UPDATE CONFIGS` updates only the **mutable** configurations. When the service is not specified, Nebula Graph updates all the configurations that have the same name. `UPDATE CONFIGS` supports expressions.

To update the **immutable** configurations, follow these steps:

1. Modify the configuration files related to the configurations. The default path to the configuration file is `/usr/local/nebula/etc`.
2. Save your modification in step one and close the configuration file.
3. Restart Nebula Graph services.

The updated configuration value is stored in the `meta service` permanently. The modification to a mutable configuration takes effect immediately. To make the modification to some RocksDB configurations take effect, you need to restart the services.

For example:

```ngql
nebula> UPDATE CONFIGS STORAGE:heartbeat_interval_secs=3;
nebula> GET CONFIGS STORAGE:heartbeat_interval_secs;
+-----------+---------------------------+-------+-----------+-------+
| module | name | type | mode | value |
+-----------+---------------------------+-------+-----------+-------+
| "STORAGE" | "heartbeat_interval_secs" | "int" | "MUTABLE" | 3 |
+-----------+---------------------------+-------+-----------+-------+
```
4 changes: 2 additions & 2 deletions docs-2.0/3.ngql-guide/18.operation-and-maintenance-statements/2.balance-syntax.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -6,8 +6,8 @@ The `BALANCE` statements are listed as follows.

|Syntax|Description|
|-|-|
|`BALANCE DATA`|Starts a task to balance the distribution of storage partitions in a Nebula Graph cluster.|
|`BALANCE DATA <balance_id>`|Shows the status of the balance task.|
|`BALANCE DATA`|Starts a task to balance the distribution of storage partitions in a Nebula Graph cluster. It returns the task ID (`balance_id`). |
|`BALANCE DATA <balance_id>`|Shows the status of the `BALANCE DATA` task.|
|`BALANCE DATA STOP`|Stops the `BALANCE DATA` task.|
|`BALANCE DATA REMOVE <host_list>`|Scales in the Nebula Graph cluster and detaches specific storage hosts.|
|`BALANCE LEADER`|Balances the distribution of storage raft leaders in a Nebula Graph cluster.|
52 changes: 34 additions & 18 deletions docs-2.0/3.ngql-guide/18.operation-and-maintenance-statements/4.job-statements.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,10 +1,14 @@
# Job manager and the JOB statements

The long-term tasks running by the Storage Service are called jobs. For example, there are jobs for `COMPACT`, `FLUSH`, and `STATS`. These jobs can be time-consuming if the data size in the graph space is large. The job manager helps you run, show, stop, and recover the jobs.
The long-term tasks run by the Storage Service are called jobs, such as `COMPACT`, `FLUSH`, and `STATS`. These jobs can be time-consuming if the data amount in the graph space is large. The job manager helps you run, show, stop, and recover jobs.

## SUBMIT JOB COMPACT

The `SUBMIT JOB COMPACT` statement triggers the long-term RocksDB compact operation.
The `SUBMIT JOB COMPACT` statement triggers the long-term RocksDB `compact` operation.

For more information about `compact` configuration, see [Storage Service configuration](../../5.configurations-and-logs/1.configurations/4.storage-config.md).

### Example

```ngql
nebula> SUBMIT JOB COMPACT;
Expand All @@ -15,11 +19,11 @@ nebula> SUBMIT JOB COMPACT;
+------------+
```

For more information about compact configuration, see [Storage Service configuration](../../5.configurations-and-logs/1.configurations/4.storage-config.md).

## SUBMIT JOB FLUSH

The `SUBMIT JOB FLUSH` statement writes the RocksDB memfile in memory to the hard disk.
The `SUBMIT JOB FLUSH` statement writes the RocksDB memfile in the memory to the hard disk.

### Example

```ngql
nebula> SUBMIT JOB FLUSH;
Expand All @@ -38,6 +42,8 @@ The `SUBMIT JOB STATS` statement starts a job that makes the statistics of the c

If the data stored in the graph space changes, in order to get the latest statistics, you have to run `SUBMIT JOB STATS` again.

### Example

```ngql
nebula> SUBMIT JOB STATS;
+------------+
Expand All @@ -49,9 +55,11 @@ nebula> SUBMIT JOB STATS;

## SHOW JOB

The Meta Service parses a `SUBMIT JOB` request into tasks and assigns them to the nebula-storaged processes. The `SHOW JOB <job_id>` statement shows the information about a specific job and all its tasks.
The Meta Service parses a `SUBMIT JOB` request into multiple tasks and assigns them to the nebula-storaged processes. The `SHOW JOB <job_id>` statement shows the information about a specific job and all its tasks.

The job ID is created when you run the `SUBMIT JOB` statement.
`job_id` is returned when you run the `SUBMIT JOB` statement.

### Example

```ngql
nebula> SHOW JOB 96;
Expand All @@ -68,30 +76,30 @@ nebula> SHOW JOB 96;
+----------------+---------------+------------+-------------------------+-------------------------+
```

The description of the return message is as follows.
The descriptions are as follows.

|Column|Description|
|Parameter|Description|
|-|-|
|`Job Id(TaskId)`|The first row shows the job ID, and the other rows show the task IDs.|
|`Command(Dest)`|The first row shows the command executed, and the other rows show on which storaged processes the task is running.|
|`Status`|Shows the status of the job or task. For more information about job status, see [Job status](#job_status).|
|`Job Id(TaskId)`|The first row shows the job ID and the other rows show the task IDs.|
|`Command(Dest)`|The first row shows the command executed and the other rows show on which storaged processes the task is running.|
|`Status`|Shows the status of the job or task. For more information, see [Job status](#job_status).|
|`Start Time`|Shows a timestamp indicating the time when the job or task enters the `RUNNING` phase.|
|`Stop Time`|Shows a timestamp indicating the time when the job or task gets `FINISHED`, `FAILED`, or `STOPPED`.|

### Job status

The description of the job status is as follows.
The descriptions are as follows.

|Status|Description|
|-|-|
|QUEUE|The job or task is waiting in a queue. The `Start Time` is empty in this phase.|
|RUNNING|The job or task is running. The `Start Time` shows the beginning of this phase.|
|RUNNING|The job or task is running. The `Start Time` shows the beginning time of this phase.|
|FINISHED|The job or task is successfully finished. The `Stop Time` shows the time when the job or task enters this phase.|
|FAILED|The job or task failed. The `Stop Time` shows the time when the job or task enters this phase.|
|FAILED|The job or task has failed. The `Stop Time` shows the time when the job or task enters this phase.|
|STOPPED|The job or task is stopped without running. The `Stop Time` shows the time when the job or task enters this phase.|
|REMOVED|The job or task is removed.|

Status switching is described as follows.
The description of switching the status is described as follows.

```ngql
Queue -- running -- finished -- removed
Expand All @@ -103,7 +111,11 @@ Queue -- running -- finished -- removed

## SHOW JOBS

The `SHOW JOBS` statement lists all the unexpired jobs. The default job expiration interval is one week. You can change it by modifying the `job_expired_secs` parameter of the Meta Service. For how to modify `job_expired_secs`, see [Meta Service configuration](../../5.configurations-and-logs/1.configurations/2.meta-config.md).
The `SHOW JOBS` statement lists all the unexpired jobs.

The default job expiration interval is one week. You can change it by modifying the `job_expired_secs` parameter of the Meta Service. For how to modify `job_expired_secs`, see [Meta Service configuration](../../5.configurations-and-logs/1.configurations/2.meta-config.md).

### Example

```ngql
nebula> SHOW JOBS;
Expand All @@ -124,6 +136,8 @@ nebula> SHOW JOBS;

The `STOP JOB` statement stops jobs that are not finished.

### Example

```ngql
nebula> STOP JOB 22;
+---------------+
Expand All @@ -137,6 +151,8 @@ nebula> STOP JOB 22;

The `RECOVER JOB` statement re-executes the failed jobs and returns the number of recovered jobs.

### Example

```ngql
nebula> RECOVER JOB;
+-------------------+
Expand All @@ -148,7 +164,7 @@ nebula> RECOVER JOB;

## FAQ

### How to troubleshoot job problems
### How to troubleshoot job problems?

The `SUBMIT JOB` operations use the HTTP port. Please check if the HTTP ports on the machines where the Storage Service is running are working well. You can use the following command to debug.

Expand Down
28 changes: 28 additions & 0 deletions docs-2.0/3.ngql-guide/18.operation-and-maintenance-statements/6.kill-query.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,28 @@
# Kill queries

`KILL QUERY` can terminate the query being executed, and is often used to terminate slow queries.

## Syntax

```ngql
KILL QUERY (session=<session_id>, plan=<plan_id>);
```

- `session_id`: The ID of the session.
- `plan_id`: The ID of the execution plan.

The ID of the session and the ID of the execution plan can uniquely determine a query. Both can be obtained through the [SHOW QUERIES](../7.general-query-statements/6.show/18.show-queries.md) statement.

## Examples

This example executes `KILL QUERY` in one session to terminate the query in another session.

```ngql
nebula> KILL QUERY(SESSION=1625553545984255,PLAN=163);
```

The query will be terminated and the following information will be returned.

```ngql
[ERROR (-1005)]: Execution had been killed
```