docs: cluster_info table

docs/nightly/en/reference/sql/information-schema/cluster-info.md

@@ -0,0 +1,70 @@
+# CLUSTER_INFO
+
+The `CLUSTER_INFO` table provides the topology information of the cluster.
+
+
+```sql
+USE INFORMATION_SCHEMA;
+
+DESC TABLE CLUSTER_INFO;
+```
+
+The output is as follows:
+
+```sql
++-------------+----------------------+------+------+---------+---------------+
+| Column | Type | Key | Null | Default | Semantic Type |
++-------------+----------------------+------+------+---------+---------------+
+| peer_id | Int64 | | NO | | FIELD |
+| peer_type | String | | NO | | FIELD |
+| peer_addr | String | | YES | | FIELD |
+| version | String | | NO | | FIELD |
+| git_commit | String | | NO | | FIELD |
+| start_time | TimestampMillisecond | | YES | | FIELD |
+| uptime | String | | YES | | FIELD |
+| active_time | String | | YES | | FIELD |
++-------------+----------------------+------+------+---------+---------------+
+```
+
+
+The columns in table:
+
+* `peer_id`: the server id of the node. It's always `0` for standalone mode and `-1` for frontends because it doesn't make sense in such cases.
+* `peer_type`: the node type, `METASRV`,`FRONTEND`, or `DATANODE` for distributed clusters and `STANDALONE` for standalone deployments.
+* `peer_addr`: the GRPC server address of the node. It's always empty for standalone deployments.
+* `version`: The build version of the node, such as `0.7.2` etc.
+* `start_time`: The node start time.
+* `uptime`: The uptime of the node, in the format of duration string `24h 10m 59s 150ms`.
+* `active_time`: The duration string in the format of `24h 10m 59s 150ms` since the node's last active time(sending the heartbeats), it's always empty for standalone deployments.
+
+Let's query the table:
+
+```sql
+SELECT * FROM CLUSTER_INFO;
+```
+
+An example output in standalone deployments:
+
+```sql
++---------+------------+-----------+---------+------------+-------------------------+--------+-------------+
+| peer_id | peer_type | peer_addr | version | git_commit | start_time | uptime | active_time |
++---------+------------+-----------+---------+------------+-------------------------+--------+-------------+
+| 0 | STANDALONE | | 0.7.2 | 86ab3d9 | 2024-04-30T06:40:02.074 | 18ms | |
++---------+------------+-----------+---------+------------+-------------------------+--------+-------------+
+```
+
+Another example is from a distributed cluster that has three Datanodes, one Frontend, and one Metasrv.
+
+```sql
++---------+-----------+----------------+---------+------------+-------------------------+----------+-------------+
+| peer_id | peer_type | peer_addr | version | git_commit | start_time | uptime | active_time |
++---------+-----------+----------------+---------+------------+-------------------------+----------+-------------+
+| 1 | DATANODE | 127.0.0.1:4101 | 0.7.2 | 86ab3d9 | 2024-04-30T06:40:04.791 | 4s 478ms | 1s 467ms |
+| 2 | DATANODE | 127.0.0.1:4102 | 0.7.2 | 86ab3d9 | 2024-04-30T06:40:06.098 | 3s 171ms | 162ms |
+| 3 | DATANODE | 127.0.0.1:4103 | 0.7.2 | 86ab3d9 | 2024-04-30T06:40:07.425 | 1s 844ms | 1s 839ms |
+| -1 | FRONTEND | 127.0.0.1:4001 | 0.7.2 | 86ab3d9 | 2024-04-30T06:40:08.815 | 454ms | 47ms |
+| 0 | METASRV | 127.0.0.1:3002 | unknown | unknown | | | |
++---------+-----------+----------------+---------+------------+-------------------------+----------+-------------+
+```
+
+

docs/nightly/en/reference/sql/information-schema/overview.md

@@ -51,8 +51,9 @@ There is still lots of work to do for `INFORMATION_SCHEMA`. The tracking [issue]
 | Table Name | Description |
 | --- | --- |
 | [`BUILD_INFO`](./build-info.md) | Provides the system build info. |
-| [`GREPTIME_REGION_PEERS`](./greptime-region-peers.md) | Provides details about where regions are stored. |
+| [`REGION_PEERS`](./region-peers.md) | Provides details about where regions are stored. |
 | [`RUNTIME_METRICS`](./runtime-metrics.md)| Provides the system runtime metrics.|
+| [`CLUSTER_INFO`](./cluster-info.md)| Provides the topology information of the cluster.|
 
 
 

