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

Question

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

1. Создание подготовительного ядра: http://localhost:8983/solr/admin/cores?action=CREATE&name=prep&instanceDir=main
2. Выполнение обновления индекса, затем принятие / оптимизация на подготовительном ядре.
3. Замена основного и подготовительногоcore: 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 предложил использовать репликацию.Чтобы использовать его в этом сценарии (на мой взгляд) потребуются следующие шаги:

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.Теперь он имеет те же данные, что и ядро ​​MAIN (теоретически), и будет готов к следующей операции индексации.

Answer 1

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

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

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

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