跳转到主要内容

status：实例概况

这是个什么实例、基本面是否正常：角色、复制、连接数、各库大小、磁盘。

采集于 2026-09-27（UTC+08），本地 KingbaseES V008R006C009B0014 主节点和备节点，数据库 test。工具是 Go 版源码提交 93bf65d 编译的 ~/kbdiag（linux/amd64 静态二进制）。这是测试环境实测，不代表生产环境验收。FAIL 的例子由故障注入脚本造出来，它把普通用户可用的连接全部占满。数值只属于本次采样。

用法

kbdiag status [--json]

status 没有自己的参数。连接参数和 sessions 相同。

只判两件事：

  • FAIL：普通用户可用的连接（max_connections 减去 superuser_reserved_connections）全部占满，业务已经连不上。
  • WARN：备库没在收 WAL，即没有 WAL 接收进程，或者它的状态不是 streaming。这时查询还能跑，但主库一旦挂掉，没有能接管的最新备库。

不报"连接快满"。连接多到什么程度算多，要看应用，所以 status 只给出数字，由你判断。

在主库上

~/kbdiag status
echo EXIT_CODE=$?
status  OK  (KingbaseES V008R006C009B0014, primary, system@local, 2026-09-27T13:34:42+08:00)

inst.info
  version         V008R006C009B0014
  data_directory  /home/kingbase/cluster/install/kingbase/data
  port            54321
  start_time      2026-09-20 22:19:13  (up 6d 15h)
  connections     5 / 97  (max_connections 100 - superuser_reserved 3)

inst.downstreams: 1
  name   address         state      sync
  node2  192.168.105.11  streaming  quorum

inst.upstream: not_applicable  (primary)

inst.databases: 5, total 382 MB
  test      325 MB
  esrep      15 MB
  mydb       14 MB
  kingbase   14 MB
  security   14 MB

inst.disk  (filesystem of data_directory)
  used   14 GB / 199 GB  (7%)
  free  185 GB
EXIT_CODE=0
  • 第一行的角色（primary / standby）来自 sys_is_in_recovery()。
  • inst.info：connections 只数连到某个库的后端，不含后台进程，可以直接和普通用户可用的 97 个比。
  • inst.downstreams：本实例给哪些备库发 WAL，一个备库一行，数据来自 sys_stat_replication。sync 照数据库原样显示，repmgr 下这里是 quorum，不是 sync / async。
  • inst.upstream 只对备库适用。
  • inst.databases：非模板库，从大到小排。大小按 1024 进位，和 pg_size_pretty 一致。
  • inst.disk：data_directory 所在的文件系统，口径和 df 一样。已用加可用小于总量，差的是给 root 预留的块。只展示，不参与判定。

在备库上

~/kbdiag status
echo EXIT_CODE=$?
status  OK  (KingbaseES V008R006C009B0014, standby, system@local, 2026-09-27T13:37:22+08:00)

inst.info
  version         V008R006C009B0014
  data_directory  /home/kingbase/cluster/install/kingbase/data
  port            54321
  start_time      2026-09-23 15:44:58  (up 3d 21h)
  connections     5 / 97  (max_connections 100 - superuser_reserved 3)

inst.upstream
  status    streaming
  upstream  192.168.105.10:54321
  slot      repmgr_slot_2
  last_msg  11s ago

inst.downstreams: 0

inst.databases: 5, total 382 MB
  test      325 MB
  esrep      15 MB
  kingbase   14 MB
  mydb       14 MB
  security   14 MB

inst.disk  (filesystem of data_directory)
  used   12 GB / 199 GB  (6%)
  free  187 GB
EXIT_CODE=0
  • 备库上游排在前面，数据来自 sys_stat_wal_receiver：从哪里收 WAL、走哪个槽、最后一条消息是多久前。
  • last_msg 只展示，不判。主库空闲时每 wal_receiver_status_interval（默认 10 秒）才发一条，几秒是正常值。
  • WAL 接收进程被暂停时（比如被 SIGSTOP），状态仍然是 streaming，status 不会报。如果 last_msg 一直在涨，请自己去备库上看 WAL 接收进程。slots 页有这种情况的实采。

连接全部占满

~/kbdiag status
echo EXIT_CODE=$?
status  FAIL  (KingbaseES V008R006C009B0014, primary, system@local, 2026-09-27T13:38:16+08:00)

