Cassandra节点退役卡在UL状态的运维问题咨询

你观测到的“3天前无传输流、待退役节点持续记录写入日志”的特征，直接指向退役流程并未实际完成，可通过以下方式确认真实运行进度：

• 执行nodetool decomstatus查看退役专属状态输出：如果结果显示Node cannot be decommissioned，代表流程卡在前置校验环节；如果显示All data transferred. Waiting for pending range calculations，代表数据迁移已完成，卡在令牌一致性校验。
• 执行nodetool info查看待退役节点的运行模式：如果Mode字段仍为Normal，代表节点从未进入退役专属的只读保护模式，之前其他节点观测到的存储容量增长属于日常压缩、读修复带来的正常波动，并非退役流程触发的数据迁移。
• 抽验高频业务key的存储分布：对几个核心业务key执行nodetool getendpoints <keyspace> <key>，如果返回结果仍包含待退役节点的IP，代表对应key的副本还未完全迁移到其他在线节点。

• 正常情况下（未手动强制篡改节点环状态），重启待退役节点不会触发退役流程从头执行：Cassandra的退役进度会持久化存储在本地系统目录和集群gossip状态中，重启后会直接加载未完成的退役上下文，支持断点续传。
• 但如果当前卡住的核心原因是gossip链路异常、节点未进入退役模式，单纯重启无法解决问题：重启后节点仍会作为正常成员加入环，继续接收协调写入，重复当前卡住的状态。
• 注意：如果是在数据流传输中途重启，不会导致已传输的SSTable分片作废，只会从断点位置继续传输，不会消耗额外的集群带宽。

• 不需要新增专属的退役配置参数：Cassandra默认的退役逻辑本身具备全流程闭环能力，卡住场景大多和运行时状态异常有关，和静态配置无关。
• 如果确认是gossip正常、但节点处理负载过高导致退役后台线程无法调度，可临时调低待退役节点的concurrent_reads、concurrent_writes参数至常规值的50%，减少节点日常业务负载，为退役流程的后台计算线程让出资源。
• 如果待退役节点长期接收写入导致无法进入只读模式，可临时在集群其他节点执行nodetool relocate定向迁移该节点上的核心keyspace数据，跳过节点自身的退役触发逻辑。

排查待退役节点的system.log文件时，只有匹配到以下关键行，才代表退役流程在正常推进：

• 出现DECOMMISSIONING: unbootstrap starts：代表退役流程正式触发，节点开始进入只读保护模式
• 出现DECOMMISSIONING: finished streaming XX ranges, XX ranges failed：代表全量数据迁移完成，进入令牌范围一致性校验环节
• 出现DECOMMISSIONING: Successfully left the ring：代表退役流程全流程结束，节点即将从集群拓扑中移除
  如果日志中只有常规的写入、查询、压缩记录，没有以上专属的DECOMMISSIONING标识，就代表退役流程根本没有进入主执行链路，所有观测到的现象都不是退役操作带来的。

内容的提问来源于stack exchange，提问作者DollyShukla