Cassandra 3.11.4集群节点磁盘空间利用率不均问题排查咨询

针对你遇到的Cassandra 3.11.4集群节点磁盘空间不均衡问题，我来梳理下可能的原因和可行的解决方案，同时对你计划的操作给出一些建议：

• 压缩进程异常：尽管所有节点的cassandra.yaml配置一致，但受影响节点的压缩任务可能因JVM卡顿、CPU/IO资源不足或临时故障出现运行滞后，导致SSTables未能及时合并成更紧凑的文件。就算SSTable日期都较新，若该节点的压缩频率低于其他节点，也会造成单文件体积偏大或总占用空间更高。另外要排查是否有人为执行过nodetool disableautocompaction且未恢复——虽然配置是自动压缩，但临时禁用会直接阻止合并操作。
• Repair操作遗留问题：如果该节点曾经历过中断后重新加入集群，或者之前的repair操作中途失败，可能导致节点存储了重复的副本数据。哪怕nodetool status显示Owns占比正常，底层也可能存在未清理的冗余数据片段，尤其是使用SimpleStrategy的集群，repair过程中的异常很容易引发这类问题。
• Tombstone清理不彻底：你提到tombstones的生命周期符合预期，但该节点的压缩任务可能没有效清理已过期的tombstones。比如STCS的压缩触发条件未满足（小SSTable数量没达到阈值），或者GC压力导致压缩线程被抢占，使得包含tombstones的SSTables未被及时合并清理，额外占用了磁盘空间。
• 数据路由或写入异常：极少数情况下，客户端可能存在路由bug，导致同一数据被重复写入该节点的副本（哪怕token范围分配均匀）。另外可以排查hint存储——如果其他节点曾离线，该节点可能存储了大量hints，虽然hints通常会被及时发送，但异常情况下可能堆积占用空间（不过你提到无网络问题，这个可能性相对较低）。

先做基础状态排查 #

1. 检查压缩状态：执行nodetool compactionstats查看是否有积压的压缩任务，同时用nodetool getcompactionthreshold <keyspace>.<table>确认压缩阈值和其他节点是否一致。如果有积压任务，先等待压缩完成后观察空间变化。
2. 排查hint存储：执行nodetool statushints查看是否有未处理的hints，若存在且其他节点都在线，可执行nodetool clearhints清理（避免数据丢失）。
3. 检查资源状态：查看该节点的CPU、磁盘IO使用率，以及JVM堆内存情况（用nodetool info或jstat），确认是否因资源不足导致压缩或flush操作延迟。

针对性解决步骤 #

• 重启受影响节点：这是低风险的第一步。重启会强制flush所有memtable到SSTable，同时重置压缩进程。如果是临时的进程异常或memtable未及时flush导致的空间占用，重启后可能会有所改善。重启前建议先执行nodetool drain确保数据安全落地。
• 触发手动压缩：如果压缩状态显示无积压但SSTables仍偏大，可针对每个受影响的表执行手动压缩：nodetool compact <keyspace>.<table>。手动压缩会强制合并该节点上的所有SSTables，清理冗余数据和tombstones，能有效减少磁盘占用。注意手动压缩会消耗较多IO资源，建议在业务低峰期执行。
• 优先尝试增量Repair而非Full Repair：Full Repair确实耗时很长，尤其是大集群。你可以先尝试增量Repair：nodetool repair --incremental <keyspace>。增量Repair只修复自上次repair以来的差异数据，耗时会短很多。如果增量Repair无效，再考虑针对特定keyspace执行Full Repair，而非全集群操作。
• 检查并重置压缩配置：如果确认压缩阈值异常（哪怕yaml配置一致，也可能被动态修改过），可执行nodetool setcompactionthreshold <keyspace>.<table> <min> <max>恢复默认值，然后触发手动压缩。

长期预防措施 #

• 监控各节点的压缩状态、磁盘占用和SSTable大小，设置告警阈值，及时发现异常。
• 定期执行增量Repair（建议每周一次），避免数据不一致问题积累。
• 确保各节点的硬件资源（CPU、IO、内存）配置一致，避免因资源瓶颈导致压缩或同步操作滞后。

注意：执行任何涉及数据修改的操作（比如compact、repair）前，建议备份关键数据，并在业务低峰期进行，避免影响正常业务。

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