[FAIL] inst.connections  98 connections in use, reaching the 97 ordinary users may open (max_connections 100 minus 3 reserved for superusers): ordinary users can no longer connect
  verify: kbdiag sessions  # who holds the connections: the summary at the top counts them by user, database, application and client

inst.info
  version         V008R006C009B0014
  data_directory  /home/kingbase/cluster/install/kingbase/data
  port            54321
  start_time      2026-09-20 22:19:13  (up 6d 15h)
  connections     98 / 97  (max_connections 100 - superuser_reserved 3)

inst.downstreams: 1
  name   address         state      sync
  node2  192.168.105.11  streaming  quorum

inst.upstream: not_applicable  (primary)

inst.databases: 5, total 382 MB
  test      325 MB
  esrep      15 MB
  mydb       14 MB
  kingbase   14 MB
  security   14 MB

inst.disk  (filesystem of data_directory)
  used   14 GB / 199 GB  (7%)
  free  185 GB
EXIT_CODE=2
  • 已用 98 个，超过了 97，因为超级用户还能从保留的连接里进来，kbdiag 自己用的 system 连接也在其中。
  • verify 行指向 sessions，它的汇总按用户、库、应用、客户端给连接计数。这次采样里能看到 kbdiag_ro 从 127.0.0.1 连进来 93 个 idle 会话。

备库没在收 WAL

这种情况还没在测试环境里造出来，下面的 finding 是从源码里摘的文字，不是实采。备库没有 WAL 接收进程时，status 报：

[WARN] inst.upstream  the standby has no WAL receiver and is not receiving WAL from the primary: if the primary fails now, no standby can take over
  verify: kbdiag slots  # run on the primary: is this standby's slot inactive?

有接收进程但状态不是 streaming 时，finding 里写的是那个状态。退出码是 1。

走 TCP 时

只有确定跑在数据库主机上，kbdiag 才读 inst.disk，即满足下面一条：

  • 走 Unix socket；
  • --host 是 localhost / 127.0.0.1 / ::1，并且 data_directory 在本机存在。要核对目录，是因为端口可能被转发到别的机器。

否则 inst.disk 是 not_applicable。下面用 kbdiag_ro 连主库自己的网络地址：

PGPASSWORD=... ~/kbdiag status --host 192.168.105.10 -U kbdiag_ro
echo EXIT_CODE=$?
status  OK  (KingbaseES V008R006C009B0014, primary, kbdiag_ro@remote, 2026-09-27T13:40:08+08:00)

inst.info
  version         V008R006C009B0014
  data_directory  /home/kingbase/cluster/install/kingbase/data
  port            54321
  start_time      2026-09-20 22:19:13  (up 6d 15h)
  connections     5 / 97  (max_connections 100 - superuser_reserved 3)

inst.downstreams: 1
  name   address         state      sync
  node2  192.168.105.11  streaming  quorum

inst.upstream: not_applicable  (primary)

inst.databases: 5, total 382 MB
  test      325 MB
  esrep      15 MB
  mydb       14 MB
  kingbase   14 MB
  security   14 MB

inst.disk: not_applicable  (remote connection)
EXIT_CODE=0

not_applicable 不影响结论。

权限不足时

kbdiag_ro 没有任何监控角色，但在 KingbaseES V8R6 上它照样能完整看到 sys_stat_replication、sys_stat_wal_receiver 和 data_directory，所以 status 给它的结果和 system 一样。能被挡住的只有库大小：对某个库没有 CONNECT 权限时，那个库的大小为空，并记进 redacted。库大小不参与判定，所以结论仍然是 OK，不是 UNKNOWN。

JSON

--json 保留原始值：大小是字节，时长是秒，版本是短版本号。inst.info 多一个 usable_connections，inst.disk 是 total_bytes、used_bytes、avail_bytes。不适用的 probe 是 "status": "not_applicable"，并带原因，比如 "primary" 或 "remote connection"。

退出码

退出码含义
0OK
1WARN：备库没在收 WAL
2FAIL：普通用户可用的连接已经占满
3UNKNOWN：有数据没采到
64参数错误
69连不上数据库

返回使用手册

最后修改 2026-10-07 · docs(v2): same back-link wording as the v0.1 pages (2be4ffd)