Cassandra集群修改压缩策略后特定节点特定表读写请求失败

嘿，我之前也碰到过Cassandra切换压缩策略后单节点单表读写故障的情况，结合你的场景，咱们一步步来排查和修复：

1. 先定位目标节点目标表的SSTable状态 #

首先登录出问题的节点，先搞清楚这张表的SSTable到底出了什么状况：

• 执行tablestats命令查看表的详细统计，重点关注损坏的SSTable和压缩状态：

  nodetool tablestats <你的keyspace名>.<你的表名>
  

• 直接去Cassandra的数据目录（默认路径是/var/lib/cassandra/data/<keyspace>/<table>-<随机uuid>/）查看SSTable文件：
  • 正常的Deflate压缩文件后缀是.db.deflate，如果看到混合了.db.lz4（旧压缩格式）或者0字节、命名异常的文件，大概率是升级过程中出了问题；如果有带corrupted标记的文件，那就是明确的损坏了。

2. 从日志里挖具体报错细节 #

Cassandra的系统日志（默认/var/log/cassandra/system.log）是排查问题的关键，搜索你的keyspace和表名，找读写失败的具体报错：

• 如果看到CorruptSSTableException，那就是SSTable文件损坏无疑；
• 如果是CompressorNotFoundException或者解压/压缩失败的报错，大概率是升级sstables时中途中断，导致部分文件没完成格式转换。

3. 针对不同问题场景修复 #

场景A：存在明确损坏的SSTable #

如果日志已经指出了具体的损坏文件名，先把这些文件移到临时目录备份（别直接删除，留一手）：

# 示例：假设损坏的文件是mc-123-big.db.deflate
mv /var/lib/cassandra/data/<keyspace>/<table>-<uuid>/mc-123-big.* /tmp/cassandra_bad_sstables_backup/

然后重启该节点的Cassandra服务，重启后Cassandra会自动从集群内其他正常节点同步修复这张表的数据。

场景B：部分SSTable未完成压缩转换 #

如果是升级过程中断（比如节点意外重启、IO/CPU资源耗尽）导致部分文件还是旧的LZ4格式，直接针对这张表重新执行升级命令：

nodetool upgradesstables -k <你的keyspace名> -t <你的表名>

执行期间可以用nodetool compactionstats查看进度，确保这次执行完全完成，中途别中断节点。

4. 验证修复效果 #

修复完成后，一定要做验证：

• 再次执行nodetool tablestats <keyspace>.<table>，确认没有corrupted的SSTable，且表的压缩策略显示为Deflate；
• 手动发起几次读写请求，验证业务是否正常；
• 再扫一遍系统日志，确认没有新的报错产生。

额外避坑提醒 #

• 压缩策略变更尽量选业务低峰期执行，upgradesstables会占用不少CPU和IO资源，避免影响正常业务；
• 如果表的数据量特别大，建议分批次操作：比如先升级部分节点，或者用nodetool upgradesstables -s只升级最近生成的SSTable，降低一次性压力；
• 执行任何变更前，最好给目标表打个快照备份：nodetool snapshot -t <备份名> <keyspace> <table>，防止出意外无法回滚。

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