kbdiag · KingbaseES 命令行诊断 on kbdiag

sessions：列会话

Mon, 01 Jan 0001 00:00:00 +0000

采集于 2026-09-27（UTC+08），本地 KingbaseES V008R006C009B0014 主节点，数据库 test。工具是 Go 版源码提交 93bf65d 编译的 ~/kbdiag（linux/amd64 静态二进制）。这是测试环境实测，不代表生产环境验收。名为 kbdiag_inj_* 的业务会话是故障注入脚本造出来的。PID、计数与时间只属于本次采样。

读懂一次真实结果

Mon, 01 Jan 0001 00:00:00 +0000

采集于 2026-09-27（UTC+08），本地 KingbaseES V008R006C009B0014 主节点，数据库 test。工具是 Go 版源码提交 93bf65d 编译的 ~/kbdiag（linux/amd64 静态二进制）。这是测试环境实测，不代表生产环境验收。PID、计数与时间只属于本次采样。idle in transaction 的会话是故障注入脚本造出来的；用 --idle-in-txn-warn 5 把报警阈值降到 5 秒，免得例子要等默认的 300 秒。

找到长时间运行的 SQL

Mon, 01 Jan 0001 00:00:00 +0000

采集于 2026-09-27（UTC+08），本地 KingbaseES V008R006C009B0014 主节点，数据库 test。工具是 Go 版源码提交 93bf65d 编译的 ~/kbdiag（linux/amd64 静态二进制）。这是测试环境实测，不代表生产环境验收。PID、计数和时间只属于本次采样。故障注入脚本启动了 select pg_sleep(3600);，一条只睡觉的语句。它测的是能不能发现，不模拟 CPU 或磁盘压力。

session：单个会话

Mon, 01 Jan 0001 00:00:00 +0000

采集于 2026-09-27（UTC+08），本地 KingbaseES V008R006C009B0014 主节点，数据库 test。工具是 Go 版源码提交 93bf65d 编译的 ~/kbdiag（linux/amd64 静态二进制）。这是测试环境实测，不代表生产环境验收。示例里的会话是故障注入脚本造出来的：1045715 在 idle in transaction 状态下持有表 kbdiag_inj_lock 的排他锁，1045724 在等它，1045809 是另一个 idle in transaction 的会话。PID、计数与时间只属于本次采样。

排查锁等待

Mon, 01 Jan 0001 00:00:00 +0000

采集于 2026-09-27（UTC+08），本地 KingbaseES V008R006C009B0014 主节点，数据库 test。工具是 Go 版源码提交 93bf65d 编译的 ~/kbdiag（linux/amd64 静态二进制）。这是测试环境实测，不代表生产环境验收。PID、计数和时间只属于本次采样。故障注入脚本开了一个事务，对测试表加 ACCESS EXCLUSIVE 锁后停着不动；另一个会话去读这张表。

locks：锁等待

Mon, 01 Jan 0001 00:00:00 +0000

采集于 2026-09-27（UTC+08），本地 KingbaseES V008R006C009B0014 主节点和备节点，数据库 test。工具是 Go 版源码提交 93bf65d 编译的 ~/kbdiag（linux/amd64 静态二进制）。这是测试环境实测，不代表生产环境验收。锁等待是故障注入脚本造出来的。主库上，1045715 在 idle in transaction 状态下持有表 kbdiag_inj_lock 的排他锁，1045724 在等它；一个两阶段（prepared）事务持有 kbdiag_inj_2pc 上的锁，1046007 在等它。PID、计数与时间只属于本次采样。

txn：事务

Mon, 01 Jan 0001 00:00:00 +0000

采集于 2026-09-27（UTC+08），本地 KingbaseES V008R006C009B0014 主节点和备节点，数据库 test。工具是 Go 版源码提交 93bf65d 编译的 ~/kbdiag（linux/amd64 静态二进制）。这是测试环境实测，不代表生产环境验收。示例里的事务是故障注入脚本造出来的：两个 idle in transaction 的会话（其中一个持有表锁）、几个在等锁的会话、一个 pg_sleep(3600)，还有 kbdiag_inj_2pc，一个既没提交也没回滚的两阶段事务。PID、计数与时间只属于本次采样。

waits：等待事件

Mon, 01 Jan 0001 00:00:00 +0000

