Несоответствие данных для ключевой проблемы

#datastax #datastax-enterprise #datastax-java-driver

#cassandra #datastax-enterprise #datastax-java-драйвер

Вопрос:

Наша текущая настройка содержит версию DSE 5.0.2 с кластером из 3 узлов.В настоящее время мы сталкиваемся с проблемой большой нагрузки и сбоя узла.Отладка.подробности журнала приведены ниже:

DEBUG [ReadRepairStage: 8] 2016-09-27 14:11:58 781 ReadCallback.java: 234 — Несоответствие дайджеста: org.apache.cassandra.service.Исключение DigestMismatchException: несоответствие для ключа DecoratedKey(5503649670304043860, 343233) (45cf191fb10d902dc052aa76f7f0b54d против ffa7b4097e7fa05de794371092c51c68) в org.apache.cassandra.service.DigestResolver.resolve(DigestResolver.java: 85) ~ [cassandra-all-3.0.7.1159.jar: 3.0.7.1159] в org.apache.cassandra.service.ReadCallback$AsyncRepairRunner.run(ReadCallback.java:225) ~ [cassandra-all-3.0.7.1159.jar:3.0.7.1159] в java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java: 1142) [na: 1.8.0_77] в java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [na: 1.8.0_77] на java.lang.Thread.run(Thread.java:745) [na: 1.8.0_77]

Ответ №1:

Я отвечаю на это с точки зрения того, что означает ошибка, которую вы опубликовали. Однако я не думаю, что это само по себе будет причиной ваших проблем. Не видя всех журналов с узлов в вашем кластере, трудно сказать.

То Digest mismatch , что вы опубликовали, на самом деле получено из восстановления чтения. Эта ссылка на документы объясняет это на высоком уровне (обратите внимание, что вопреки тому, что говорится в документе, восстановление чтения может блокировать и в других CLS):

https://docs.datastax.com/en/cassandra/3.0/cassandra/operations/opsRepairNodesReadRepair.html

Если вы видите слишком много исправлений чтения и у вас есть несколько контроллеров домена, вы можете рассмотреть возможность установки 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