ScyllaDB Nodetool tasks wait 详解等待后台任务完成并获取任务状态【免费下载链接】scylladbNoSQL data store using the Seastar framework, compatible with Apache Cassandra and Amazon DynamoDB项目地址: https://gitcode.com/GitHub_Trending/sc/scylladbnodetool tasks wait是 ScyllaDB 任务管理器Task Manager系列命令中的一个核心子命令用于阻塞等待某个任务管理器任务运行结束并获取该任务的最终状态。它适用于 repair、compaction 等长时运行的后台操作——在脚本或自动化流程中你往往需要等一个任务真正做完而不是仅仅发起任务才能继续下一步。读完本文你将掌握tasks wait的完整语法、全部参数、退出码语义、输出字段含义以及它与其他nodetool tasks子命令status / list / tree / abort的配合方式。命令概览与适用场景任务管理器Task Manager是 ScyllaDB 提供的、基于 API 的可观测与控制机制用于跟踪 repair、compaction 等长时运行的后台操作使其可观察、可控制并且按节点per node运行参见 tasks/index.rst。nodetool tasks wait task_id的作用正如其名——等待它会一直等到指定任务完成然后把任务的完整状态打印出来。如果设置了超时timeout且超时到期命令会打印带有失败原因的提示消息。典型使用场景脚本化运维提交一个nodetool repair后紧接着调用nodetool tasks wait task_id让脚本在任务真正结束后再继续执行后续逻辑如备份、验证、下一轮操作。CI/CD 流水线用--quiet模式配合退出码将任务结果直接映射为流水线的成功/失败判定。故障排查结合tasks status与tasks tree先定位任务 ID再等待并观察其最终状态与子任务信息。语法与参数nodetool tasks wait的标准语法如下来源tasks/wait.rstnodetool tasks wait task_id [(--quiet|-q)] [--timeout time_in_second]参数缩写含义task_id—要等待的任务的唯一标识UUID例如ef1b7a61-66c8-494c-bb03-6f65724e6eee--quiet-q不打印任务状态改为通过进程退出码反映结果详见下文退出码语义--timeout time_in_second—等待超时时间秒。超时到期后命令会打印带失败原因的消息并终止退出码语义--quiet模式当指定--quiet或-q时命令不再输出任务状态文本而是返回以下退出码方便脚本直接判断结果退出码含义0任务成功完成123任务失败124请求超时125发生错误任务状态无法确定这套退出码设计与timeout命令的退出码约定保持一致124 表示超时便于运维人员直觉理解。在 shell 脚本中可以直接用if nodetool tasks wait task_id -q; then ...这样的写法判断任务成败。使用示例基础用法等待并查看状态最简单的用法是不带任何额外参数等待任务结束并打印其完整状态 nodetool tasks wait ef1b7a61-66c8-494c-bb03-6f65724e6eee带超时等待如果任务可能运行很长时间建议显式设置超时避免命令无限期阻塞 nodetool tasks wait ef1b7a61-66c8-494c-bb03-6f65724e6eee --timeout 3600超时以秒为单位。超时到期后命令会打印带有失败原因的消息例如与 HTTP 请求超时对应的错误信息。静默模式脚本友好在自动化脚本中通常只需要结果而不需要冗长的状态输出nodetool tasks wait ef1b7a61-66c8-494c-bb03-6f65724e6eee --quiet配合退出码使用nodetool tasks wait $TASK_ID -q rc$? case $rc in 0) echo task succeeded ;; 123) echo task failed ;; 124) echo task timed out ;; 125) echo task status undetermined ;; esac输出字段逐项解读nodetool tasks wait成功完成后会打印任务的完整状态信息。以下是文档中的示例输出来源tasks/wait.rstid : 29dd6552-1e9a-4f17-b2c9-231d088fbee6 type : repair kind : node scope : keyspace state : done is_abortable : true start_time : 2024-07-29T17:00:53Z end_time : 2024-07-29T17:00:53Z error : parent_id : none sequence_number : 2 shard : 0 keyspace : abc table : entity : progress_units : ranges progress_total : 4 progress_completed : 4 children_ids : [{task_id: 5d74a62e-aaf6-4993-b0f1-973899d89cd0, node: 127.0.0.1 }, {task_id: 055d5a59-d97c-45a8-a7e6-dcad39ed61ca, node: 127.0.0.1 }]各字段含义如下字段含义id任务唯一标识UUIDtype任务类型如repair、compactionoffstrategy compaction等kind任务层级node表示节点级任务shard表示分片级子任务scope任务作用域如keyspace键空间级、shard分片级state任务状态created已创建、running运行中、done已完成、failed失败等is_abortable该任务是否可中止决定nodetool tasks abort是否可用start_time/end_time任务开始 / 结束时间ISO 8601 格式UTC。未结束时end_time为空error失败原因为空表示无错误parent_id父任务 ID顶层任务为nonesequence_number任务在节点上的序号同一模块内递增shard任务所在 CPU 分片编号keyspace/table/entity任务作用的键空间、表、实体progress_units进度单位如ranges范围数progress_total/progress_completed总工作量 / 已完成工作量可用于计算进度百分比children_ids子任务列表含 task_id 与所在节点体现任务的父子层级一个状态输出中的父子层级从上述示例可以看到一个repair节点级任务scope 为keyspace会派生出两个shard级子任务分别落在127.0.0.1节点的 shard 0 与 shard 1 上。这与 tasks/tree.rst 中展示的结构一致——tasks tree会按 BFS 顺序列出任务及其全部后代的状态而tasks wait只聚焦你指定的那一个任务。底层实现任务状态从哪里来nodetool tasks wait最终通过 ScyllaDB 的 HTTP API 与任务管理器交互。在源码中对应的 REST 端点是wait_task实现在 api/task_manager.cctm::wait_task.set(r, [tm, gossiper] (std::unique_ptrhttp::request req) - futurejson::json_return_type { auto id tasks::task_id{utils::UUID{req-get_path_param(task_id)}}; tasks::task_status status; std::optionalstd::chrono::seconds timeout std::nullopt; if (auto param req-get_query_param(timeout); !param.empty()) { timeout std::chrono::seconds(boost::lexical_castuint32_t(param)); } try { auto task tasks::task_handler{tm.local(), id}; status co_await task.wait_for_task(timeout); } catch (tasks::task_manager::task_not_found e) { throw bad_param_exception(e.what()); } catch (timed_out_error e) { throw httpd::base_exception{e.what(), http::reply::status_type::request_timeout}; } co_return make_status(status, gossiper); });从源码可以看出几个关键实现事实超时参数解析timeout查询参数通过boost::lexical_castuint32_t解析为秒未传时timeout为std::nullopt即无限等待。任务不存在若传入的task_id不存在会抛出task_manager::task_not_found对应 HTTP 400bad_param_exception。超时处理wait_for_task(timeout)超时后抛出timed_out_error映射为 HTTP 408request_timeout——这与 nodetool 侧--quiet模式下退出码124超时的语义一一对应。状态序列化最终通过make_status(status, gossiper)生成包含节点信息children_ids中的 node 字段即来自 gossiper的完整状态。类似地api/task_manager.cc 中的abort_task端点实现了nodetool tasks abort的底层逻辑调用task.abort()若任务不可中止则抛出task_not_abortable映射为 HTTP 403。状态保留时间与相关配置任务完成后其状态不会永久保存在节点上。根据 tasks/index.rst 的说明任务完成时其状态会临时存储在执行该任务的节点上状态信息最多保留task_ttl_in_seconds秒。在 db/config.cc 中可以找到该配置的默认值定义, task_ttl_seconds(this, task_ttl_in_seconds, liveness::LiveUpdate, value_status::Used, 0, Time for which information about finished task started internally stays in memory.) , user_task_ttl_seconds(this, user_task_ttl_in_seconds, liveness::LiveUpdate, value_status::Used, 3600, Time for which information about finished task started by user stays in memory.)即task_ttl_in_seconds内部任务完成后的保留时间默认0立即注销user_task_ttl_in_seconds用户发起的任务完成后的保留时间默认3600秒1 小时。两者均为LiveUpdate属性可在线更新。相关运行时查看/修改方式参见 tasks/ttl.rst 与 tasks/user-ttl.rst# 查看当前内部任务保留时长 nodetool tasks ttl # 将内部任务保留时长设为 10 秒仅内存生效不持久化 nodetool tasks ttl --set 10需要注意nodetool tasks ttl --set只在内存中生效要永久修改需调整scylla.yaml中的task_ttl_in_seconds或在启动 Scylla 时使用--task-ttl-in-seconds参数。对tasks wait的实际影响如果在任务完成之前、任务状态已因 TTL 到期被注销wait_for_task会抛出task_not_found。因此在使用tasks wait等待长任务时应确保任务尚在保留期内或合理配置 TTL 值。与其它 tasks 子命令的配合tasks wait是整个任务管理器命令家族的一员完整列表见 tasks/index.rst在实践中常与以下命令组合使用子命令作用配合场景tasks list module列出某模块如repair、compaction下的任务先列出任务拿到task_id再用tasks wait等待目标任务。modules子命令可查看支持的模块列表tasks status task_id获取单个任务当前状态不等待任务还在运行时轮询其状态或任务已完成但未记录结束时间时核实tasks tree [task_id]获取任务及其全部后代状态BFS 顺序分析父任务与 shard 子任务的整体完成情况tasks abort task_id中止可中止is_abortable: true的任务等太久不想等了先中止再配合tasks wait确认状态tasks drain [--module module]注销模块中所有已完成的本地任务清理陈旧任务状态释放内存典型的提交 → 等待 → 验证工作流如下# 1. 查看支持的模块 nodetool tasks modules # 输出示例repair / compaction # 2. 列出 repair 模块的任务找到目标 task_id nodetool tasks list repair --internal -ks myks --table mytable # 3. 等待该任务完成静默模式按退出码判断结果 nodetool tasks wait task_id --quiet # 4. 若超时或失败可中止任务并用 tree 检查整体状态 nodetool tasks abort task_id nodetool tasks tree task_idtasks list的常用过滤参数详见 tasks/list.rst包括--internal列出内部任务、--keyspace/-ks、--table/-t、--interval周期性重复列出与--iterations/-i重复次数。例如每 5 秒重复列出 compaction 任务 3 次nodetool tasks list compaction --interval 5 --i 3小结nodetool tasks wait是 ScyllaDB 任务管理器中面向确定性结果的关键工具它把任务是否真正完成从人工轮询tasks status中解放出来通过一次调用即可阻塞等待并返回最终状态--quiet模式下的退出码约定0/123/124/125使其天然适合嵌入 shell 脚本与自动化流水线。配合tasks list定位任务、tasks tree观察层级、tasks abort中止失控任务以及task_ttl_in_seconds/user_task_ttl_in_seconds的保留期配置运维人员可以完整地掌控 repair、compaction 等长时后台任务的整个生命周期。【免费下载链接】scylladbNoSQL data store using the Seastar framework, compatible with Apache Cassandra and Amazon DynamoDB项目地址: https://gitcode.com/GitHub_Trending/sc/scylladb创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 ScyllaDB Nodetool tasks wait 详解：等待后台任务完成并获取任务状态
ScyllaDB Nodetool tasks wait 详解等待后台任务完成并获取任务状态【免费下载链接】scylladbNoSQL data store using the Seastar framework, compatible with Apache Cassandra and Amazon DynamoDB项目地址: https://gitcode.com/GitHub_Trending/sc/scylladbnodetool tasks wait是 ScyllaDB 任务管理器Task Manager系列命令中的一个核心子命令用于阻塞等待某个任务管理器任务运行结束并获取该任务的最终状态。它适用于 repair、compaction 等长时运行的后台操作——在脚本或自动化流程中你往往需要等一个任务真正做完而不是仅仅发起任务才能继续下一步。读完本文你将掌握tasks wait的完整语法、全部参数、退出码语义、输出字段含义以及它与其他nodetool tasks子命令status / list / tree / abort的配合方式。命令概览与适用场景任务管理器Task Manager是 ScyllaDB 提供的、基于 API 的可观测与控制机制用于跟踪 repair、compaction 等长时运行的后台操作使其可观察、可控制并且按节点per node运行参见 tasks/index.rst。nodetool tasks wait task_id的作用正如其名——等待它会一直等到指定任务完成然后把任务的完整状态打印出来。如果设置了超时timeout且超时到期命令会打印带有失败原因的提示消息。典型使用场景脚本化运维提交一个nodetool repair后紧接着调用nodetool tasks wait task_id让脚本在任务真正结束后再继续执行后续逻辑如备份、验证、下一轮操作。CI/CD 流水线用--quiet模式配合退出码将任务结果直接映射为流水线的成功/失败判定。故障排查结合tasks status与tasks tree先定位任务 ID再等待并观察其最终状态与子任务信息。语法与参数nodetool tasks wait的标准语法如下来源tasks/wait.rstnodetool tasks wait task_id [(--quiet|-q)] [--timeout time_in_second]参数缩写含义task_id—要等待的任务的唯一标识UUID例如ef1b7a61-66c8-494c-bb03-6f65724e6eee--quiet-q不打印任务状态改为通过进程退出码反映结果详见下文退出码语义--timeout time_in_second—等待超时时间秒。超时到期后命令会打印带失败原因的消息并终止退出码语义--quiet模式当指定--quiet或-q时命令不再输出任务状态文本而是返回以下退出码方便脚本直接判断结果退出码含义0任务成功完成123任务失败124请求超时125发生错误任务状态无法确定这套退出码设计与timeout命令的退出码约定保持一致124 表示超时便于运维人员直觉理解。在 shell 脚本中可以直接用if nodetool tasks wait task_id -q; then ...这样的写法判断任务成败。使用示例基础用法等待并查看状态最简单的用法是不带任何额外参数等待任务结束并打印其完整状态 nodetool tasks wait ef1b7a61-66c8-494c-bb03-6f65724e6eee带超时等待如果任务可能运行很长时间建议显式设置超时避免命令无限期阻塞 nodetool tasks wait ef1b7a61-66c8-494c-bb03-6f65724e6eee --timeout 3600超时以秒为单位。超时到期后命令会打印带有失败原因的消息例如与 HTTP 请求超时对应的错误信息。静默模式脚本友好在自动化脚本中通常只需要结果而不需要冗长的状态输出nodetool tasks wait ef1b7a61-66c8-494c-bb03-6f65724e6eee --quiet配合退出码使用nodetool tasks wait $TASK_ID -q rc$? case $rc in 0) echo task succeeded ;; 123) echo task failed ;; 124) echo task timed out ;; 125) echo task status undetermined ;; esac输出字段逐项解读nodetool tasks wait成功完成后会打印任务的完整状态信息。以下是文档中的示例输出来源tasks/wait.rstid : 29dd6552-1e9a-4f17-b2c9-231d088fbee6 type : repair kind : node scope : keyspace state : done is_abortable : true start_time : 2024-07-29T17:00:53Z end_time : 2024-07-29T17:00:53Z error : parent_id : none sequence_number : 2 shard : 0 keyspace : abc table : entity : progress_units : ranges progress_total : 4 progress_completed : 4 children_ids : [{task_id: 5d74a62e-aaf6-4993-b0f1-973899d89cd0, node: 127.0.0.1 }, {task_id: 055d5a59-d97c-45a8-a7e6-dcad39ed61ca, node: 127.0.0.1 }]各字段含义如下字段含义id任务唯一标识UUIDtype任务类型如repair、compactionoffstrategy compaction等kind任务层级node表示节点级任务shard表示分片级子任务scope任务作用域如keyspace键空间级、shard分片级state任务状态created已创建、running运行中、done已完成、failed失败等is_abortable该任务是否可中止决定nodetool tasks abort是否可用start_time/end_time任务开始 / 结束时间ISO 8601 格式UTC。未结束时end_time为空error失败原因为空表示无错误parent_id父任务 ID顶层任务为nonesequence_number任务在节点上的序号同一模块内递增shard任务所在 CPU 分片编号keyspace/table/entity任务作用的键空间、表、实体progress_units进度单位如ranges范围数progress_total/progress_completed总工作量 / 已完成工作量可用于计算进度百分比children_ids子任务列表含 task_id 与所在节点体现任务的父子层级一个状态输出中的父子层级从上述示例可以看到一个repair节点级任务scope 为keyspace会派生出两个shard级子任务分别落在127.0.0.1节点的 shard 0 与 shard 1 上。这与 tasks/tree.rst 中展示的结构一致——tasks tree会按 BFS 顺序列出任务及其全部后代的状态而tasks wait只聚焦你指定的那一个任务。底层实现任务状态从哪里来nodetool tasks wait最终通过 ScyllaDB 的 HTTP API 与任务管理器交互。在源码中对应的 REST 端点是wait_task实现在 api/task_manager.cctm::wait_task.set(r, [tm, gossiper] (std::unique_ptrhttp::request req) - futurejson::json_return_type { auto id tasks::task_id{utils::UUID{req-get_path_param(task_id)}}; tasks::task_status status; std::optionalstd::chrono::seconds timeout std::nullopt; if (auto param req-get_query_param(timeout); !param.empty()) { timeout std::chrono::seconds(boost::lexical_castuint32_t(param)); } try { auto task tasks::task_handler{tm.local(), id}; status co_await task.wait_for_task(timeout); } catch (tasks::task_manager::task_not_found e) { throw bad_param_exception(e.what()); } catch (timed_out_error e) { throw httpd::base_exception{e.what(), http::reply::status_type::request_timeout}; } co_return make_status(status, gossiper); });从源码可以看出几个关键实现事实超时参数解析timeout查询参数通过boost::lexical_castuint32_t解析为秒未传时timeout为std::nullopt即无限等待。任务不存在若传入的task_id不存在会抛出task_manager::task_not_found对应 HTTP 400bad_param_exception。超时处理wait_for_task(timeout)超时后抛出timed_out_error映射为 HTTP 408request_timeout——这与 nodetool 侧--quiet模式下退出码124超时的语义一一对应。状态序列化最终通过make_status(status, gossiper)生成包含节点信息children_ids中的 node 字段即来自 gossiper的完整状态。类似地api/task_manager.cc 中的abort_task端点实现了nodetool tasks abort的底层逻辑调用task.abort()若任务不可中止则抛出task_not_abortable映射为 HTTP 403。状态保留时间与相关配置任务完成后其状态不会永久保存在节点上。根据 tasks/index.rst 的说明任务完成时其状态会临时存储在执行该任务的节点上状态信息最多保留task_ttl_in_seconds秒。在 db/config.cc 中可以找到该配置的默认值定义, task_ttl_seconds(this, task_ttl_in_seconds, liveness::LiveUpdate, value_status::Used, 0, Time for which information about finished task started internally stays in memory.) , user_task_ttl_seconds(this, user_task_ttl_in_seconds, liveness::LiveUpdate, value_status::Used, 3600, Time for which information about finished task started by user stays in memory.)即task_ttl_in_seconds内部任务完成后的保留时间默认0立即注销user_task_ttl_in_seconds用户发起的任务完成后的保留时间默认3600秒1 小时。两者均为LiveUpdate属性可在线更新。相关运行时查看/修改方式参见 tasks/ttl.rst 与 tasks/user-ttl.rst# 查看当前内部任务保留时长 nodetool tasks ttl # 将内部任务保留时长设为 10 秒仅内存生效不持久化 nodetool tasks ttl --set 10需要注意nodetool tasks ttl --set只在内存中生效要永久修改需调整scylla.yaml中的task_ttl_in_seconds或在启动 Scylla 时使用--task-ttl-in-seconds参数。对tasks wait的实际影响如果在任务完成之前、任务状态已因 TTL 到期被注销wait_for_task会抛出task_not_found。因此在使用tasks wait等待长任务时应确保任务尚在保留期内或合理配置 TTL 值。与其它 tasks 子命令的配合tasks wait是整个任务管理器命令家族的一员完整列表见 tasks/index.rst在实践中常与以下命令组合使用子命令作用配合场景tasks list module列出某模块如repair、compaction下的任务先列出任务拿到task_id再用tasks wait等待目标任务。modules子命令可查看支持的模块列表tasks status task_id获取单个任务当前状态不等待任务还在运行时轮询其状态或任务已完成但未记录结束时间时核实tasks tree [task_id]获取任务及其全部后代状态BFS 顺序分析父任务与 shard 子任务的整体完成情况tasks abort task_id中止可中止is_abortable: true的任务等太久不想等了先中止再配合tasks wait确认状态tasks drain [--module module]注销模块中所有已完成的本地任务清理陈旧任务状态释放内存典型的提交 → 等待 → 验证工作流如下# 1. 查看支持的模块 nodetool tasks modules # 输出示例repair / compaction # 2. 列出 repair 模块的任务找到目标 task_id nodetool tasks list repair --internal -ks myks --table mytable # 3. 等待该任务完成静默模式按退出码判断结果 nodetool tasks wait task_id --quiet # 4. 若超时或失败可中止任务并用 tree 检查整体状态 nodetool tasks abort task_id nodetool tasks tree task_idtasks list的常用过滤参数详见 tasks/list.rst包括--internal列出内部任务、--keyspace/-ks、--table/-t、--interval周期性重复列出与--iterations/-i重复次数。例如每 5 秒重复列出 compaction 任务 3 次nodetool tasks list compaction --interval 5 --i 3小结nodetool tasks wait是 ScyllaDB 任务管理器中面向确定性结果的关键工具它把任务是否真正完成从人工轮询tasks status中解放出来通过一次调用即可阻塞等待并返回最终状态--quiet模式下的退出码约定0/123/124/125使其天然适合嵌入 shell 脚本与自动化流水线。配合tasks list定位任务、tasks tree观察层级、tasks abort中止失控任务以及task_ttl_in_seconds/user_task_ttl_in_seconds的保留期配置运维人员可以完整地掌控 repair、compaction 等长时后台任务的整个生命周期。【免费下载链接】scylladbNoSQL data store using the Seastar framework, compatible with Apache Cassandra and Amazon DynamoDB项目地址: https://gitcode.com/GitHub_Trending/sc/scylladb创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考