TDengine 集群异常恢复实战用 KILL 终止连接、查询与事务并重置查询缓存【免费下载链接】tdengineTDengine is an open source, high-performance, cloud native time-series database optimized for Internet of Things (IoT), Connected Cars, Industrial IoT and DevOps.项目地址: https://gitcode.com/taosdata/tdengine在复杂应用场景中TDengine 集群内的连接或查询任务可能进入错误状态或因资源争抢而耗时过长、迟迟无法结束。此时若不及时干预会持续占用连接句柄、查询执行资源甚至元数据事务锁影响整个集群的正常读写。本文基于 TDengine 集群管理文档系统讲解KILL CONNECTION、KILL QUERY、KILL TRANSACTION与RESET QUERY CACHE四条恢复指令的语法、配套状态查询命令SHOW CONNECTIONS/SHOW QUERIES/SHOW TRANSACTIONS、底层实现原理与权限要求帮助你快速定位问题对象并将系统恢复到正常状态。异常恢复的适用场景与整体思路在 TDengine 中以下情况会触发“异常恢复”诉求客户端连接挂起或异常退出但仍被服务端记录为活跃连接查询含写入与删除任务执行时间异常、长时间不返回挤占 vnode/qnode 执行线程元数据级事务因网络抖动或节点异常卡在某个阶段如redoAction、undoAction导致后续 DDL 无法执行多客户端共享元数据时客户端本地缓存的元数据与集群实际状态不一致。恢复手段分为两类终止类KILL 系列用于打断异常的执行单元重置类RESET QUERY CACHE用于清理客户端侧的元数据缓存使其重新从服务端同步。使用 KILL 系列命令前通常先用 SHOW 系列命令查询目标 ID再执行对应终止语句形成“先查后杀”的标准流程。终止连接KILL CONNECTION当某个客户端连接处于异常状态、不再响应或其占用需要被强制回收时使用如下语句KILL CONNECTION conn_id;conn_id为连接 ID无符号整型可通过SHOW CONNECTIONS查询获得SHOW CONNECTIONS;SHOW CONNECTIONS输出当前系统中全部连接的信息完整字段与PERF_CONNECTIONS一致常用列如下字段类型说明conn_idUINT连接 ID即KILL CONNECTION所需的参数userBINARY(24)用户名关键字列查询时需用反引号转义appBINARY(24)客户端名称pidUINT发起连接的客户端进程 IDend_pointBINARY(134)客户端地址login_time/last_accessTIMESTAMP登录时间 / 最后访问时间typeBINARY(16)连接类型tokenBINARY(32)若以 Token 登录显示 Token 名从源码看KILL CONNECTION的请求在 mnode 中由mndProcessKillConnReq处理先校验操作权限对应MND_OPER_KILL_CONN再根据conn_id从连接缓存connCache中定位连接对象将标志位killed置 1此后该连接在心跳heartbeat交互中会收到killConnection 1的响应并被强制关闭见 mndProfile.c 中关于被 kill 连接的处理逻辑。这也意味着被终止的连接是由服务端在后续心跳或请求交互中回收的而不是请求到达瞬间物理断开。终止查询KILL QUERY当某条查询或写入、删除任务执行时间过长、无法结束或不再需要其结果时使用KILL QUERY kill_id;注意kill_id是字符串字面量需使用单引号包裹它可通过SHOW QUERIES获取SHOW QUERIES;SHOW QUERIES展示当前系统中正在进行中的写入更新、查询与删除操作因内部 API 命名统称QUERIES其字段与PERF_QUERIES一致其中与终止操作直接相关的字段如下字段类型说明kill_idVARCHAR(26)专用于KILL QUERY的任务 IDquery_idUBIGINT查询 IDconn_idUINT所属连接 IDuser/app/pid/end_point—发起者信息用户名、应用名、进程 ID、客户端地址create_time/exec_usecTIMESTAMP / BIGINT创建时间 / 已执行时长微秒sqlVARCHAR(2048)SQL 语句关键字列查询时需用反引号转义phase_state/phase_start_timeVARCHAR(64) / TIMESTAMP当前查询阶段 / 阶段开始时间从实现看kill_id实际编码了“连接 ID 与查询 ID”的组合mnode 侧的mndProcessKillQueryReq在收到请求后会以:为分隔符解析kill_id前半部分按十六进制解析为connId后半部分解析为queryId因此查询结果中展示的kill_id形如十六进制connId:十六进制queryId。解析成功后mnode 将queryId写入对应连接对象的killId字段之后随心跳响应rspBasic-killRid下发到客户端或相应执行节点使目标查询被取消见 mndProfile.c。提示KILL QUERY的字符串参数具有特定格式建议直接从SHOW QUERIES结果中复制kill_id避免手工拼接出错。终止事务KILL TRANSACTIONTDengine 的元数据操作除普通表操作外的元数据级变更以事务方式执行。当某个元数据事务卡死或失败无法自行结束、阻塞后续操作时使用KILL TRANSACTION trans_id;trans_id为事务 ID整型可通过SHOW TRANSACTIONS获取SHOW TRANSACTIONS;SHOW TRANSACTIONS展示当前正在执行的元数据事务列表对应信息表为INS_TRANSACTIONS/PERF_TRANS关键列包括字段类型说明idBIGINT事务 ID即KILL TRANSACTION所需的参数create_timeTIMESTAMP事务创建时间stageVARCHAR(12)当前阶段例如redoAction重做动作、undoAction回滚动作、commit提交操作对象 / 失败次数 / 最近执行详情—事务针对的操作目标、累计失败次数与最近一次执行信息若要查看某个事务内部各动作的详细信息可执行SHOW TRANSACTION transaction_id;其输出对应INS_TRANSACTION_DETAILS用于在终止前判断该事务当前卡在哪个动作上。结合 01-meta.md 中的INS_TRANSACTION_ORPHANS信息还可以辅助识别孤儿事务。此外mnode 在心跳通知中通过HEARTBEAT_KEY_TXN_KILLED将事务被终止/超时回滚的消息同步给客户端见 mndProfile.c保证客户端与服务端对事务状态的认知一致。重置客户端缓存RESET QUERY CACHE多客户端环境下如果出现元数据不同步问题例如客户端 A 创建了表/库客户端 B 仍然查询不到或执行计划使用了过期元数据可以使用RESET QUERY CACHE;该命令用于强制清空客户端缓存执行后客户端会从服务端重新拉取最新元数据。它属于本地命令类语句在语法树构建阶段由createResetQueryCacheStmt生成QUERY_NODE_RESET_QUERY_CACHE_STMT节点语法定义见 sql.y最终在命令执行入口qExecCommand中被分发到execResetQueryCache进而调用catalogClearCache()见 catalog.c将 catalog 缓存整体入队清空。从客户端分类逻辑看RESET QUERY CACHE在 clientImpl.c 中被归类为TXN_STMT_NON_DDL即它不会被计入写事务、不参与 DDL 事务流程可以在任意时刻安全执行而不会与正在进行的写入产生事务冲突。权限要求与使用建议上述恢复命令均受权限控制。从语法定义sql.y看权限类型与语句的对应关系如下语句权限类型KILL集群管理级PRIV_CM_KILLKILL CONNECTIONPRIV_CONN_KILLKILL QUERYPRIV_QUERY_KILLKILL TRANSACTIONPRIV_TRANS_KILL也就是说执行 KILL 类语句需要管理员通过GRANT授予对应权限无权限用户执行时会返回权限错误。RESET QUERY CACHE属于本地缓存清理指令执行门槛较低但同样建议由具备相应管理权限的用户操作。实际运维建议先查询、后终止一律先执行SHOW CONNECTIONS/SHOW QUERIES/SHOW TRANSACTIONS确认目标 ID确认其确实属于异常或不再需要的对象后再执行 KILL避免误杀正常业务关注执行时长通过PERF_QUERIES的exec_usec与phase_state判断查询是否长期停留在某一阶段优先终止长时间卡住的查询事务终止前查看动作明细对卡死的元数据事务先用SHOW TRANSACTION trans_id查看其执行到哪一步判断是否值得终止缓存重置作为兜底当多客户端元数据不一致且无法通过正常同步解决时再执行RESET QUERY CACHE它不会影响正在进行的数据读写。小结恢复指令速查场景查询目标 ID恢复语句连接异常/占用SHOW CONNECTIONS03-show.mdKILL CONNECTION conn_id;查询/写入/删除卡住SHOW QUERIES03-show.mdKILL QUERY kill_id;元数据事务卡死SHOW TRANSACTIONS03-show.mdKILL TRANSACTION trans_id;客户端元数据不同步—RESET QUERY CACHE;上述命令在 TDengine 中有着完整的“语法解析 — 权限校验 — mnode 处理 — 心跳/请求同步”实现链路语法规则集中在 sql.y连接与查询的终止逻辑见 mndProfile.c缓存重置链路见 command.c 与 catalog.c。当你面对一个“杀不掉、查不动、改不了”的集群异常时按照“查 ID → KILL / RESET”的顺序即可快速恢复系统正常状态。此外语法中还支持KILL COMPACT、KILL RETENTION、KILL SCAN、KILL SSMIGRATE等面向后台维护任务的终止语句sql.y可结合具体运维场景选用。【免费下载链接】tdengineTDengine is an open source, high-performance, cloud native time-series database optimized for Internet of Things (IoT), Connected Cars, Industrial IoT and DevOps.项目地址: https://gitcode.com/taosdata/tdengine创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
TDengine 集群异常恢复实战用 KILL 终止连接、查询与事务并重置查询缓存【免费下载链接】tdengineTDengine is an open source, high-performance, cloud native time-series database optimized for Internet of Things (IoT), Connected Cars, Industrial IoT and DevOps.项目地址: https://gitcode.com/taosdata/tdengine在复杂应用场景中TDengine 集群内的连接或查询任务可能进入错误状态或因资源争抢而耗时过长、迟迟无法结束。此时若不及时干预会持续占用连接句柄、查询执行资源甚至元数据事务锁影响整个集群的正常读写。本文基于 TDengine 集群管理文档系统讲解KILL CONNECTION、KILL QUERY、KILL TRANSACTION与RESET QUERY CACHE四条恢复指令的语法、配套状态查询命令SHOW CONNECTIONS/SHOW QUERIES/SHOW TRANSACTIONS、底层实现原理与权限要求帮助你快速定位问题对象并将系统恢复到正常状态。异常恢复的适用场景与整体思路在 TDengine 中以下情况会触发“异常恢复”诉求客户端连接挂起或异常退出但仍被服务端记录为活跃连接查询含写入与删除任务执行时间异常、长时间不返回挤占 vnode/qnode 执行线程元数据级事务因网络抖动或节点异常卡在某个阶段如redoAction、undoAction导致后续 DDL 无法执行多客户端共享元数据时客户端本地缓存的元数据与集群实际状态不一致。恢复手段分为两类终止类KILL 系列用于打断异常的执行单元重置类RESET QUERY CACHE用于清理客户端侧的元数据缓存使其重新从服务端同步。使用 KILL 系列命令前通常先用 SHOW 系列命令查询目标 ID再执行对应终止语句形成“先查后杀”的标准流程。终止连接KILL CONNECTION当某个客户端连接处于异常状态、不再响应或其占用需要被强制回收时使用如下语句KILL CONNECTION conn_id;conn_id为连接 ID无符号整型可通过SHOW CONNECTIONS查询获得SHOW CONNECTIONS;SHOW CONNECTIONS输出当前系统中全部连接的信息完整字段与PERF_CONNECTIONS一致常用列如下字段类型说明conn_idUINT连接 ID即KILL CONNECTION所需的参数userBINARY(24)用户名关键字列查询时需用反引号转义appBINARY(24)客户端名称pidUINT发起连接的客户端进程 IDend_pointBINARY(134)客户端地址login_time/last_accessTIMESTAMP登录时间 / 最后访问时间typeBINARY(16)连接类型tokenBINARY(32)若以 Token 登录显示 Token 名从源码看KILL CONNECTION的请求在 mnode 中由mndProcessKillConnReq处理先校验操作权限对应MND_OPER_KILL_CONN再根据conn_id从连接缓存connCache中定位连接对象将标志位killed置 1此后该连接在心跳heartbeat交互中会收到killConnection 1的响应并被强制关闭见 mndProfile.c 中关于被 kill 连接的处理逻辑。这也意味着被终止的连接是由服务端在后续心跳或请求交互中回收的而不是请求到达瞬间物理断开。终止查询KILL QUERY当某条查询或写入、删除任务执行时间过长、无法结束或不再需要其结果时使用KILL QUERY kill_id;注意kill_id是字符串字面量需使用单引号包裹它可通过SHOW QUERIES获取SHOW QUERIES;SHOW QUERIES展示当前系统中正在进行中的写入更新、查询与删除操作因内部 API 命名统称QUERIES其字段与PERF_QUERIES一致其中与终止操作直接相关的字段如下字段类型说明kill_idVARCHAR(26)专用于KILL QUERY的任务 IDquery_idUBIGINT查询 IDconn_idUINT所属连接 IDuser/app/pid/end_point—发起者信息用户名、应用名、进程 ID、客户端地址create_time/exec_usecTIMESTAMP / BIGINT创建时间 / 已执行时长微秒sqlVARCHAR(2048)SQL 语句关键字列查询时需用反引号转义phase_state/phase_start_timeVARCHAR(64) / TIMESTAMP当前查询阶段 / 阶段开始时间从实现看kill_id实际编码了“连接 ID 与查询 ID”的组合mnode 侧的mndProcessKillQueryReq在收到请求后会以:为分隔符解析kill_id前半部分按十六进制解析为connId后半部分解析为queryId因此查询结果中展示的kill_id形如十六进制connId:十六进制queryId。解析成功后mnode 将queryId写入对应连接对象的killId字段之后随心跳响应rspBasic-killRid下发到客户端或相应执行节点使目标查询被取消见 mndProfile.c。提示KILL QUERY的字符串参数具有特定格式建议直接从SHOW QUERIES结果中复制kill_id避免手工拼接出错。终止事务KILL TRANSACTIONTDengine 的元数据操作除普通表操作外的元数据级变更以事务方式执行。当某个元数据事务卡死或失败无法自行结束、阻塞后续操作时使用KILL TRANSACTION trans_id;trans_id为事务 ID整型可通过SHOW TRANSACTIONS获取SHOW TRANSACTIONS;SHOW TRANSACTIONS展示当前正在执行的元数据事务列表对应信息表为INS_TRANSACTIONS/PERF_TRANS关键列包括字段类型说明idBIGINT事务 ID即KILL TRANSACTION所需的参数create_timeTIMESTAMP事务创建时间stageVARCHAR(12)当前阶段例如redoAction重做动作、undoAction回滚动作、commit提交操作对象 / 失败次数 / 最近执行详情—事务针对的操作目标、累计失败次数与最近一次执行信息若要查看某个事务内部各动作的详细信息可执行SHOW TRANSACTION transaction_id;其输出对应INS_TRANSACTION_DETAILS用于在终止前判断该事务当前卡在哪个动作上。结合 01-meta.md 中的INS_TRANSACTION_ORPHANS信息还可以辅助识别孤儿事务。此外mnode 在心跳通知中通过HEARTBEAT_KEY_TXN_KILLED将事务被终止/超时回滚的消息同步给客户端见 mndProfile.c保证客户端与服务端对事务状态的认知一致。重置客户端缓存RESET QUERY CACHE多客户端环境下如果出现元数据不同步问题例如客户端 A 创建了表/库客户端 B 仍然查询不到或执行计划使用了过期元数据可以使用RESET QUERY CACHE;该命令用于强制清空客户端缓存执行后客户端会从服务端重新拉取最新元数据。它属于本地命令类语句在语法树构建阶段由createResetQueryCacheStmt生成QUERY_NODE_RESET_QUERY_CACHE_STMT节点语法定义见 sql.y最终在命令执行入口qExecCommand中被分发到execResetQueryCache进而调用catalogClearCache()见 catalog.c将 catalog 缓存整体入队清空。从客户端分类逻辑看RESET QUERY CACHE在 clientImpl.c 中被归类为TXN_STMT_NON_DDL即它不会被计入写事务、不参与 DDL 事务流程可以在任意时刻安全执行而不会与正在进行的写入产生事务冲突。权限要求与使用建议上述恢复命令均受权限控制。从语法定义sql.y看权限类型与语句的对应关系如下语句权限类型KILL集群管理级PRIV_CM_KILLKILL CONNECTIONPRIV_CONN_KILLKILL QUERYPRIV_QUERY_KILLKILL TRANSACTIONPRIV_TRANS_KILL也就是说执行 KILL 类语句需要管理员通过GRANT授予对应权限无权限用户执行时会返回权限错误。RESET QUERY CACHE属于本地缓存清理指令执行门槛较低但同样建议由具备相应管理权限的用户操作。实际运维建议先查询、后终止一律先执行SHOW CONNECTIONS/SHOW QUERIES/SHOW TRANSACTIONS确认目标 ID确认其确实属于异常或不再需要的对象后再执行 KILL避免误杀正常业务关注执行时长通过PERF_QUERIES的exec_usec与phase_state判断查询是否长期停留在某一阶段优先终止长时间卡住的查询事务终止前查看动作明细对卡死的元数据事务先用SHOW TRANSACTION trans_id查看其执行到哪一步判断是否值得终止缓存重置作为兜底当多客户端元数据不一致且无法通过正常同步解决时再执行RESET QUERY CACHE它不会影响正在进行的数据读写。小结恢复指令速查场景查询目标 ID恢复语句连接异常/占用SHOW CONNECTIONS03-show.mdKILL CONNECTION conn_id;查询/写入/删除卡住SHOW QUERIES03-show.mdKILL QUERY kill_id;元数据事务卡死SHOW TRANSACTIONS03-show.mdKILL TRANSACTION trans_id;客户端元数据不同步—RESET QUERY CACHE;上述命令在 TDengine 中有着完整的“语法解析 — 权限校验 — mnode 处理 — 心跳/请求同步”实现链路语法规则集中在 sql.y连接与查询的终止逻辑见 mndProfile.c缓存重置链路见 command.c 与 catalog.c。当你面对一个“杀不掉、查不动、改不了”的集群异常时按照“查 ID → KILL / RESET”的顺序即可快速恢复系统正常状态。此外语法中还支持KILL COMPACT、KILL RETENTION、KILL SCAN、KILL SSMIGRATE等面向后台维护任务的终止语句sql.y可结合具体运维场景选用。【免费下载链接】tdengineTDengine is an open source, high-performance, cloud native time-series database optimized for Internet of Things (IoT), Connected Cars, Industrial IoT and DevOps.项目地址: https://gitcode.com/taosdata/tdengine创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
` 方法)
