ScyllaDB 集群缩容实操：使用 nodetool decommission 与 removenode 安全移除节点

ScyllaDB 集群缩容实操使用 nodetool decommission 与 removenode 安全移除节点【免费下载链接】scylladbNoSQL data store using the Seastar framework, compatible with Apache Cassandra and Amazon DynamoDB项目地址: https://gitcode.com/GitHub_Trending/sc/scylladbScyllaDB 集群在业务增长或收缩过程中经常需要调整规模。本文基于 remove-node.rst 官方操作指南系统讲解两类节点移除场景使用nodetool decommission优雅下线运行中的节点推荐方式以及使用nodetool removenode强制移除永久宕机的节点兜底方案。读完本文你将掌握从状态检查、数据迁移监控到数据清理的完整缩容流程并理解其背后的数据安全约束Replication Factor、RF-rack 约束、Repair-Based Node Operations 等。移除节点前必须确认的事项无论采用哪种方式移除节点缩容都会把待移除节点上的数据重新分布到其余节点上因此在动手之前需要确认以下前提剩余节点的磁盘空间是否充足。请检查现有节点的磁盘使用率确保待移除节点将要流式传输stream的数据量能够放入剩余节点的可用磁盘空间。如果空间不足移除操作会失败——务必在开始移除之前为剩余节点扩容见 decommission_warning.rst。移除后剩余节点数量不得低于键空间的复制因子Replication Factor, RF。例如audit键空间audit 功能默认启用等可能受影响。如果移除后剩余节点数低于该数据中心内键空间的 RFdecommission / removenode 请求可能失败。此时应先ALTER键空间降低 RF再执行移除见 decommission.rst 与 removenode.rst。注意机架级约束RF-rack 约束。移除某个机架中的节点可能违反某些键空间的 RF-rack 约束。如果一个键空间使用 tablets 且包含物化视图Materialized View或二级索引Secondary Index或者设置了rf_rack_valid_keyspaces选项则该键空间的这一不变量会被强制校验——若节点移除会破坏该约束操作将被拒绝。移除运行中的节点nodetool decommission推荐当目标节点状态为Up NormalUN时推荐使用nodetool decommission完成缩容。该命令会在节点退出前将其数据流式传输给集群中其余节点从而防止数据丢失是集群缩容的标准做法。第一步运行 nodetool status 查看集群状态Datacenter: DC1 StatusUp/Down StateNormal/Leaving/Joining/Moving -- Address Load Tokens Owns (effective) Host ID Rack UN 192.168.1.201 112.82 KB 256 32.7% 8d5ed9f4-7764-4dbd-bad8-43fddce94b7c B1 UN 192.168.1.202 91.11 KB 256 32.9% 125ed9f4-7777-1dbn-mac8-43fddce9123e B1 UN 192.168.1.203 124.42 KB 256 32.6% 675ed9f4-6564-6dbd-ca08-43fddce952de B1其中关键列含义详见 status.rst列/字段含义StatusU节点在线D节点离线X节点已被标记为 excluded被 removenode / excludenode / replace 标记为永久丢失StateNNormalLLeavingJJoiningMMovingLoad节点上 ScyllaDB 数据占用的磁盘大小每 60 秒更新一次Tokens每个节点拥有的 token 数量Owns (effective)节点在数据中心内拥有的数据百分比 × 复制因子。例如节点拥有 25% 数据、RF 为 4 时该值为 100%Host ID自动分配给节点的唯一标识UUIDremovenode 等命令依赖它定位节点Rack节点所在机架名称提示nodetool status也支持指定键空间参数如nodetool status my_keyspace用于计算有效拥有信息tablet 键空间还需指定表才能计算有效拥有率。第二步执行 nodetool decommission在待移除节点本机上执行decommission 移除的是你所连接的节点nodetool decommission依据节点当前状态分流处理节点状态为JoiningUJ时请参见 Safely Remove a Joining Node ——这类节点卡在 JOINING 状态无法进入 UN应停止节点、清理数据后重新加入而不是执行 decommission节点状态为DownDN时请跳转到下方「移除不可用节点」一节。decommission 的并行与取消能力来自 decommission.rst允许在多个节点上并行执行 decommissiontablet 键空间中数据量较大时并行比串行更快因为 tablets 会从各节点并行迁移随后进入 vnode 键空间的 decommission 阶段该阶段会与其他 vnode 类拓扑操作包括其他 decommission 操作串行化。仍处于tablet 排空draining阶段的 decommission 可以通过Task Manager API取消。第三步用 nodetool netstats 监控 token 再分配进度decommission 过程中运行nodetool netstats持续观察 token 再分配token reallocation的进度直到流式传输完成。第四步用 nodetool status 验证节点已移除decommission 完成后再次执行nodetool status被移除的节点应从输出中消失Datacenter: DC1 StatusUp/Down StateNormal/Leaving/Joining/Moving -- Address Load Tokens Owns (effective) Host ID Rack UN 192.168.1.201 112.82 KB 256 32.7% 8d5ed9f4-7764-4dbd-bad8-43fddce94b7c B1 UN 192.168.1.202 91.11 KB 256 32.9% 125ed9f4-7777-1dbn-mac8-43fddce9123e B1第五步手动清理节点上的数据与 commit log节点被移除后其上的数据不会自动删除。如果不清理这些数据仍会计入该节点的负载。请在已下线节点上执行以下命令删除数据来自 clean-data-code.rstsudo 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注意上述路径为默认安装位置请根据实际部署环境例如自定义数据目录调整。移除不可用节点nodetool removenode兜底方案当节点状态为Down NormalDN时应首先尝试恢复它若节点能恢复上线则回到上一节使用nodetool decommission正常移除若所有恢复手段均失败、节点永久宕机才使用nodetool removenode并提供该节点的Host ID强制移除。removenode 的使用场景与硬性警告nodetool removenode 675ed9f4-6564-6dbd-ca08-43fddce952denodetool removenode是兜底流程仅当节点永久宕机且无法恢复时使用绝对禁止用nodetool removenode移除一个可被集群中其他节点访问的运行中节点——运行节点请使用nodetool decommission被移除的节点以及通过--ignore-dead-nodes指定的被忽略死节点会在流程开始时被永久封禁banned出集群即使 removenode 失败也无法再将它们带回来。一旦节点被封禁唯一出路就是将其移除或替换在该节点被移除或替换之前无法执行 decommission、bootstrap 等其他拓扑操作。removenode 前置条件集群中至少要有quorum法定多数的节点可用。若失去 quorum必须先恢复再变更集群拓扑参见 Handling Node Failures移除后该数据中心剩余节点数不得低于键空间 RF否则 removenode 请求可能失败。此时应改为执行 替换死节点而不是 removenode。removenode 的工作原理与一致性风险nodetool removenode会通知其他节点被移除节点所拥有的 token range 需要转移各节点应通过流式传输streaming重新分布数据。需要明确的是如果流式传输源stream sources没有最新数据该命令不保证重平衡后数据的一致性如果集群中有节点不可用或发生其他错误removenode 操作会失败。因此为保证操作成功并保持副本间的一致性必须做到确保集群中其他所有节点状态均为 Up NormalUN。若有一个或多个节点不可用应显式指定--ignore-dead-nodes选项详见下文在运行nodetool removenode之前执行一次全集群 repair修复确保所有现有副本都持有最新数据若 removenode 过程中出现节点故障在重跑nodetool removenode之前再次执行 repair——当 Repair Based Node Operations (RBNO) 对removenode已启用时则无需手动 repair。处理不可用节点--ignore-dead-nodesremovenode操作需要集群中所有节点参与同步数据因此只要有节点不可用操作就会失败。此时必须用逗号分隔的列表显式列出所有不可用节点的 Host ID然后再给出待移除节点的 Host IDnodetool removenode --ignore-dead-nodes 8d5ed9f4-7764-4dbd-bad8-43fddce94b7c,125ed9f4-7777-1db0-aac8-43fddce9123e 675ed9f4-6564-6dbd-ca08-43fddce952deremovenode 的并行与取消能力与 decommission 类似见 removenode.rst允许对多个节点并行执行 removenode首先在并行阶段把被移除节点所属的 tablets 迁移到新副本并重建随后执行 vnode 键空间的移除部分该部分与其他 vnode 类操作串行化仍处于tablet 重建阶段的 removenode 可通过Task Manager API取消已重建完成的 tablets 会保留在新副本上。相关命令nodetool excludenode如果只想把节点标记为永久宕机excluded而暂不真正执行移除可使用nodetool excludenode见 excludenode.rstnodetool excludenode Host ID of the node节点被标记为 excluded 后集群不再尝试联系它从而解除 tablet 负载均衡、复制变更等操作阻塞但数据归属不变节点仍是集群成员最终仍需被移除或替换。被 excluded 的节点之后无需再作为忽略节点传给 removenode、replace 或 repair。深入理解RBNORepair-Based Node Operations为什么启用 RBNO 后 removenode 无需先跑 repairScyllaDB 在拓扑变更bootstrap、decommission、rebuild、removenode、replace期间默认使用行级 repair 机制来同步数据而非 streaming这一机制即 RBNO见 repair-based-node-operation.rst。RBNO 相比 streaming 更稳健、可靠且对数据一致性更安全失败的节点操作可以从停止点断点续传无需重传已同步的数据——这对大节点的增删是显著的省时优化并且启用 RBNO 后节点操作如 replace、removenode前后都无需再手动执行 repair。可通过以下配置项控制 RBNO参见 Configuration Parametersenable_repair_based_node_ops true|false—— 启用或禁用 RBNOallowed_repair_based_node_ops replace,removenode,rebuild,bootstrap,decommission—— 指定启用 RBNO 机制的节点操作类型。小结场景节点状态推荐命令关键动作正常缩容UN运行中nodetool decommission先查status流式迁移数据后自动下线最后手动清数据卡在加入流程UJJoining停止 清数据 重试参见 Safely Remove a Joining Node永久宕机DN无法恢复nodetool removenode Host ID先 repair确保其他节点全为 UN必要时用--ignore-dead-nodes移除节点前务必核对磁盘空间、RF 与机架约束decommission 过程中用netstats监控、用status验证removenode 仅在节点永久宕机时使用并牢记其在数据一致性上的局限与 repair 要求。如需查询全部相关命令可参考 Nodetool Referencedecommission 失败时的排查思路参见 Failed Decommission Troubleshooting。【免费下载链接】scylladbNoSQL data store using the Seastar framework, compatible with Apache Cassandra and Amazon DynamoDB项目地址: https://gitcode.com/GitHub_Trending/sc/scylladb创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考