我们当前的设置包含带有3节点群集的DSE 5.0.2版本。目前，我们面临着重负载和节点故障问题。调试。日志详细信息如下：
调试[ReadRepairStage:8]2016-09-27 14:11:58781 ReadCallback。java:234-摘要不匹配：org.apache.cassandra.service。DigestMismatchException：org.apache.cassandra.service.DigestResolver.resolve（DigestResolver.java:85）~[cassandra-all-3.0.7.1159.jar:3.0.7.1159]处的DecoratedKey（55036496703043860，343233）（45cf191fb10d902dc052aa76f0b54d vs ffa7b4097e7fa05de794371092c51c68）不匹配~java.util.concurrent.ThreadPoolExecutor.runWorker（ThreadPool Executor.java:1142）[na:1.8.0_77]，java.util.concurrency.ThreadpoolExecuteor$Worker.run（Threadpool Executior.java:617）[na:1.8.0_77][na:1.8.0_77〕
1条答案
按热度按时间mv1qrgav1#
我是从你发布的错误的含义的Angular 来回答这个问题的。然而，我不认为只有这一点会导致你的问题。如果看不到集群中节点的所有日志，则很难判断。
您发布的
Digest mismatch实际上来自读取修复。此文档链接对其进行了高级解释（请注意，与文档所述相反，读取修复也可能在其他CL中阻塞）：https://docs.datastax.com/en/cassandra/3.0/cassandra/operations/opsRepairNodesReadRepair.html
如果您看到太多读取修复，并且有多个DC，您可能需要考虑将
read_repair_chance设置为更低，并增加dclocal_read_repair_chance，默认情况下，iirc分别为0.1和0，因此并不总是最理想的。我已经看到这些原因导致读取超时，因为摘要不匹配可能导致阻塞读取修复。如果您认为这会导致问题，那么最好的办法是要么在cqlsh中运行带有跟踪的查询，要么使用概率跟踪来记录查询，您可以回顾这些查询
文档链接：
https://docs.datastax.com/en/cql/3.3/cql/cql_reference/tracing_r.html
https://docs.datastax.com/en/cassandra/3.0/cassandra/tools/toolsSetTraceProbability.html