Cassandra数据迁移后出现Self-suppression not permitted压缩错误求助

一、先处理压缩错误「Self-suppression not permitted」 #

这个错误是Java 8原生限制触发的，根源是复制到新容器的SSTable因旧容器意外关机存在损坏，压缩线程处理损坏文件时触发异常自我抑制的冲突。

1. 定位损坏的SSTable #

从错误日志可以明确看到，出错前正在处理的是以下两个SSTable：

• /var/lib/cassandra/data/pab/client-2a3c4e90bfe711eebc156d2c86545d91/md-13-big-Data.db
• /var/lib/cassandra/data/pab/client-2a3c4e90bfe711eebc156d2c86545d91/md-12-big-Data.db

2. 临时关闭压缩，确保节点正常启动 #

修改cassandra.yaml配置文件：

• 将auto_snapshot设为false
• 将compaction_throughput_mb_per_sec设为0（临时禁用自动压缩）

保存配置后重启Cassandra节点，确保节点能正常运行。

3. 验证并移除损坏的SSTable #

使用Cassandra自带的sstableutil工具校验SSTable完整性：

# 校验md-12系列文件
sstableutil --verify /var/lib/cassandra/data/pab/client-2a3c4e90bfe711eebc156d2c86545d91/md-12-big-*
# 校验md-13系列文件
sstableutil --verify /var/lib/cassandra/data/pab/client-2a3c4e90bfe711eebc156d2c86545d91/md-13-big-*

如果工具返回损坏提示，直接删除对应前缀的所有文件（包括.db、.index、.summary等关联文件）。

4. 恢复压缩配置 #

删除损坏文件后，将cassandra.yaml恢复默认配置：

• compaction_throughput_mb_per_sec改回默认值（如16）
• auto_snapshot设为true

重启节点后，压缩任务即可正常执行。

二、解决数据恢复与副本故障问题 #

1. 快照恢复数据不正确的原因 #

旧容器意外关机时，内存中的未刷盘数据丢失，快照基于磁盘文件生成，本身就不完整；直接复制容器数据目录可能遗漏commit log、system元数据表等关键文件，导致数据不一致。

2. 修复副本节点 #

• 若副本节点可启动：先按上述步骤修复副本节点的损坏SSTable，再执行nodetool repair同步数据。
• 若副本节点无法启动：重新初始化副本节点，执行nodetool bootstrap或nodetool rebuild从当前健康的新节点拉取完整数据。

3. 正确恢复旧容器数据（若旧磁盘可挂载） #

如果旧容器的磁盘还能挂载，先修复旧数据：

sstablescrub /path/to/old/cassandra/data/pab/client-2a3c4e90bfe711eebc156d2c86545d91/

修复完成后，将修复后的SSTable复制到新节点对应路径，执行nodetool refresh让Cassandra加载这些数据。

若旧数据无法修复，只能依赖最近的完整快照（如果有），或从健康副本节点同步数据。

内容的提问来源于stack exchange，提问作者marvin lee jing rui