docs/nightly/en/reference/sql/information-schema/greptime-region-peers.md → docs/nightly/en/reference/sql/information-schema/region-peers.md

@@ -1,14 +1,14 @@
-# GREPTIME_REGION_PEERS
+# REGION_PEERS
 
-The `GREPTIME_REGION_PEERS` table shows detailed information of a single Region node in GreptimeDB, such as whether it is a learner or leader.
+The `REGION_PEERS` table shows detailed information of a single Region node in GreptimeDB, such as whether it is a learner or leader.
 
 :::tip NOTE
 This table is not available on [GreptimeCloud](https://greptime.cloud/).
 :::
 
 ```sql
 USE INFORMATION_SCHEMA;
-DESC GREPTIME_REGION_PEERS;
+DESC REGION_PEERS;
 ```
 
 The output is as follows:
@@ -27,7 +27,7 @@ The output is as follows:
 6 rows in set (0.00 sec)
 ```
 
-Fields in the `GREPTIME_REGION_PEERS` table are described as follows:
+Fields in the `REGION_PEERS` table are described as follows:
 
 - `region_id`: The ID of the Region.
 - `peer_id`: The ID of the Region peer.

docs/nightly/en/summary.yml

@@ -166,8 +166,9 @@
  - schemata
  - tables
  # - table-constraints
- - greptime-region-peers
+ - region-peers
  - runtime-metrics
+ - cluster-info
  - Telemetry
 - Contributor-Guide:
  - overview

docs/nightly/en/user-guide/operations/region-migration.md

@@ -17,7 +17,7 @@ You need to first query the region distribution of the table, i.e., find out on
 ```sql
 select b.peer_id as datanode_id,
  a.greptime_partition_id as region_id
-from information_schema.partitions a left join information_schema.greptime_region_peers b
+from information_schema.partitions a left join information_schema.region_peers b
 on a.greptime_partition_id = b.region_id where a.table_name='migration_target' order by datanode_id asc;
 ```
 
@@ -32,6 +32,9 @@ For example, have the following region distribution:
 1 row in set (0.01 sec)
 ```
 
+
+For more info about the `region_peers` table, please read the [reference](/reference/sql/information-schema/cluster-info.md).
+
 ## Select a Datanode as the migration destination.
 :::warning Warning
 The region migration won't be performed if the `from_peer_id` equals the `to_peer_id`.

docs/nightly/zh/reference/sql/information-schema/cluster-info.md

@@ -0,0 +1,71 @@
+# CLUSTER_INFO
+
+`CLUSTER_INFO` 表提供了集群的节点拓扑信息。 
+
+
+```sql
+USE INFORMATION_SCHEMA;
+
+DESC TABLE CLUSTER_INFO;
+```
+
+输出如下：
+
+```sql
++-------------+----------------------+------+------+---------+---------------+
+| Column | Type | Key | Null | Default | Semantic Type |
++-------------+----------------------+------+------+---------+---------------+
+| peer_id | Int64 | | NO | | FIELD |
+| peer_type | String | | NO | | FIELD |
+| peer_addr | String | | YES | | FIELD |
+| version | String | | NO | | FIELD |
+| git_commit | String | | NO | | FIELD |
+| start_time | TimestampMillisecond | | YES | | FIELD |
+| uptime | String | | YES | | FIELD |
+| active_time | String | | YES | | FIELD |
++-------------+----------------------+------+------+---------+---------------+
+```
+
+
+每个列的含义：
+
+* `peer_id`: 节点的服务器 ID。对于 standalone 来讲，该字段总是为 `0`，对于集群模式下的 frontend 该字段总为 `-1`。因为在这两种情况下，该字段没有实际含义。
+* `peer_type`: 节点类型, 分布式集群里可能是 `METASRV`、`FRONTEND` 或者 `DATANODE`。单机模式显示为 `STANDALONE`。
+* `peer_addr`: 节点的 gRPC 服务地址。对于单机部署，该字段总为空。
+* `version`: 节点的版本号，形如 `0.7.2` 的字符串。
+* `start_time`: 节点的启动时间。
+* `uptime`: 节点的持续运行时间，形如 `24h 10m 59s 150ms` 的字符串。
+* `active_time`: 距离节点上一次活跃（也就是发送心跳请求）过去的时间，形如 `24h 10m 59s 150ms` 的字符串。单机模式下该字段总为空。
+
+
+让我们尝试查询下这张表：
+
+```sql
+SELECT * FROM CLUSTER_INFO;
+```
+
+一个单机模式的样例输出：
+
+```sql
++---------+------------+-----------+---------+------------+-------------------------+--------+-------------+
+| peer_id | peer_type | peer_addr | version | git_commit | start_time | uptime | active_time |
++---------+------------+-----------+---------+------------+-------------------------+--------+-------------+
+| 0 | STANDALONE | | 0.7.2 | 86ab3d9 | 2024-04-30T06:40:02.074 | 18ms | |
++---------+------------+-----------+---------+------------+-------------------------+--------+-------------+
+```
+
+另一个输出来自一个分布式集群，它有三个 Datanode、一个 Frontend 和一个 Metasrv：
+
+```sql
++---------+-----------+----------------+---------+------------+-------------------------+----------+-------------+
+| peer_id | peer_type | peer_addr | version | git_commit | start_time | uptime | active_time |
++---------+-----------+----------------+---------+------------+-------------------------+----------+-------------+
+| 1 | DATANODE | 127.0.0.1:4101 | 0.7.2 | 86ab3d9 | 2024-04-30T06:40:04.791 | 4s 478ms | 1s 467ms |
+| 2 | DATANODE | 127.0.0.1:4102 | 0.7.2 | 86ab3d9 | 2024-04-30T06:40:06.098 | 3s 171ms | 162ms |
+| 3 | DATANODE | 127.0.0.1:4103 | 0.7.2 | 86ab3d9 | 2024-04-30T06:40:07.425 | 1s 844ms | 1s 839ms |
+| -1 | FRONTEND | 127.0.0.1:4001 | 0.7.2 | 86ab3d9 | 2024-04-30T06:40:08.815 | 454ms | 47ms |
+| 0 | METASRV | 127.0.0.1:3002 | unknown | unknown | | | |
++---------+-----------+----------------+---------+------------+-------------------------+----------+-------------+
+```
+
+

docs/nightly/zh/reference/sql/information-schema/overview.md

@@ -49,7 +49,8 @@
 |表名|描述|
 | --- | --- |
 | [`BUILD_INFO`](./build-info.md) | 提供了系统构建的信息。 |
-| [`GREPTIME_REGION_PEERS`](./greptime-region-peers.md) | 提供了区域存储的详细信息。 |
+| [`REGION_PEERS`](./region-peers.md) | 提供了表的 Region 存储的详细信息。 |
 | [`RUNTIME_METRICS`](./runtime-metrics.md)| 提供了系统运行时指标。|
+| [`CLUSTER_INFO`](./cluster-info.md)| 提供了集群的节点拓扑信息。|
 
 

docs/nightly/zh/reference/sql/information-schema/greptime-region-peers.md → docs/nightly/zh/reference/sql/information-schema/region-peers.md

@@ -1,14 +1,14 @@
-# GREPTIME_REGION_PEERS
+# REGION_PEERS
 
-`GREPTIME_REGION_PEERS` 表显示了 GreptimeDB 中单个 Region 节点的详细信息，例如它是 learner 还是 leader。
+`REGION_PEERS` 表显示了 GreptimeDB 中单个 Region 节点的详细信息，例如它是 learner 还是 leader。
 
 :::tip 注意
 该表在 [GreptimeCloud](https://greptime.cloud/) 中不可用。
 :::
 
 ```sql
 USE INFORMATION_SCHEMA;
-DESC GREPTIME_REGION_PEERS;
+DESC REGION_PEERS;
 ```
 
 结果如下：
@@ -27,7 +27,7 @@ DESC GREPTIME_REGION_PEERS;
 6 rows in set (0.00 sec)
 ```
 
-`GREPTIME_REGION_PEERS` 表中的字段描述如下：
+`REGION_PEERS` 表中的字段描述如下：
 
 - `region_id`：Region 的 ID。
 - `peer_id`：Region peer 的 ID。

docs/nightly/zh/user-guide/operations/region-migration.md

@@ -18,7 +18,7 @@ Region 迁移允许用户在 Datanode 间移动 Region 数据。
 ```sql
 select b.peer_id as datanode_id,
  a.greptime_partition_id as region_id
-from information_schema.partitions a left join information_schema.greptime_region_peers b
+from information_schema.partitions a left join information_schema.region_peers b
 on a.greptime_partition_id = b.region_id where a.table_name='migration_target' order by datanode_id asc;
 ```
 
@@ -32,6 +32,9 @@ on a.greptime_partition_id = b.region_id where a.table_name='migration_target' o
 1 row in set (0.01 sec)
 ```
 
+
+更多关于 `region_peers` 表的信息，请阅读 [Reference](/reference/sql/information-schema/cluster-info.md)。
+
 ## 选择 Region 迁移的目标节点
 :::warning Warning
 当起始节点等于目标节点时，Region 迁移不会被执行