ScyllaDB 节点下线失败Failed Decommission排查与修复指南【免费下载链接】scylladbNoSQL data store using the Seastar framework, compatible with Apache Cassandra and Amazon DynamoDB项目地址: https://gitcode.com/GitHub_Trending/sc/scylladb本文基于 ScyllaDB 官方故障排查文档讲解节点执行nodetool decommission时卡在 Leaving下线状态这一常见问题的成因、验证方法以及标准恢复流程。读完本文你将掌握如何通过nodetool status与日志定位下线失败节点并能在不丢失数据的前提下重启节点、恢复正常状态UN后重新执行下线操作。问题背景decommission 与数据流Streaming节点下线decommission是 ScyllaDB 集群缩容Down Scale的核心操作。当你在某个节点上执行nodetool decommission时该节点会把自己负责的 token 范围数据流式传输streaming给集群中的其他节点随后从环ring中退出。从源码角度看nodetool decommission经由 REST API 的POST /storage_service/decommission进入服务端最终调用 storage_service.cc 中的storage_service::decommission()。下线期间节点会经历一系列受保护步骤通过 raft_decommission() 向 Raft 组提交 leave 拓扑请求、禁用快照与备份操作、停止传输层transport、排空 batchlog最终将引导状态置为DECOMMISSIONED。数据流的实际执行位于 stream_ranges()该函数按 keyspace 构建dht::range_streamer对应 stream reason 为decommission逐 keyspace 将本节点的 token range 注册为待发送tx范围然后调用streamer.stream_async()完成流式传输。数据流期间节点需要持续从磁盘HDD/SSD读取 SSTable 并跨网络发送给目标副本因此磁盘读取故障或网络问题是流失败最常见的两个诱因这正是官方文档指出的核心原因。症状节点卡在 ULUp Leaving状态当数据流失败时节点会停留在正在下线的中间状态即问题描述中的节点卡在 decommission 状态。如何验证执行以下命令检查本节点状态nodetool status正常情况下正在下线中该节点的状态应为ULUp / Leaving。从集群中的其他节点上再次运行nodetool status交叉确认被下线节点的状态确实显示为UL。这可以排除本节点视角的误判。通过日志确认失败原因。nodetool netstats不会显示正在进行的 streaming 详情因此无法用它来判断流是否失败请改用 ScyllaDB 日志详见 日志文档。典型错误日志当数据流失败时nodetool客户端会收到来自 REST API 的错误响应表现为类似如下的报错nodetool: ScyllaDB API server HTTP POST to URL /storage_service/decommission failed: stream_ranges failed这条错误信息与服务端日志一一对应在 stream_ranges() 中当stream_async()抛出异常时服务端会记录stream_ranges failed并重新抛出异常该异常最终由 rest_decommission 转换为 HTTP 错误返回给nodetool。同时节点的引导状态停留在 Leaving形成卡死表象。解决方案三步恢复官方推荐的修复流程非常简单无需强制清理或手工改表重启正在下线的节点。根据部署方式选择重启命令受支持的操作系统systemd 服务sudo systemctl restart scylla-serverDocker 容器无需重启容器本身仅重启其中的 ScyllaDB 服务docker exec -it some-scylla supervisorctl restart scylla重启后节点会脱离之前的 Leaving 中间状态重新以正常身份加入集群。验证节点恢复为UN状态nodetool status确认被下线节点显示为UNUp / Normal说明节点已回到正常状态。重新执行下线操作nodetool decommission再次触发 decommission让节点重新执行数据流并完成下线。深度解析为什么重启能解决问题重启之所以有效是因为 decommission 失败后节点只是停留在拓扑中间状态其数据本身完好。节点重启后storage_service会根据 system_keyspace 中记录的引导状态与 Raft 拓扑状态重新评估自身角色由于 raft_decommission() 要求节点必须处于normal状态才能提交 leave 请求重启后节点重新进入 normal 状态此时再次执行nodetool decommission即可重新走完整的下线流程。从源码结构看decommission全程受run_with_api_lock串行保护且 Raft 拓扑变更采用group0一致性协议提交因此重试是安全的上一次失败的流传输不会遗留孤儿状态重复提交 leave 请求由拓扑状态机去重处理。预防与前置检查根据nodetool decommission命令文档decommission.rst在真正执行下线前建议做好以下检查可显著降低失败概率磁盘空间确认剩余节点有足够空间容纳被下线节点流出的全部数据。空间不足是下线失败的另一常见原因应在操作前扩容。副本因子RF确保下线后本 DC 剩余节点数不低于该 keyspace 配置的 RF。若低于 RFALTERkeyspace 降低 RF 后再执行下线例如默认开启的 audit 功能使用的auditkeyspace 也需要相应调整。集群健康如果集群中存在任何节点宕机nodetool decommission将无法执行需先恢复宕机节点。并行下线官方支持对多个节点并行执行nodetool decommission。tablet 型 keyspace 的 tablet 迁移部分会并行进行而 vnode 型下线部分则与其他 vnode 操作串行执行因此并行在 tablet 数据量大时收益明显。取消能力仍处于 tablet 排空draining阶段的下线操作可以通过 Task Manager API 取消避免只能等它失败的被动局面。相关文档导航Remove a Node from a ScyllaDB Cluster (Down Scale)下线节点的完整操作流程。nodetool decommission 命令参考命令语义、前置条件与并行说明。Decommissioning a Data Center数据中心级下线。Task Manager监控与取消节点操作任务。Troubleshooting 首页更多故障排查文档入口。小结节点卡在UL且日志报stream_ranges failed时按重启节点 → 确认UN→ 重新 decommission三步即可恢复若反复失败则应优先排查磁盘读取与网络链路并结合上述前置检查排除空间与 RF 因素。【免费下载链接】scylladbNoSQL data store using the Seastar framework, compatible with Apache Cassandra and Amazon DynamoDB项目地址: https://gitcode.com/GitHub_Trending/sc/scylladb创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
