执行nodetool decommission后数据流式传输完成，节点仍卡在LEAVING状态

我之前维护Cassandra 4.0.x集群时遇到过几乎一模一样的状况，折腾了好一阵才解决，分享几个亲测有效的排查和解决思路：

1. 优先处理阻塞的Compaction队列 #

节点卡在LEAVING状态很大概率是因为decommission的收尾阶段需要等待所有compaction完成，但升级后遗留的旧SSTable引发了大量积压的compaction任务：

• 先通过nodetool compactionstats查看队列详情，确认是哪种类型的compaction在积压（比如LeveledCompaction的清理任务、升级后格式转换的compaction）。
• 临时调高compaction吞吐量：执行nodetool setcompactionthroughput -- 150（单位MB/s，根据你的磁盘IO性能调整，不要超过磁盘承受上限），加快任务处理速度。
• 增加并发compactor数量：执行nodetool setconcurrentcompactors 4（根据节点CPU核心数调整，一般是核心数的1/2到1倍），让更多compaction任务并行处理。

2. 排查日志与系统表元数据 #

• 查看节点的system.log，搜索decommission相关日志，重点关注是否有类似Waiting for compactions to complete的提示，以及后续是否出现超时、异常报错（比如元数据不一致、磁盘IO错误）。
• 检查系统表状态：用cqlsh连接集群，查询system.peers和system.local表，确认是否存在旧节点的残留数据，或者当前LEAVING节点的元数据是否异常。如果有残留，可以手动清理（操作前请备份）。

3. 极端情况下的强制移除（谨慎操作） #

如果确认数据已经完全复制到其他副本节点（可通过nodetool status查看该节点负载为0，且其他副本节点的对应keyspace数据完整），但compaction队列始终无法清理完毕，可以尝试：

• 先停止该LEAVING节点的Cassandra服务。
• 在集群中任意正常节点执行nodetool removenode <节点ID>，将该节点从集群元数据中移除。

注意：此操作风险较高，必须确保数据已完全同步，否则会导致数据丢失。

4. 检查Compaction策略配置 #

如果升级后修改过Compaction策略（比如从SizeTiered切换到Leveled），可能会引发大量SSTable合并任务：

• 临时将有问题的keyspace的Compaction策略改回SizeTiered，待compaction队列清空后再切换回原策略。
• 针对旧SSTable执行手动compact：nodetool compact <keyspace> <table> -s，指定只处理旧格式的SSTable。

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