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

Question

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

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

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

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

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

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

Индекс восстановления

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

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

Внесение обновлений в живое ядро

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

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

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

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

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

Answer 1

Хороший (и жесткий) вопрос!

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

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

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

Answer 2

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

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

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

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

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