Безопасный импорт данных Solr и замена ядра на веб-сайте с высокой посещаемостью

Здравствуйте, коллеги-технари.

Предположим, у нас есть веб-сайт (PHP) с миллионами посетителей в месяц, и мы запускаем индекс SolR на веб-сайте с 4 миллионами размещенных документов. Solr работает на 4 отдельных серверах, где один сервер является главным, а остальные 3 сервера реплицированы.

Каждые 5 минут в Solr можно вставлять тысячи документов. Кроме того, пользователь может обновить свою учетную запись, что также должно вызвать обновление solr.

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

Импорт данных Solr

Для всех операций я хочу использовать один обработчик импорта данных. Я хочу объединить импорт данных и изменений в один файл конфигурации, например DataImportHandlerDeltaQueryViaFullImport. Мы используем базу данных MySQL в качестве источника данных.

Перестроение индекса

Для перестроения индекса я имею в виду следующее; мы создаем новое ядро ​​под названием «переиндексация» рядом с «живым» ядром. С помощью dataimporthandler мы полностью перестраиваем весь набор документов (4 миллиона документов), что в общей сложности занимает около 1-2 часов. В живом индексе по-прежнему каждую минуту происходят какие-то обновления, вставки и удаления.

После перестроения, которое заняло около 1-2 часов, новый индекс все еще не совсем актуален. Чтобы уменьшить задержку, мы делаем один дельта-импорт нового ядра, чтобы зафиксировать все изменения за последние 1-2 часа. Когда это будет сделано, выполните замену ядра. Обычный обработчик импорта «дельта», который запускается каждую минуту, подберет это новое ядро.

Передача обновлений в активное ядро

Чтобы держать наше живое ядро ​​в курсе, мы запускаем дельта-импорт каждую минуту. Из-за замены ядра ядро ​​переиндексации (которое теперь является действующим ядром) будет отслеживаться и обновляться. Я предполагаю, что это не должно быть проблемой, если этот индекс задерживается на несколько минут, потому что dataimport.properties также будут заменены местами? Дельта-импорт преодолел эти минуты задержки, но должен быть возможен.

Надеюсь, вы понимаете мою ситуацию и мою стратегию и можете посоветовать, правильно ли я поступаю в ваших глазах. Также я хотел бы знать, есть ли какие-то узкие места, о которых я не подумал? Мы используем Solr версии 1.4.

У меня есть вопрос, а как насчет репликации? Если главный сервер меняет ядро, как с этим справляются подчиненные?

И есть ли риски потери документов при обмене и т.д.?

Заранее спасибо!


architecture high-availability solr dataimporthandler high-traffic
person Kees Schepers    schedule 27.02.2012    source источник

Ответы (2)


arrow_upward
2
arrow_downward

Хороший (и сложный) вопрос!

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

Что касается репликации, перед заменой основного ядра я бы удостоверился, что репликация не выполняется. Дополнительные сведения о том, как работает репликация, можно найти в Вики Solr, если вы еще не сделал это еще.

Кроме того, перед заменой главного ядра я бы удостоверился, что на активном ядре не выполняется дельта-импорт.

person javanna    schedule 27.02.2012
comment
Конечно, я бы не стал делать полный импорт каждые два часа, я сказал, что полный импорт займет два часа ;-) Мы запускаем полный импорт только в том случае, если считаем, что индекс должен быть полностью обновлен. По ядрам важно, что модификации до сих пор индексируются по "старому" индексу, потому что мы не можем поставить все на паузу на 2 часа. Поскольку я запускаю полный импорт с очисткой, вы не можете одновременно запускать дельта-импорт на том же ядре, что приведет к задержке всех обновлений на 2 часа. Это одна из причин многоядерной настройки, вы меня понимаете? Спасибо! - person Kees Schepers; 27.02.2012
comment
@KeesSchepers Спасибо за ваш комментарий! Я обновил свой ответ в соответствии с вашим отзывом. - person javanna; 27.02.2012
comment
Спасибо! Итак, ваш вывод, что я поступаю правильно? Я мог бы запросить XML-данные о статусе дельта-импорта, чтобы проверить, обновляется ли сейчас живое ядро, и проверить xml-узел isReplicating в /replication?command=status, чтобы проверить, реплицируется ли или обновляется живое ядро, и обмениваться только тогда, когда оба действия праздные, не так ли? - person Kees Schepers; 27.02.2012
comment
@KeesSchepers Да, звучит хорошо! Я думаю, вы даже можете прервать текущую репликацию, но если вы можете подождать... лучше! - person javanna; 27.02.2012
comment
Хороший! Спасибо за отзыв. Еще одна вещь, поскольку вы работаете в SearchWorkings, работает ли описанная выше настройка с подключаемым модулем JTeam Spatial с solr? - person Kees Schepers; 28.02.2012
comment
@KeesSchepers Я не думаю, что у вас должны быть проблемы с плагином SSP и Solr 1.4, но если вам нужна помощь, вы всегда можете связаться с нами. - person javanna; 29.02.2012

arrow_upward
1
arrow_downward

У нас немного измененная ситуация на нашем конце. Есть два обработчика DataImportHandler — один для полного импорта, другой для дельта-импорта. Дельта-импорт запускается cron каждые 3 часа и занимает несколько минут. Полный импорт около 10 млн документов занимает ~48 часов (безумие!). Большая часть этого связана с задержкой в ​​сети, так как огромное количество данных извлекается из таблицы MySQL для каждого документа. Эти две таблицы находятся на двух разных серверах MySQL и не могут быть объединены.

У нас есть «живое» ядро, имеющее дельта-импорт. Мы вводим еще одно «перестроенное» ядро ​​и выполняем полный индекс, который занимает около 48 часов. К этому времени мы отслеживаем все документы, которые были обновлены/удалены из «живого» ядра, а затем делаем дельта-импорт в «перестроенное» ядро, чтобы привести их оба в одинаковое состояние. В обычный день, когда оба ядра находятся в одном и том же состоянии, мы поменяем их местами и будем обслуживать из перестроенного ядра. (Кто будет следить за тем, чтобы ядро ​​перестроения было полностью проиндексировано и к нему применялись дельта-заплаты?)

Иногда нам хотелось бы, чтобы и «живое», и «перестроенное» ядро ​​одновременно служили для «абс-тестирования». В то время как «живое», так и «перестроенное» ядро ​​будут иметь дельта-импорт для согласованности, и оба будут обслуживаться. Основываясь на результате, мы хотели бы сохранить один и удалить другой путем замены.

Чтобы сделать всю эту установку стабильной в рабочем состоянии, мы планируем ввести процесс мониторинга, который будет проверять, индексируется ли ядро ​​«перестроения» или с этим покончено. Если он проиндексирован, процесс монитора обновит его с помощью дельта-документов и активирует cron дельта-индексации для обоих ядер. По завершении фазы ab одно из ядер будет разгружено, а другое ядро ​​заменено. Дополнительные crons будут отключены.

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

person pr4n    schedule 28.02.2013