我们有一个在数据中心中有 6 个节点的集群（每个 3 个节点）。我们正在一个节点上开始修复，不久之后我们可以在日志中找到类似的内容：
ERROR [Repair#1:1] 2016-05-31 01:33:28,075 CassandraDaemon.java:195 - Exception in thread Thread[Repair#1:1,5,RMI Runtime]
com.google.common.util.concurrent.UncheckedExecutionException: org.apache.cassandra.exceptions.RepairException: [repair #e8e21070-26be-11e6-aae8-77b20cefeee5 on ..... Validation failed in /xx.xxx.xx.xx
at com.google.common.util.concurrent.Futures.wrapAndThrowUnchecked(Futures.java:1525) ~[guava-18.0.jar:na]
at com.google.common.util.concurrent.Futures.getUnchecked(Futures.java:1511) ~[guava-18.0.jar:na]
at org.apache.cassandra.repair.RepairJob.run(RepairJob.java:162) ~[apache-cassandra-3.0.4.jar:3.0.4]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) ~[na:1.8.0_77]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) ~[na:1.8.0_77]
at java.lang.Thread.run(Thread.java:745) ~[na:1.8.0_77]
事后似乎什么都没有发生了。我们几天没有中断维修，但仍然没有任何反应。我们还在两个不同的集群上进行了尝试，结果相同。
在网上搜索后，我们偶然发现了https://support.datastax.com/hc/en-us/articles/205256895--Validation-failed-when-running-a-nodetool-repair。它说我们应该运行“nodetool scrub”，如果它没有帮助“sstablescrub”。
我们尝试了 nodetool 擦洗，但修复仍然无法正常工作。我们现在开始了 sstablescrub，但它似乎需要很长时间。它在 100% 的情况下仅使用一个 cpu，并且数据和索引文件正在增长，但它现在运行了一天多，文件现在只有 1.2GB 的大小。
“sstablescrub”这么慢是正常的吗？
集群已经运行了一段时间，我们错过了 GCGraceSeconds 进行修复。这会导致无法修复吗？
我们目前不知道如何进行维修，希望有人能提供帮助。