Узлы Cassandra Going Down

Question

У меня есть установка кластера Cassandra из 3 узлов (репликация установлена ​​на 2) с установленным Solr, каждый узел имеет RHEL, 32 ГБ RAM, жесткий диск 1 ТБ и DSE 4.8.3. На моих узлах происходит много писем, а также мое веб-приложение читает мои узлы.

1. Я заметил, что все узлы спускаются через каждые 3-4 дня. Я должен перезапустить каждый узел, а затем они работают достаточно хорошо до следующих 3-4 дней и снова повторяется одна и та же проблема. Я проверил журналы сервера, но они не показывают никакой ошибки, даже когда сервер идет вниз. Я не могу понять, почему это происходит.
2. В моем приложении, иногда при подключении к узлам через драйвер C# Кассандры, я получаю следующую ошибку

   Cassandra.NoHostAvailableException: Ни один из хостов пытавшихся для запроса не доступны (пробовали: «узел-IP ': 9042) в Cassandra.Tasks.TaskHelper.WaitToComplete (задача задачи, время ожидания Int32) в Cassandra.Tasks.TaskHelper.WaitToComplete [T] (задача Task``1, время ожидания Int32) в Cassandra.ControlConnection.Init() в Cassandra .Cluster.Init() `

Но когда я проверяю OpsCenter, ни один из узлов не вниз. Состояние всех узлов отображается отлично. Это может быть проблема с драйвером? Раньше я использовал Cassandra C# драйвер версии 2.5.0, установленный из nuget, но теперь я обновляю даже до версии 3.0.3, но эти ошибки сохраняются.

Любая помощь по этому вопросу будет оценена по достоинству. Заранее спасибо.

Answer 1

Если вы еще не сделали этого, вы можете захотеть взглянуть на настройки вашего уровня протоколирования по умолчанию, выполнив: nodetool -h 192.168.XXX.XXX setlogginglevel org.apache.cassandra DEBUG на всех узлах

Ваш первый вопрос скорее всего, OutOfMemory исключение.

Для вашей второй проблемы проблема скорее всего в том, что у вас действительно длительные паузы GC. Tailing /var/log/cassandra/debug.log или /var/log/cassandra/system.log может дать вам подсказку, но, как правило, не выявляет проблемы, если вы не тщательно просмотрите временные метки. Лучший способом устранения этого является обеспечением вы GC каротаж включены в вашем jvm.options конфигурации, а затем хвост ваших журналов ГЦ, принимая к сведению пауз:

grep 'Total time for which application threads were stopped:' /var/log/cassandra/gc.log.1 | less

ошибка Unexpected exception during request; channel = [....] java.io.IOException: Error while read (....): Connection reset by peer является обычно межузловым тайм-ауты. то есть координатор не ожидает ответа от другого узла и отправляет пакет TCP RST для закрытия соединения.