ScyllaDB 节点下线前的磁盘空间规划：decommission 容量检查与失败规避完整指南

ScyllaDB 节点下线前的磁盘空间规划decommission 容量检查与失败规避完整指南【免费下载链接】scylladbNoSQL data store using the Seastar framework, compatible with Apache Cassandra and Amazon DynamoDB项目地址: https://gitcode.com/GitHub_Trending/sc/scylladb在 ScyllaDB 集群缩容scale-down操作中nodetool decommission会把被移除节点的数据流式传输streaming到其余节点因此剩余节点是否有足够的磁盘空间直接决定下线操作成败。本文以仓库中复用于多份文档的官方警告decommission_warning.rst为核心系统讲解下线前磁盘空间评估方法、空间不足的失败表现、完整的下线流程与规避手段帮助你在执行节点移除前完成正确的容量规划避免操作中途失败。一、警告原文官方强制要求在下线前完成容量审查ScyllaDB 官方文档将以下警告以 Sphinx.. include::复用片段的形式同时嵌入到节点移除操作流程remove-node.rst与nodetool decommission命令参考decommission.rst中其原文要点如下审查现有节点当前的磁盘空间使用率确保从被移除节点流出的数据量能够放进剩余节点可用磁盘空间中如果剩余节点磁盘空间不足节点移除将失败必须在开始移除流程之前为剩余节点增加存储。这段警告虽然只有寥寥数行却概括了 ScyllaDB 缩容操作中最容易踩坑的一类事故decommission 不是一个逻辑上摘掉节点的元数据操作而是一个会产生真实数据搬运的存储操作。下面我们从源码层面解释它为什么如此关键。二、为什么需要磁盘空间decommission 的数据流机制从源码结构看ScyllaDB 的 decommission 本质上是反向引导unbootstrap流程入口为 service/storage_service.cc 中的storage_service::decommission()它通过run_with_api_lock串行化执行避免与其他拓扑操作并发冲突对于使用 Raft 协调的集群实际请求进入raft_decommission()service/storage_service.cc并向 group0 提交一条decommission: request decommission for ...命令service/storage_service.cc数据搬运由dht::range_streamer承担在源码中以Unbootstrap为流名称、以streaming::stream_reason::decommission为原因发起service/storage_service.cc被下线节点负责将自身持有的 token 范围数据流式传输给环上的其他节点之后才将自身从left_token_ring拓扑状态中移除service/storage_service.cc。这意味着下线一个节点相当于把它的负载含 SSTable 数据、二级索引数据、视图数据等平均或按拓扑规则分摊给剩余节点。剩余节点的可用空间必须大于等于被分摊数据的实际落盘量否则流式传输写入时会因磁盘写满而失败。此外ScyllaDB 通过 REST 接口暴露该操作/storage_service/decommission对应 api/storage_service.cc 中的rest_decommission最终调用ss.local().decommission(ssc)。nodetool decommission正是向该接口发起 HTTP POST 请求——因此 decommission 失败时客户端会收到形如ScyllaDB API server HTTP POST to URL /storage_service/decommission failed的错误见 failed-decommission.rst。三、操作前评估如何确认剩余节点有足够的可用空间按照警告的要求在下线前请逐项执行以下检查1. 查看各节点的磁盘使用率在被移除节点之外的每一个剩余节点上执行df -h重点关注挂载点ScyllaDB 默认数据目录为/var/lib/scylla可通过scylla.yaml的data_file_directories调整的Avail可用空间列。2. 估算将被搬运的数据量使用nodetool status查看各节点当前的Load各节点持有的数据量被移除节点的Load是数据搬运量的上限参考。需要说明的是实际搬运量并不等于该节点全部数据——streaming 只传输那些在新拓扑下仍需要保留在剩余节点上的 token 范围数据过期数据、已被压缩清除的数据不会重复传输同时剩余节点各自还要为新数据预留 compaction 等临时空间。因此在规划时建议以被移除节点Load的相当比例为粗估基准再结合各 keyspace 的复制因子RF与本数据中心剩余节点数量做估算。3. 空间充足性判定对于剩余节点集合中的每个节点近似满足节点可用空间 ≥ 该节点将承接的流式数据量 日常运行预留空间compaction 临时文件、commitlog、hints 等如果任一剩余节点不满足先在剩余节点上扩容增加磁盘或数据目录容量再开始移除流程——这是警告中before一词强调的顺序要求扩容必须发生在移除操作之前因为一旦 streaming 开始中途再扩容虽然可能挽救操作但流程复杂度与风险会显著上升。四、空间不足会怎样失败表现与影响如果忽略容量检查直接执行 decommission可能出现以下失败形态streaming 写入失败数据流式传输过程中目标节点磁盘写满流任务中断。此时从运行nodetool decommission的客户端看错误形如nodetool: ScyllaDB API server HTTP POST to URL /storage_service/decommission failed: stream_ranges failed该错误信息记录在官方排障文档 failed-decommission.rst 中同时节点可能停留在ULUp Leaving状态无法自行收敛。操作被拒绝某些校验性失败会在更早阶段抛出。例如 service/storage_service.cc 中当 Raft 协调器收到无法受理的下线请求时会抛出Decommission failed: node decommission rejected: ...当集群只剩最后一个节点或最后一个持有 token 的节点时也会直接拒绝service/storage_service.cc。数据一致性风险decommission 过程中若因磁盘问题导致流任务异常虽然 ScyllaDB 的拓扑状态机与任务管理器可以追踪任务进度但部分数据可能停留在中间状态。官方排障流程给出的标准恢复路径是重启被下线节点 → 确认恢复为UNUp Normal→ 重新执行nodetool decommission见 failed-decommission.rst。值得注意decommission 期间nodetool netstats并不展示正在进行的 streaming 细节官方在 failed-decommission.rst 中明确提示它更多用于观察 token 再分配的整体进度。五、完整的下线流程警告在流程中的位置官方推荐的移除运行中节点流程完整步骤见 remove-node.rst如下其中第一步之后紧接着就是本文讨论的磁盘空间检查执行nodetool status确认待移除节点状态为UNUp Normal本警告所处位置审查剩余节点磁盘空间必要时先扩容在被移除节点上执行nodetool decommission执行nodetool netstats监控 token 再分配进度执行nodetool status确认该节点已从环上消失手工清理被移除节点上的残留数据decommission 不会自动删除本地数据sudo rm -rf /var/lib/scylla/data sudo find /var/lib/scylla/commitlog -type f -delete sudo find /var/lib/scylla/hints -type f -delete sudo find /var/lib/scylla/view_hints -type f -delete清理命令源自仓库公共片段 clean-data-code.rst其中rm命令仅建议在确认数据已全部成功搬离后执行。与磁盘规划并列的其它前置校验nodetool decommission命令参考decommission.rst在磁盘空间检查之外还要求剩余节点数 ≥ keyspace 复制因子RF若本数据中心下线后剩余节点数低于 RFdecommission 请求可能失败此时应先ALTER KEYSPACE降低 RF 再下线需留意 audit 功能默认启用可能需要相应调整auditkeyspace不得在任何现有节点处于 Down 状态时执行 decommission。六、不可恢复节点的场景removenode 的容量注意点当节点永久宕机、无法恢复时官方推荐改用nodetool removenode Host ID见 removenode.rst。该命令同样依赖其余节点通过 streaming 重建被移除节点持有的 token 范围数据tablet 场景下是并行重建vnode 场景下与其它 vnode 操作串行因此前文的空间检查在这里同样适用——甚至更应谨慎因为被移除节点已宕机其本地数据不可用其余节点必须基于已有副本重建数据removenode开始时被移除节点与--ignore-dead-nodes列出的节点会被永久 ban 出集群removenode.rst操作失败后无法简单回退官方要求执行removenode前先做全集群 repair确保所有副本数据最新见 remove-node.rst。因此在removenode前同样要先确认剩余节点磁盘空间足够承接重建数据并满足剩余节点数 ≥ RF的前提否则应考虑走replace流程而不是removenode。七、最佳实践小结检查项方法失败后果剩余节点可用空间df -h对比被移除节点Load估算搬运量streaming 写满磁盘操作失败剩余节点数 ≥ RFnodetool status与 keyspace 配置核对decommission/removenode 请求被拒绝集群其它节点状态nodetool status确认全部为 UN无法执行 decommission副本数据新鲜度removenode先执行全集群 repair重建数据不一致核心原则浓缩为官方警告的那句话在下线流程开始之前为剩余节点补足存储。容量规划是 ScyllaDB 集群缩容的第一道防线做好这一步nodetool decommission与nodetool removenode才能顺畅、安全地完成。延伸阅读移除集群节点Down Scale完整流程nodetool decommission 命令参考nodetool removenode 命令参考Failed Decommission 排障指南decommission 源码实现入口storage_service.cc【免费下载链接】scylladbNoSQL data store using the Seastar framework, compatible with Apache Cassandra and Amazon DynamoDB项目地址: https://gitcode.com/GitHub_Trending/sc/scylladb创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考