Узлы Кассандры опускаются

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

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

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

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


cassandra rhel datastax datastax-enterprise datastax-startup
person Hitesh    schedule 07.04.2016    source источник
comment
Вы изучили /var/log/cassandra/system.log, чтобы узнать, почему узлы не работают? Это может быть исключение OutOfMemory или длинная сборка мусора.   -  person doanduyhai    schedule 07.04.2016
comment
Я проверил эти журналы во время отключения узла, в них не было ничего, отмеченного как ошибки, хотя есть много информационных журналов, в которых говорится: Unexpected exception during request; channel = [....] java.io.IOException: Error while read (....): Connection reset by peer   -  person Hitesh    schedule 07.04.2016
comment
Можете ли вы скопировать и вставить куда-нибудь полную трассировку стека? И если это ошибка сетевого подключения, возможно, вам следует изучить файл system.log исходного сервера, с которого возникла ошибка.   -  person doanduyhai    schedule 08.04.2016

Ответы (1)


arrow_upward
0
arrow_downward

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

Ваша первая проблема, скорее всего, связана с исключением OutOfMemory.

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

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, чтобы закрыть соединение.

person Tim Ojo    schedule 19.07.2016