Question

我们在数据中心有一个包含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。它说我们应该运行＆＃34; nodetool scrub＆＃34;如果它没有帮助＆＃34; sstablescrub＆＃34;。

我们尝试了nodetool scrub，但修复仍然无效。我们现在开始使用sstablescrub，但它似乎需要永远。它只使用一个100％的cpu，数据和索引文件正在增长，但它现在运行了一天以上，文件现在只有1.2GB的大小。

＆＃34; sstablescrub＆＃34;是否正常？太慢了？

群集已经运行了一段时间，我们错过了修复的GCGraceSeconds。可能导致无法修复？

我们目前不知道如何进行维修，希望有人可以提供帮助。

Answer 1

异常表示该节点无法接收应该在/xx.xxx.xx.xx上发生的merkle树计算的结果。请检查此节点的日志。您开始修复运行的节点很可能并且不需要sstable擦洗。

Cassandra 3修复永远不会完成

1 个答案: