java.io.IOException: недоступные осколки для диапазонов

Я получаю следующую ошибку, когда запрашиваю свой кластер DSE:

java.io.IOException: недоступные фрагменты для диапазонов: [длинный список чисел]

Кластер состоит из 1 узла Cassandra и 4 узлов Solr, которые ранее работали нормально. Одна вещь, которую я заметил, когда начал получать сообщение об ошибке, заключается в том, что узлы Solr 2 и 3 не работают (процесс DSE не работает), а узел Solr 1 отображается как «UL» (вверху, уходит) в «состоянии узла».

Узлы 2 и 3 были возвращены в оперативный режим, просто снова запустив процесс DSE как автономный процесс, хотя во время запуска было несколько предупреждений «FileNotFound». Я еще не предпринял никаких действий для узла 1.

Мои вопросы:

  1. Что могло привести к остановке процесса DSE в узлах 2 и 3?
  2. Что могло заставить узел 1 «покинуть» кластер (без меня) и как я могу это остановить?

Изменить: узлы разделены на два контроллера домена: узел Cassandra принадлежит контроллеру домена "Cassandra"; 4 узла Solr принадлежат контроллеру домена Solr.

Изменить: теперь узлы отображают конфликтующие выходные данные «статус узла» при локальном запуске.

Узел Cassandra показывает следующий вывод:

Datacenter: Solr
================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address         Load       Tokens  Owns   Host ID                                  Rack
DL  <solr node 1>   306.5 GB   256     22.8%  69040f80-48fd-4425-817b-9550cb9490a6     rack1
DN  <solr node 2>   336.8 GB   256     25.1%  7dbbcc88-aabc-4cf4-a942-08e1aa325300     rack1
UN  <solr node 3>   316 GB     256     27.1%  c7db42c6-c5ae-439e-ab8d-c04b200fffc5     rack1
DN  <solr node 4>   444.88 GB  256     24.9%  30f411c3-7419-4786-97ad-395dfc379b40     rack1
Datacenter: Cassandra
=====================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address              Load       Tokens  Owns   Host ID                                  Rack
UN  <cassandra node 1>   850.02 GB  256     0.1%   6ab7062e-47fe-45f7-98e8-3ee8e1f742a4     rack1

Узел Solr 1 показывает:

Datacenter: Solr
================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address                                   Load       Tokens  Owns   Host ID                               Rack
UL  <solr node 1>                             306.5 GB   256     22.8%  69040f80-48fd-4425-817b-9550cb9490a6  rack1
DN  <solr node 2>                             336.8 GB   256     25.1%  7dbbcc88-aabc-4cf4-a942-08e1aa325300  rack1
UN  <solr node 3>                             316.02 GB  256     27.1%  c7db42c6-c5ae-439e-ab8d-c04b200fffc5  rack1
DN  <solr node 4>                             444.88 GB  256     24.9%  30f411c3-7419-4786-97ad-395dfc379b40  rack1
Datacenter: Cassandra
=====================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address             Load       Tokens  Owns   Host ID                               Rack
UN  <cassandra node 1>  850.42 GB  256     0.1%   6ab7062e-47fe-45f7-98e8-3ee8e1f742a4  rack1

И Solr node2 показывает:

Datacenter: Solr
================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address                                     Load       Tokens  Owns   Host ID                               Rack
UL  <solr node 1>                             303.26 GB  256     22.8%  69040f80-48fd-4425-817b-9550cb9490a6  rack1
UN  <solr node 2>                             336.8 GB   256     25.1%  7dbbcc88-aabc-4cf4-a942-08e1aa325300  rack1
UN  <solr node 3>                             310.52 GB  256     27.1%  c7db42c6-c5ae-439e-ab8d-c04b200fffc5  rack1
UN  <solr node 4>                             440.39 GB  256     24.9%  30f411c3-7419-4786-97ad-395dfc379b40  rack1
Datacenter: Cassandra
=====================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address                     Load       Tokens  Owns   Host ID                               Rack
UN  <cassandra node 1>          834.34 GB  256     0.1%   6ab7062e-47fe-45f7-98e8-3ee8e1f742a4  rack1

Узлы Solr 3 и 4 также показывают несколько разные результаты, но факт в том, что все узлы в настоящее время работают и доступны (пользовательский интерфейс администратора), за исключением того, что я получаю ошибку диапазона сегментов всякий раз, когда я выполняю запрос


solr datastax-enterprise
person PJ.    schedule 08.03.2014    source источник
comment
Очевидно, что какая-то сетевая проблема мешает вашим узлам правильно взаимодействовать, и даже если каждый узел доступен сам по себе, ни один из них не может достичь достаточного количества узлов, чтобы сгенерировать распределенный запрос, который может охватывать все диапазоны токенов.   -  person sbtourist    schedule 10.03.2014

Ответы (2)


arrow_upward
1
arrow_downward

Судя по всему, решение для нас — перезапустить все узлы. Были некоторые узлы, которые не удалось запустить при нашей первой попытке перезапуска (много FileNotFoundException), но смогли продолжить работу при повторной попытке. Этот шаг решил следующие проблемы:

  • узел 1 «покидает» кластер (возвращается к «нормальному» состоянию после перезапуска)
  • узлы, отображающие конфликтующие выходные данные nodetool status (все узлы показывают одинаковый статус после перезапуска)

РЕДАКТИРОВАТЬ: Проблема с узлом 1, «выходящим» из кластера, возникла сегодня снова. Я заметил, что диск заполнен. Является ли это причиной автоматического исключения из кластера?

person PJ.    schedule 11.03.2014

arrow_upward
0
arrow_downward

Убедитесь, что у вас есть рабочие нагрузки поиска Solr только в том контроллере домена, в котором вы используете Solr. IOW, на всех узлах Solr/search DC должны быть включены Solr/search. Узлы, отличные от Solr, в контроллере домена Solr могут сбивать с толку DSE/Solr при распределении запросов.

person Jack Krupansky    schedule 08.03.2014
comment
Добавил детали к моему вопросу - person PJ.; 09.03.2014