Как мне создать ядро ​​solr с данными из существующего?

Solr 1.4 Enterprise Search Server рекомендует выполнять большие обновления копии ядра, а затем заменять его на главное ядро. Я выполняю следующие шаги:

  1. Создайте подготовительное ядро: http://localhost:8983/solr/admin/cores?action=CREATE&name=prep&instanceDir=main
  2. Выполните обновление индекса, затем выполните фиксацию / оптимизацию в подготовительном ядре.
  3. Поменяйте местами основное и подготовительное ядро: http://localhost:8983/solr/admin/cores?action=SWAP&core=main&other=prep
  4. Выгрузить подготовительное ядро: http://localhost:8983/solr/admin/cores?action=UNLOAD&core=prep

Проблема, с которой я столкнулся, заключается в том, что в ядре, созданном на шаге 1, нет данных. Если я собираюсь сделать полный индекс всего и кухонной мойки, это было бы хорошо, но если я просто хочу обновить (большое) подмножество документов - это, очевидно, не сработает.

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

Есть ли какой-то флаг для действия CREATE, который мне не хватает? Подробности на Solr Wiki для CoreAdmin немного скудны.

Возможное решение: репликация

Кто-то на solr-user предложил использовать репликацию. Чтобы использовать его в этом сценарии (насколько я понимаю), потребуются следующие шаги:

  1. Создайте новое ядро ​​PREP на основе конфигурации главного ядра.
  2. Измените конфигурацию ОСНОВНОГО ядра на ведущее
  3. Измените конфигурацию ядра PREP на подчиненное устройство
  4. Вызвать / подождать синхронизации?
  5. изменить конфигурацию ядра PREP, чтобы он больше не был подчиненным
  6. Выполните обновление индекса, затем зафиксируйте / оптимизируйте ядро ​​PREP.
  7. Поменять местами ядра PREP и MAIN

Более простой настройкой на основе репликации будет настройка постоянного ядра PREP, которое всегда является главным. ГЛАВНОЕ ядро ​​(на любом количестве серверов) может быть подчиненным для ядра PREP. Индексирование может происходить в ядре PREP так быстро или медленно, как необходимо.

Возможное решение: постоянное ядро ​​PREP и двойное обновление

Еще одна идея, которую я придумал, заключалась в следующем (также включающем постоянное ядро ​​PREP):

  1. Выполните обновление индекса, затем зафиксируйте / оптимизируйте ядро ​​PREP.
  2. Поменяйте местами ядра PREP и MAIN.
  3. Повторите обновление индекса, затем зафиксируйте / оптимизируйте то, что сейчас является ядром PREP. Теперь он имеет те же данные, что и основное ядро ​​(теоретически), и будет готов к следующей операции индексации.

solr
person stannius    schedule 23.03.2010    source источник
comment
Думаю, эта процедура предназначена для переиндексации всего. Что вы используете для индексации? DIH или индивидуальный процесс?   -  person Mauricio Scheffer    schedule 24.03.2010
comment
вы пробовали просто обновлять документы на том же ядре? неужели это так плохо?   -  person Mauricio Scheffer    schedule 25.03.2010
comment
Ну что, пробовали? Вы можете излишне усложнять вещи ...   -  person Mauricio Scheffer    schedule 25.03.2010
comment
Мы постарались, и производительность была в пределах допустимого. Документов у нас немного - порядка 100к. Спасибо за совет. Я был просто удивлен, что в книге было рекомендовано то, что было так сложно реализовать.   -  person stannius    schedule 02.04.2010

Ответы (1)


arrow_upward
3
arrow_downward

Я создал идею операции клонирования, которая делает копию файловой системы индексов и данных конфигурации, а затем СОЗДАЕТ новую. Есть некоторые проблемы с блокировкой, и у вас должен быть доступ файловой системы к индексам, но это сработало. Это действительно дает вам хорошую копию, которую вы можете возиться с файлами конфигурации.

Чем больше я думаю об этом, вы можете СОЗДАТЬ новое ядро, а затем сделать следующее:

Заставить команду fetchindex на ведомом устройстве от ведущего: http://slave_host:port/solr/replication?command=fetchindex Можно передать дополнительный атрибут «masterUrl» или другие атрибуты, такие как «сжатие» (или любой другой параметр, указанный в теге), чтобы выполнить одноразовую репликацию с мастера. Это избавляет от необходимости жесткого кодирования ведущего устройства на ведомом.

И заполните новый из производственного, затем примените свои обновления, а затем поменяйте местами обратно!

person Eric Pugh    schedule 25.03.2010