Почему мой индекс Solr Slave продолжает расти? - PullRequest
Новая
       13

Почему мой индекс Solr Slave продолжает расти?

4 голосов
/ 30 июня 2010

У меня есть 5-ядерный мастер solr 1.4, который реплицируется на другой 5-ядерный solr с использованием репликации solr, как описано здесь .Все записи выполняются против мастера и периодически копируются на подчиненный.Это делается с использованием следующей последовательности:

  1. Фиксация на каждом главном ядре
  2. Репликация на каждом подчиненном ядре
  3. Оптимизация на каждом подчиненном ядре
  4. Зафиксируйте на каждом подчиненном ядре

Проблема, с которой я столкнулся, заключается в том, что подчиненное устройство, похоже, хранит старые индексные файлы и занимает все больше места на диске.Например, после 3 повторов каталог данных основного ядра выглядит следующим образом: 

$ du -sh *
145M    index

Но каталог данных на подчиненном устройстве того же ядра выглядит следующим образом: 

$ du -sh *
300M    index
144M    index.20100621042048
145M    index.20100629035801
4.0K    index.properties
4.0K    replication.properties

Вотсодержимое index.properties:

#index properties
#Tue Jun 29 15:58:13 CDT 2010
index=index.20100629035801

И replication.properties:

#Replication details
#Tue Jun 29 15:58:13 CDT 2010
replicationFailedAtList=1277155032914
previousCycleTimeInSeconds=12
timesFailed=1
indexReplicatedAtList=1277845093709,1277155253911,1277155032914
indexReplicatedAt=1277845093709
replicationFailedAt=1277155032914
lastCycleBytesDownloaded=150616512
timesIndexReplicated=3

Файл solrconfig.xml для этого ведомого устройства содержит политику удаления по умолчанию: 

[...]
<mainIndex>
    <unlockOnStartup>false</unlockOnStartup>
    <reopenReaders>true</reopenReaders>
    <deletionPolicy class="solr.SolrDeletionPolicy">
        <str name="maxCommitsToKeep">1</str>
        <str name="maxOptimizedCommitsToKeep">0</str>
    </deletionPolicy>
</mainIndex>
[...]

Чего мне не хватает?

Ответы [ 3 ]

1 голос
/ 16 сентября 2012

оптимизация, выполняемая на ведомом устройстве, приводит к удвоению размера индекса.При оптимизации будут созданы отдельные сегменты индекса, чтобы переписать исходный индекс в число сегментов, упомянутых во время оптимизации (по умолчанию 1).Лучше всего оптимизировать время от времени, не вызывать его ни при каком событии (запустить задание cron или что-то еще) и оптимизировать только на master, а не на slave.Рабы получат эти новые сегменты через репликацию.Вы не должны фиксировать на ведомом устройстве, перезагрузка индекса позаботится о доступности новых документов на ведомом устройстве после репликации.

1 голос
/ 30 июня 2010

Бесполезно совершать и оптимизировать на рабах.Поскольку все операции записи выполняются на ведущем устройстве, это единственное место, где эти операции должны выполняться.

Это может быть причиной проблемы: поскольку вы выполняете дополнительную фиксацию и оптимизируете на ведомых устройствах, онадержит больше точек фиксации на рабах.Но это только предположение, должно быть легче понять, что происходит с вашим полным файлом solrconfig.xml как на главном, так и на ведомом устройствах.

0 голосов
/ 30 июня 2010

Я определил, что дополнительные каталоги index. *, Похоже, остались позади, когда я копируюсь после полной перезагрузки мастера.Под «полной перезагрузкой» я подразумеваю остановку мастера, удаление всего в [core] / data / *, перезапуск (после чего solr создает новый индекс), индексирование всех наших документов, а затем репликация.

* 1002Основываясь на дополнительном тестировании, я обнаружил, что кажется безопасным удалить другие каталоги * индекса (кроме того, который указан в [core] /data/index.properties).Если мне не нравится этот обходной путь, я могу решить очистить ведомый индекс (остановить; удалить данные / *; запустить) перед первой репликацией после полной перезагрузки мастера.
...