采集于 2026-09-27（UTC+08），本地 KingbaseES V008R006C009B0014 主节点和备节点，数据库 test。工具是 Go 版源码提交 93bf65d 编译的 ~/kbdiag（linux/amd64 静态二进制）。这是测试环境实测，不代表生产环境验收。示例里的会话是故障注入脚本造出来的：两个 idle in transaction 的会话、两个在等表锁的会话、一个 pg_sleep(3600)。PID、计数与时间只属于本次采样。

status：实例概况

Mon, 01 Jan 0001 00:00:00 +0000

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

slots：复制槽

Mon, 01 Jan 0001 00:00:00 +0000

采集于 2026-09-27（UTC+08），本地 KingbaseES V008R006C009B0014 主节点和备节点，数据库 test。工具是 Go 版源码提交 93bf65d 编译的 ~/kbdiag（linux/amd64 静态二进制）。这是测试环境实测，不代表生产环境验收。WARN 的例子由故障注入脚本造出来：它暂停（SIGSTOP）备库的 WAL 接收进程，过了 wal_sender_timeout（这里是 30 秒）后主库上的槽变成不活跃，和备库挂掉时一样。数值只属于本次采样。

space：磁盘、WAL、库大小

Mon, 01 Jan 0001 00:00:00 +0000

采集于 2026-10-07（UTC+08），本地 KingbaseES V008R006C009B0014 主节点和备节点，数据库 test。工具是 Go 版源码提交 96c874f 编译的 ~/kbdiag（linux/amd64 静态二进制）。这是测试环境实测，不代表生产环境验收。这一页的例子来自正常的实验环境，以及两个看不全的账号：没有监控角色的 kbdiag_ro，分别走 127.0.0.1 和节点的网络地址。这条命令没有做故障注入；它能报的那一条 FAIL 在实验环境里没有造出来（见最后一节）。数值只属于本次采样。

freeze：事务号回卷距离

Mon, 01 Jan 0001 00:00:00 +0000

采集于 2026-10-07（UTC+08），本地 KingbaseES V008R006C009B0014 主节点和备节点，数据库 test。工具是 Go 版源码提交 96c874f 编译的 ~/kbdiag（linux/amd64 静态二进制）。这是测试环境实测，不代表生产环境验收。两个节点都是正常状态，没有注入故障，所以例子全是 OK。WARN 和 FAIL 在实验环境里没有造出来（见最后一节）。数值只属于本次采样。

vacuum：死元组和 autovacuum

Mon, 01 Jan 0001 00:00:00 +0000

采集于 2026-10-07（UTC+08），本地 KingbaseES V008R006C009B0014 主节点和备节点，数据库 test。工具是 Go 版源码提交 96c874f 编译的 ~/kbdiag（linux/amd64 静态二进制）。这是测试环境实测，不代表生产环境验收。WARN 的例子由注入脚本造出来：它建了表 public.kbdiag_inj_dead，设为 autovacuum_enabled=off，插入 10000 行再删掉 5000 行，所以表里有 5000 个没人会清的死元组。数值只属于本次采样。

archive：WAL 归档

Mon, 01 Jan 0001 00:00:00 +0000

采集于 2026-10-07（UTC+08），本地 KingbaseES V008R006C009B0014 主节点和备节点，数据库 test。工具是 Go 版源码提交 96c874f 编译的 ~/kbdiag（linux/amd64 静态二进制）。这是测试环境实测，不代表生产环境验收。没有注入故障。主库的 WAL 归档在实验环境里本来就在失败（archive_command 调 sys_rman archive-push，最后一次成功在 21 天前），所以下面的 WARN 就是实验环境的真实状态；失败原因这一页没有去查，因为 kbdiag 不读服务器日志。数值只属于本次采样。

params：改过的参数

Mon, 01 Jan 0001 00:00:00 +0000

采集于 2026-10-07（UTC+08），本地 KingbaseES V008R006C009B0014 主节点和备节点，数据库 test。工具是 Go 版源码提交 96c874f 编译的 ~/kbdiag（linux/amd64 静态二进制）。这是测试环境实测，不代表生产环境验收。WARN 的例子由注入脚本造出来：它用 ALTER SYSTEM 改了 max_files_per_process（需要重启的参数），reload 了配置，没有重启，所以运行值和文件里的不一样。数值只属于本次采样。

