Решите безопасный импорт данных и основной обмен на веб-сайте с высоким трафиком

Question

Здравствуйте коллеги-специалисты,

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

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

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

Solr DataImport

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

Индекс перестройки

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

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

Передача обновлений для живого ядра

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

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

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

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

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

Answer 1

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

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

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

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

Answer 2

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

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

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

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

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