ScyllaDB 节点下线后重新加入集群Revoke Decommission 操作完整指南【免费下载链接】scylladbNoSQL data store using the Seastar framework, compatible with Apache Cassandra and Amazon DynamoDB项目地址: https://gitcode.com/GitHub_Trending/sc/scylladb本指南讲解如何将一台已被nodetool decommission下线移除的 ScyllaDB 节点重新加入原集群。无论是误操作导致节点被下线还是希望通过“下线再上线”的方式重置节点状态本文给出的标准做法是先彻底清空该节点上的旧数据再把它当作一台全新节点走一次标准的加节点bootstrap流程。读完本文你将掌握从状态核验、停止服务、清理数据目录到重新引导入集群的完整操作链并理解每一步背后的实现原理与注意事项。为什么需要“撤销下线”场景与思路ScyllaDB 的nodetool decommission会把当前节点从其 token 环中移除并将其持有的数据流式迁移给环内其余节点然后该节点正式脱离集群。这一操作通常是不可逆的——节点一旦被下线就没有一条“undo”命令能把它直接恢复原状。但实际运维中节点被误下线的情况并不少见。比如管理员在缩容演练时选错了节点、脚本误触发了 decommission或者节点下线后发现集群容量不足需要它回来。此时官方推荐的做法见 revoke-decommission.rst是把该节点当作一台全新节点重新加入集群——即清空它本地遗留的所有数据再执行标准的加节点bootstrap流程让集群其他节点把对应 token 范围的数据重新流式复制给它。这样做的核心原因在于下线的节点本地仍残留着旧的 schema 与数据包括记录 bootstrap 状态的系统表。如果不清理就重新启动节点会带着旧身份Host ID、token 归属、bootstrap 状态试图恢复导致初始化init流程无法正常进行甚至与集群当前的拓扑状态冲突。因此在重新加入前删除旧数据目录是必须的一步。前置条件确认节点已从集群中移除在动手之前必须先确认该节点确实已经不在集群拓扑中。ScyllaDB 官方文档要求使用nodetool status命令进行核验。nodetool status用于打印集群中节点的状态信息。在集群内任意一台存活节点上执行nodetool status假设被下线的节点 IP 为192.168.1.203核验后的输出应类似该节点不再出现在列表中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注意只有当目标节点完全消失于nodetool status输出中时才说明它已被彻底下线可以安全地执行下面的重加流程。如果输出中仍能看到它处于LeavingL状态说明 decommission 尚未完成应等待其彻底移出集群。关于nodetool status输出字段的解读可参考 status.rstStatusU表示节点存活D表示宕机X表示被排除permanently lost。StateNNormal正常、LLeaving正在离开、JJoining正在加入、MMoving移动中。Address / Load / Tokens节点 IP、磁盘上数据占用每 60 秒更新、每节点 token 数。Owns (effective)节点拥有的数据百分比按数据中心与复制因子计算。Host ID节点被自动分配的唯一 UUID是节点在集群中的身份标识。Rack节点所在机架名。从源码结构看nodetool status对应的实现位于 api/column_family.cc 与 api/storage_service.cc 等 REST 端点之后端最终汇聚各节点上报的 gossip 状态生成上述表格。操作步骤整个流程分为三步停止服务 → 清理数据 → 重新加节点。下面逐一展开。第 1 步停止被下线节点的 ScyllaDB 服务在待重新加入的节点本例192.168.1.203上停止 ScyllaDB 服务确保后续清理操作时没有进程正在写入数据文件。使用 systemd 的常规安装Supported OSsudo systemctl stop scylla-server使用 Docker 部署docker exec -it some-scylla supervisorctl stop scyllaDocker 场景下只需停止容器内的scylla服务无需停止some-scylla容器本身。第 2 步删除数据与 commitlog 目录由于该节点将以新节点身份重新加入集群必须删除旧的 data 文件夹否则残留的旧状态如 bootstrap 状态会阻碍新节点启动初始化流程。官方给出的清理命令如下对应仓库中的 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逐条说明各目录的作用与删除必要性目录作用为何必须清理/var/lib/scylla/data存放所有 keyspace 的 SSTable 数据及系统表system keyspace残留的 system 表记录着旧的 bootstrap 状态、Host ID 与 token 归属会阻止节点以新身份初始化/var/lib/scylla/commitlog预写日志commit log未刷盘的写入记录旧提交日志可能引用已被删除的 SSTable 数据且与新的节点身份不匹配/var/lib/scylla/hints针对离线副本的 Hinted Handoff 提示与旧拓扑相关的 hint 在新身份下无意义甚至可能投递给错误的副本/var/lib/scylla/view_hints物化视图的 hint同上属于旧节点残留关于数据清理的更多背景可参考 clear-data.rst该文档同时描述了“服务意外先启动”时应如何处理停止服务、清空数据、重新启动。第 3 步按“新增节点”流程把节点加回集群清理完成后即可遵循 add-node-to-cluster.rst 描述的“添加新节点到已有集群”流程把该节点重新引导入集群。核心要点如下3.1 收集集群信息在被下线节点上执行以下命令收集必要信息也可登录集群内任一节点获取grep cluster_name /etc/scylla/scylla.yaml grep seeds: /etc/scylla/scylla.yaml grep endpoint_snitch /etc/scylla/scylla.yaml grep authenticator /etc/scylla/scylla.yaml scylla --version即集群名、种子节点、snitch 类型、认证器配置以及 ScyllaDB 版本。对应的模板配置可参见仓库中的 conf/scylla.yaml。3.2 配置/etc/scylla/scylla.yaml编辑该节点的/etc/scylla/scylla.yaml确认或修改以下关键参数cluster_name集群名称必须与集群内其他节点一致模板默认Test Cluster。listen_address节点用于与集群其他节点通信的内部 IP。endpoint_snitch拓扑感知策略必须与集群一致模板默认SimpleSnitch。rpc_address面向 CQL 客户端连接的服务地址模板默认localhost。seeds集群中一个已存在节点的 IP新节点通过它连接集群并学习拓扑与状态。版本一致性提醒务必使新节点的 ScyllaDB补丁版本与集群其余节点完全一致不建议用不同 release 的节点加入集群。例如当前部署版本为 2025.1.0 时sudo yum install scylla-2025.1.0该要求同样记录于 match_version.rst。3.3 启动并验证启动 ScyllaDB 服务# systemd 安装 sudo systemctl start scylla-server # Docker 部署容器已运行 docker exec -it some-scylla supervisorctl start scylla然后再次执行nodetool status验证节点加入情况。此时集群其他节点会向新节点流式传输数据新节点会先处于Up Joining (UJ)状态类似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 UJ 192.168.1.203 124.42 KB 256 32.6% 675ed9f4-6564-6dbd-ca08-43fddce952de B1等待流式传输完成状态变为Up Normal (UN)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 B13.4 执行nodetool cleanup当新节点状态变为 UN 后需要在集群中除新节点外的所有其他节点上执行nodetool cleanupcleanup用于清除那些已经流式迁移给新节点、不再由原节点拥有的 key防止数据“复活”回旧位置。官方文档特别给出以下提示以降低 cleanup 的资源开销添加多个节点时可在所有节点都加入完成后仅在“除最后一个加入节点外”的其他节点上执行 cleanup可将 cleanup 推迟到低峰时段执行但必须确保在任何节点 decommission/remove 之前完成一次只在一个节点上运行 cleanup降低对集群整体的影响。源码视角decommission 与重新加入的机制从源码与测试层面可以进一步理解这一操作闭环的底层机制decommission 的入口nodetool decommission命令对应 decommission.rst 文档其核心行为是把节点数据流式迁移给环上的下一个节点。官方文档提醒执行 decommission 前要确认剩余节点磁盘空间充足、且 decommission 后 DC 内剩余节点数不低于 keyspace 的复制因子RF。remove-node 文档的呼应在 remove-node.rst 中节点被移除后同样要求手动清理数据与 commitlog复用同一份 clean-data-code.rst 清理命令原因与本文一致——被移除节点的数据不会自动删除其本地残留状态会干扰后续以新身份加入集群。服务端实现位置从源码结构看与节点生命周期相关的 REST API 处理集中在 api/storage_service.cc如 decommission/removenode 等端点数据流式迁移逻辑则在 streaming/ 目录下实现nodetool status依赖 gossip 状态汇总相关实现在 gms/gossiper.cc。测试覆盖仓库 test/ 目录中包含了大量围绕节点生命周期decommission、add node、replace、cleanup的集成测试用例如test/topology*系列可用于验证“下线节点清空数据后重新加入”这一场景的正确性。注意事项与常见误区decommission 一旦完成就没有“撤销”命令。不要试图用重启、nodetool removenode的逆操作等方式恢复下线节点唯一受支持的正确路径就是本文的“清空数据 重新 bootstrap”。必须确认节点已完全移出nodetool status输出后再开始操作。若节点仍处于Leaving状态应等待 decommission 彻底结束。清理必须彻底。仅删除data目录而不清理 commitlog、hints、view_hints 的做法会导致新身份与旧残留数据不一致。配置必须与集群一致。cluster_name、endpoint_snitch、seeds等任一参数不匹配都会导致节点无法成功加入。版本必须匹配补丁版本。以不同 release 加入集群不被推荐可能引发协议或功能不兼容。不要忽略 cleanup。若不执行nodetool cleanup被迁移走的 key 会残留在旧节点磁盘上带来数据一致性与存储浪费隐患。小结把已下线decommissioned的 ScyllaDB 节点重新加入集群本质上是执行一次“受控的新节点添加”确认节点已离群 → 停止服务 → 清理本地全部数据与日志 → 按新增节点流程重新 bootstrap。这套流程的关键在于彻底清除节点旧身份残留让集群能够安全地把它当作全新成员重新接纳并由其他节点重新流式同步其应属的数据。相关命令与说明均可在此前的 decommission、remove-node、add-node-to-cluster 文档及仓库源码中找到一致印证。【免费下载链接】scylladbNoSQL data store using the Seastar framework, compatible with Apache Cassandra and Amazon DynamoDB项目地址: https://gitcode.com/GitHub_Trending/sc/scylladb创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
ScyllaDB 节点下线后重新加入集群：Revoke Decommission 操作完整指南
ScyllaDB 节点下线后重新加入集群Revoke Decommission 操作完整指南【免费下载链接】scylladbNoSQL data store using the Seastar framework, compatible with Apache Cassandra and Amazon DynamoDB项目地址: https://gitcode.com/GitHub_Trending/sc/scylladb本指南讲解如何将一台已被nodetool decommission下线移除的 ScyllaDB 节点重新加入原集群。无论是误操作导致节点被下线还是希望通过“下线再上线”的方式重置节点状态本文给出的标准做法是先彻底清空该节点上的旧数据再把它当作一台全新节点走一次标准的加节点bootstrap流程。读完本文你将掌握从状态核验、停止服务、清理数据目录到重新引导入集群的完整操作链并理解每一步背后的实现原理与注意事项。为什么需要“撤销下线”场景与思路ScyllaDB 的nodetool decommission会把当前节点从其 token 环中移除并将其持有的数据流式迁移给环内其余节点然后该节点正式脱离集群。这一操作通常是不可逆的——节点一旦被下线就没有一条“undo”命令能把它直接恢复原状。但实际运维中节点被误下线的情况并不少见。比如管理员在缩容演练时选错了节点、脚本误触发了 decommission或者节点下线后发现集群容量不足需要它回来。此时官方推荐的做法见 revoke-decommission.rst是把该节点当作一台全新节点重新加入集群——即清空它本地遗留的所有数据再执行标准的加节点bootstrap流程让集群其他节点把对应 token 范围的数据重新流式复制给它。这样做的核心原因在于下线的节点本地仍残留着旧的 schema 与数据包括记录 bootstrap 状态的系统表。如果不清理就重新启动节点会带着旧身份Host ID、token 归属、bootstrap 状态试图恢复导致初始化init流程无法正常进行甚至与集群当前的拓扑状态冲突。因此在重新加入前删除旧数据目录是必须的一步。前置条件确认节点已从集群中移除在动手之前必须先确认该节点确实已经不在集群拓扑中。ScyllaDB 官方文档要求使用nodetool status命令进行核验。nodetool status用于打印集群中节点的状态信息。在集群内任意一台存活节点上执行nodetool status假设被下线的节点 IP 为192.168.1.203核验后的输出应类似该节点不再出现在列表中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注意只有当目标节点完全消失于nodetool status输出中时才说明它已被彻底下线可以安全地执行下面的重加流程。如果输出中仍能看到它处于LeavingL状态说明 decommission 尚未完成应等待其彻底移出集群。关于nodetool status输出字段的解读可参考 status.rstStatusU表示节点存活D表示宕机X表示被排除permanently lost。StateNNormal正常、LLeaving正在离开、JJoining正在加入、MMoving移动中。Address / Load / Tokens节点 IP、磁盘上数据占用每 60 秒更新、每节点 token 数。Owns (effective)节点拥有的数据百分比按数据中心与复制因子计算。Host ID节点被自动分配的唯一 UUID是节点在集群中的身份标识。Rack节点所在机架名。从源码结构看nodetool status对应的实现位于 api/column_family.cc 与 api/storage_service.cc 等 REST 端点之后端最终汇聚各节点上报的 gossip 状态生成上述表格。操作步骤整个流程分为三步停止服务 → 清理数据 → 重新加节点。下面逐一展开。第 1 步停止被下线节点的 ScyllaDB 服务在待重新加入的节点本例192.168.1.203上停止 ScyllaDB 服务确保后续清理操作时没有进程正在写入数据文件。使用 systemd 的常规安装Supported OSsudo systemctl stop scylla-server使用 Docker 部署docker exec -it some-scylla supervisorctl stop scyllaDocker 场景下只需停止容器内的scylla服务无需停止some-scylla容器本身。第 2 步删除数据与 commitlog 目录由于该节点将以新节点身份重新加入集群必须删除旧的 data 文件夹否则残留的旧状态如 bootstrap 状态会阻碍新节点启动初始化流程。官方给出的清理命令如下对应仓库中的 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逐条说明各目录的作用与删除必要性目录作用为何必须清理/var/lib/scylla/data存放所有 keyspace 的 SSTable 数据及系统表system keyspace残留的 system 表记录着旧的 bootstrap 状态、Host ID 与 token 归属会阻止节点以新身份初始化/var/lib/scylla/commitlog预写日志commit log未刷盘的写入记录旧提交日志可能引用已被删除的 SSTable 数据且与新的节点身份不匹配/var/lib/scylla/hints针对离线副本的 Hinted Handoff 提示与旧拓扑相关的 hint 在新身份下无意义甚至可能投递给错误的副本/var/lib/scylla/view_hints物化视图的 hint同上属于旧节点残留关于数据清理的更多背景可参考 clear-data.rst该文档同时描述了“服务意外先启动”时应如何处理停止服务、清空数据、重新启动。第 3 步按“新增节点”流程把节点加回集群清理完成后即可遵循 add-node-to-cluster.rst 描述的“添加新节点到已有集群”流程把该节点重新引导入集群。核心要点如下3.1 收集集群信息在被下线节点上执行以下命令收集必要信息也可登录集群内任一节点获取grep cluster_name /etc/scylla/scylla.yaml grep seeds: /etc/scylla/scylla.yaml grep endpoint_snitch /etc/scylla/scylla.yaml grep authenticator /etc/scylla/scylla.yaml scylla --version即集群名、种子节点、snitch 类型、认证器配置以及 ScyllaDB 版本。对应的模板配置可参见仓库中的 conf/scylla.yaml。3.2 配置/etc/scylla/scylla.yaml编辑该节点的/etc/scylla/scylla.yaml确认或修改以下关键参数cluster_name集群名称必须与集群内其他节点一致模板默认Test Cluster。listen_address节点用于与集群其他节点通信的内部 IP。endpoint_snitch拓扑感知策略必须与集群一致模板默认SimpleSnitch。rpc_address面向 CQL 客户端连接的服务地址模板默认localhost。seeds集群中一个已存在节点的 IP新节点通过它连接集群并学习拓扑与状态。版本一致性提醒务必使新节点的 ScyllaDB补丁版本与集群其余节点完全一致不建议用不同 release 的节点加入集群。例如当前部署版本为 2025.1.0 时sudo yum install scylla-2025.1.0该要求同样记录于 match_version.rst。3.3 启动并验证启动 ScyllaDB 服务# systemd 安装 sudo systemctl start scylla-server # Docker 部署容器已运行 docker exec -it some-scylla supervisorctl start scylla然后再次执行nodetool status验证节点加入情况。此时集群其他节点会向新节点流式传输数据新节点会先处于Up Joining (UJ)状态类似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 UJ 192.168.1.203 124.42 KB 256 32.6% 675ed9f4-6564-6dbd-ca08-43fddce952de B1等待流式传输完成状态变为Up Normal (UN)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 B13.4 执行nodetool cleanup当新节点状态变为 UN 后需要在集群中除新节点外的所有其他节点上执行nodetool cleanupcleanup用于清除那些已经流式迁移给新节点、不再由原节点拥有的 key防止数据“复活”回旧位置。官方文档特别给出以下提示以降低 cleanup 的资源开销添加多个节点时可在所有节点都加入完成后仅在“除最后一个加入节点外”的其他节点上执行 cleanup可将 cleanup 推迟到低峰时段执行但必须确保在任何节点 decommission/remove 之前完成一次只在一个节点上运行 cleanup降低对集群整体的影响。源码视角decommission 与重新加入的机制从源码与测试层面可以进一步理解这一操作闭环的底层机制decommission 的入口nodetool decommission命令对应 decommission.rst 文档其核心行为是把节点数据流式迁移给环上的下一个节点。官方文档提醒执行 decommission 前要确认剩余节点磁盘空间充足、且 decommission 后 DC 内剩余节点数不低于 keyspace 的复制因子RF。remove-node 文档的呼应在 remove-node.rst 中节点被移除后同样要求手动清理数据与 commitlog复用同一份 clean-data-code.rst 清理命令原因与本文一致——被移除节点的数据不会自动删除其本地残留状态会干扰后续以新身份加入集群。服务端实现位置从源码结构看与节点生命周期相关的 REST API 处理集中在 api/storage_service.cc如 decommission/removenode 等端点数据流式迁移逻辑则在 streaming/ 目录下实现nodetool status依赖 gossip 状态汇总相关实现在 gms/gossiper.cc。测试覆盖仓库 test/ 目录中包含了大量围绕节点生命周期decommission、add node、replace、cleanup的集成测试用例如test/topology*系列可用于验证“下线节点清空数据后重新加入”这一场景的正确性。注意事项与常见误区decommission 一旦完成就没有“撤销”命令。不要试图用重启、nodetool removenode的逆操作等方式恢复下线节点唯一受支持的正确路径就是本文的“清空数据 重新 bootstrap”。必须确认节点已完全移出nodetool status输出后再开始操作。若节点仍处于Leaving状态应等待 decommission 彻底结束。清理必须彻底。仅删除data目录而不清理 commitlog、hints、view_hints 的做法会导致新身份与旧残留数据不一致。配置必须与集群一致。cluster_name、endpoint_snitch、seeds等任一参数不匹配都会导致节点无法成功加入。版本必须匹配补丁版本。以不同 release 加入集群不被推荐可能引发协议或功能不兼容。不要忽略 cleanup。若不执行nodetool cleanup被迁移走的 key 会残留在旧节点磁盘上带来数据一致性与存储浪费隐患。小结把已下线decommissioned的 ScyllaDB 节点重新加入集群本质上是执行一次“受控的新节点添加”确认节点已离群 → 停止服务 → 清理本地全部数据与日志 → 按新增节点流程重新 bootstrap。这套流程的关键在于彻底清除节点旧身份残留让集群能够安全地把它当作全新成员重新接纳并由其他节点重新流式同步其应属的数据。相关命令与说明均可在此前的 decommission、remove-node、add-node-to-cluster 文档及仓库源码中找到一致印证。【免费下载链接】scylladbNoSQL data store using the Seastar framework, compatible with Apache Cassandra and Amazon DynamoDB项目地址: https://gitcode.com/GitHub_Trending/sc/scylladb创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
