CLUSTER_INFO

The CLUSTER_INFO table provides the topology information of the cluster.

  1. USE INFORMATION_SCHEMA;
  2. DESC TABLE CLUSTER_INFO;

The output is as follows:

  1. +-------------+----------------------+------+------+---------+---------------+
  2. | Column | Type | Key | Null | Default | Semantic Type |
  3. +-------------+----------------------+------+------+---------+---------------+
  4. | peer_id | Int64 | | NO | | FIELD |
  5. | peer_type | String | | NO | | FIELD |
  6. | peer_addr | String | | YES | | FIELD |
  7. | version | String | | NO | | FIELD |
  8. | git_commit | String | | NO | | FIELD |
  9. | start_time | TimestampMillisecond | | YES | | FIELD |
  10. | uptime | String | | YES | | FIELD |
  11. | active_time | String | | YES | | FIELD |
  12. +-------------+----------------------+------+------+---------+---------------+

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.
  • git_commit: The build git commit of the node.
  • 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.

Query the table:

  1. SELECT * FROM CLUSTER_INFO;

An example output in standalone deployments:

  1. +---------+------------+-----------+---------+------------+-------------------------+--------+-------------+
  2. | peer_id | peer_type | peer_addr | version | git_commit | start_time | uptime | active_time |
  3. +---------+------------+-----------+---------+------------+-------------------------+--------+-------------+
  4. | 0 | STANDALONE | | 0.7.2 | 86ab3d9 | 2024-04-30T06:40:02.074 | 18ms | |
  5. +---------+------------+-----------+---------+------------+-------------------------+--------+-------------+

Another example is from a distributed cluster that has three Datanodes, one Frontend, and one Metasrv.

  1. +---------+-----------+----------------+---------+------------+-------------------------+----------+-------------+
  2. | peer_id | peer_type | peer_addr | version | git_commit | start_time | uptime | active_time |
  3. +---------+-----------+----------------+---------+------------+-------------------------+----------+-------------+
  4. | 1 | DATANODE | 127.0.0.1:4101 | 0.7.2 | 86ab3d9 | 2024-04-30T06:40:04.791 | 4s 478ms | 1s 467ms |
  5. | 2 | DATANODE | 127.0.0.1:4102 | 0.7.2 | 86ab3d9 | 2024-04-30T06:40:06.098 | 3s 171ms | 162ms |
  6. | 3 | DATANODE | 127.0.0.1:4103 | 0.7.2 | 86ab3d9 | 2024-04-30T06:40:07.425 | 1s 844ms | 1s 839ms |
  7. | -1 | FRONTEND | 127.0.0.1:4001 | 0.7.2 | 86ab3d9 | 2024-04-30T06:40:08.815 | 454ms | 47ms |
  8. | 0 | METASRV | 127.0.0.1:3002 | unknown | unknown | | | |
  9. +---------+-----------+----------------+---------+------------+-------------------------+----------+-------------+