repl：本节点看复制

Mon, 01 Jan 0001 00:00:00 +0000

采集于 2026-10-07（UTC+08），本地 KingbaseES V008R006C009B0014 主节点和备节点，数据库 test。工具是 Go 版源码提交 96c874f 编译的 ~/kbdiag（linux/amd64 静态二进制）。这是测试环境实测，不代表生产环境验收。WARN 的例子由故障注入脚本造出来：它暂停（SIGSTOP）备库的 WAL 接收进程，和 slots 页用的是同一个。数值只属于本次采样。

cluster：repmgr 眼里的集群

Mon, 01 Jan 0001 00:00:00 +0000

采集于 2026-10-07（UTC+08），本地 KingbaseES V008R006C009B0014 主节点和备节点，数据库 test。工具是 Go 版源码提交 96c874f 编译的 ~/kbdiag（linux/amd64 静态二进制）。这是测试环境实测，不代表生产环境验收。集群由 repmgr 管理，元数据在 esrep 库里。WARN 的例子由故障注入脚本造出来：它暂停（SIGSTOP）备库的 WAL 接收进程，直到备库不再挂在主库上，和 slots 页用的是同一个。数值只属于本次采样。

top-objects：最大的表和索引

Mon, 01 Jan 0001 00:00:00 +0000

采集于 2026-10-07（UTC+08），本地 KingbaseES V008R006C009B0014 主节点和备节点，数据库 test。工具是 Go 版源码提交 96c874f 编译的 ~/kbdiag（linux/amd64 静态二进制）。这是测试环境实测，不代表生产环境验收。没有注入故障。数值只属于本次采样。

table：一张表

Mon, 01 Jan 0001 00:00:00 +0000

采集于 2026-10-07（UTC+08），本地 KingbaseES V008R006C009B0014 主节点和备节点，数据库 test。工具是 Go 版源码提交 96c874f 编译的 ~/kbdiag（linux/amd64 静态二进制）。这是测试环境实测，不代表生产环境验收。两个例子由注入脚本造出来：public.kbdiag_inj_dead（设了 autovacuum_enabled=off，插入 10000 行、删除 5000 行）和 public.kbdiag_inj_tbl（插入 20000 行、删除 5000 行，带主键和另一个索引）。数值只属于本次采样。

top：累计 Top SQL

Mon, 01 Jan 0001 00:00:00 +0000

采集于 2026-10-07（UTC+08），本地 KingbaseES V008R006C009B0014 主节点和备节点，数据库 test。工具是 Go 版源码提交 96c874f 编译的 ~/kbdiag（linux/amd64 静态二进制）。这是测试环境实测，不代表生产环境验收。没有注入故障。实验环境两个节点上 sys_stat_statements.track 都是 none，没有在收集语句，top 没有行可显示。这一页展示的就是这种情况，也是实验环境的真实状态。统计开着的情况没有采到（见最后一节）。

progress：长操作进度

Mon, 01 Jan 0001 00:00:00 +0000

采集于 2026-10-07（UTC+08），本地 KingbaseES V008R006C009B0014 主节点和备节点，数据库 test。工具是 Go 版源码提交 96c874f 编译的 ~/kbdiag（linux/amd64 静态二进制）。这是测试环境实测，不代表生产环境验收。进行中的例子由注入脚本造出来：它在 public.orders（100 万行）上跑 CREATE INDEX，运行期间读了三次，其中一次用 kbdiag_ro。PID 和时间只属于本次采样。

checkpoint：检查点

Mon, 01 Jan 0001 00:00:00 +0000

wal：WAL 位置和谁让它留着

Mon, 01 Jan 0001 00:00:00 +0000

seq：序列

Mon, 01 Jan 0001 00:00:00 +0000

采集于 2026-10-07（UTC+08），本地 KingbaseES V008R006C009B0014 主节点和备节点，数据库 test。工具是 Go 版源码提交 96c874f 编译的 ~/kbdiag（linux/amd64 静态二进制）。这是测试环境实测，不代表生产环境验收。FAIL 的例子由注入脚本造出来：它建了 public.kbdiag_inj_seq（maxvalue 3），再用 nextval 把它用完。数值只属于本次采样。