Cassandra Opscenter.rollup\u状态表的压缩受阻

我们刚刚向cassandra集群添加了新的第二个DC，它有7个节点（每5个jbods SSD），在复制新DC之后，我们得到了Opscenter.rollup_状态表的周期性压缩。当这种情况发生时，节点为其他节点进入关闭状态，但自身保持活动状态，节点上的nodetool drain也会停止，在这种情况下，只有重新启动节点才有帮助。 重新启动节点后，下面的日志已存在。下面两个节点都处于此状态

DEBUG [CompactionExecutor:14] 2019-09-03 17:03:44,456  CompactionTask.java:154 - Compacting (a43c8d71-ce53-11e9-972d-59ed5390f0df) [/cass-db1/data/OpsCenter/rollup_state-43e776914d2911e79ab41dbbeab1d831/mc-581-big-Data.db:level=0, /cass-db1/data/OpsCenter/rollup_state-43e776914d2911e79ab41dbbeab1d831/mc-579-big-Data.db:level=0, ]

其他节点

    DEBUG [CompactionExecutor:14] 2019-09-03 20:38:22,272  CompactionTask.java:154 - Compacting (a00354f0-ce71-11e9-91a4-3731a2137ea5) [/cass-db2/data/OpsCenter/rollup_state-43e776914d2911e79ab41dbbeab1d831/mc-610-big-Data.db:level=0, /cass-db2/data/OpsCenter/rollup_state-43e776914d2911e79ab41dbbeab1d831/mc-606-big-Data.db:level=0, ]
    WARN  [CompactionExecutor:14] 2019-09-03 20:38:22,273  LeveledCompactionStrategy.java:273 - Live sstable /cass-db2/data/OpsCenter/rollup_state-43e776914d2911e79ab41dbbeab1d831/mc-606-big-Data.db from level 0 is not on corresponding level in the leveled manifest. This is not a problem per se, but may indicate an orphaned sstable due to a failed compaction not cleaned up properly.

---

解决此问题的方法是什么。

尝试了nodetool修复--full Opscenter将查看这是否有帮助…仍然相同。我可以截断它吗？有人有办法解决这个问题吗？