У нас есть кластер с 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, но ремонт все еще не помог. Мы начали использовать стабильный скраб, но, похоже, он длился вечно. Он использует только один ЦП на 100%, а файл данных и индекса растет, но теперь он работает более суток, и теперь файл имеет размер только 1,2 ГБ.
Это нормально, что "sstablescrub" работает так медленно?
Кластер уже какое-то время работает, и мы пропустили GCGraceSeconds на ремонт. Может ли это привести к неработающему ремонту?
В настоящее время мы не знаем, как запустить ремонт, надеюсь, кто-то может помочь.
