Облачная реплика solr записывает файл норм, пока не использует раздел

У нас есть облако solr 4.7.1 с 3 коллекциями на 8 серверах. Каждая коллекция разбита на 4 сегмента, на 4 серверах хранится основная реплика каждой коллекции, а на 4 разных серверах — остальные реплики. На прошлой неделе серверы, содержащие реплики для второго сегмента одной из коллекций, начали вести себя странно. Файлы записывались в одну из коллекций, заполняющих раздел. Когда раздел достиг 100%, файлы были удалены, а коллекция вернулась к своему обычному размеру; но процесс начнется снова. Это продолжалось несколько часов, а затем прекращалось на несколько часов. Проблема возникла со среды в четверг днем, но прекратилась с четверга до раннего утра понедельника.

В каталоге, содержащем файлы реплики, я вижу один файл, увеличивающийся до полного заполнения диска: ????.nvd. Насколько я читал, это файл норм. Я вижу, что в файле schema.xml для этой коллекции параметру omitNorms присвоено значение true.

В журналах больше ничего не выделяется, и мои поиски вычеркиваются. Любые мысли, пожалуйста?


person user3884624    schedule 28.07.2014    source источник


Ответы (1)


Пытался прокомментировать, но не получилось....

Укажите размер сегмента и общий размер диска. Все ли реплики осколка-виновника помечены зеленым цветом в облачном представлении? Что говорит файл журнала? Другие осколки также демонстрируют такое поведение?

Я видел, как Solr пытался продублировать индекс при подготовке к восстановлению или что-то еще... (я никогда не знаю, что он там делает)...

Кроме того, вы пытались перезапустить реплику?

РЕДАКТИРОВАТЬ: Кроме того, вы нажали кнопку «Оптимизировать»?

person nick_v1    schedule 28.07.2014
comment
Шард весит около 8,5 Гб. Размер раздела составляет 20 ГБ с 70% свободного места, когда проблема не возникает. В облачном представлении обе реплики для осколка-виновника выделены зеленым цветом (активны). Ни на одном из трех других осколков этой проблемы нет. Я попытался перезапустить реплику, и это не решило проблему. Я не нажимал кнопку оптимизации, и, насколько мне известно, я не думаю, что кто-то еще нажимал ее. Единственное, что я вижу в файле журнала, это когда раздел заполняется, и он сообщает о нехватке места на диске. - person user3884624; 29.07.2014
comment
Я исправляюсь, размер шарда 5,5 Гб. не 8,5 Гб. - person user3884624; 29.07.2014
comment
Что говорит файл журнала? Может нужно увеличить уровень лога? - person nick_v1; 29.07.2014
comment
Если я увеличу ведение журнала до DEBUG, я увижу шквал или запросы к серверу. Но единственное, что, кажется, регистрируется в связи с этой проблемой, это когда раздел заполняется на 100%, а затем возникает ошибка: - person user3884624; 01.08.2014
comment
org.apache.solr.common.SolrException: добавление журнала ошибок..... Вызвано: java.io.IOException: на устройстве не осталось места - person user3884624; 01.08.2014
comment
Интересно, что когда раздел заполняется, ошибка не всегда вылетает. Я подозреваю, что ошибка возникает только в том случае, если раздел заполняется и одновременно вносятся изменения в коллекцию. Я установил ведение журнала на DEBUG и просматривал журналы до тех пор, пока раздел не заполнился на 100%, а затем упал до 35%, и ошибка не возникла. - person user3884624; 01.08.2014
comment
Недавно у нас была похожая проблема, когда два осколка пытались восстановить, но не смогли. Симптом заключался в том, что они постоянно дублировали индексные файлы на диске. Оказалось, что это проблема подключения зоопарка. Нам пришлось остановить реплику, исправить zookeeper, очистить файловую систему и дать ей восстановиться вручную. - person nick_v1; 04.08.2014