Безопасный импорт данных Solr и замена ядра на веб-сайте с высоким трафиком
-
13-11-2019 - |
Вопрос
Здравствуйте, коллеги-техники!
Предположим, у нас есть веб-сайт (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?
И есть ли риски потери документов при подмене и т.п.?
Заранее спасибо!
Решение
Хороший (и жесткий) вопрос!
Полнопортная - очень тяжелая работа, в целом лучше запустить Delta Queries, чтобы обновить свой индекс до последних изменений в ваших RDMS.Я получил, почему вы поменяете мастеру, когда вам нужно сделать полный импорт: вы продолжаете обновиться живое ядро, используя DELTA-Import, пока полный импорт работает на новом ядре, так как требуется два часа.Звучит хорошо, до тех пор, пока полный импорт не используется так часто.
Что касается репликации, я бы убедился, что нет никакой репликации, прежде чем поднимать основное ядро.Для получения более подробной информации о том, как работает репликация, вы можете посмотреть на Solr wiki , если у вас нетсделал это еще.
Кроме того, я бы убедился, что в живом ядре нет никакого дельта-импорта, не работающего перед обмен главным ядром.
Другие советы
У нас немного измененная ситуация.Существует два DataImportHandlers — один для полного импорта, другой для дельта-импорта.Дельта-импорт запускается cron каждые 3 часа и занимает несколько минут.Полный импорт около 10 миллионов документов занимает около 48 часов (безумие!).Большая часть этого связана с задержкой в сети, поскольку для каждого документа из таблицы MySQL извлекается огромный объем данных.Эти две таблицы находятся на двух разных серверах MySQL и не могут быть объединены.
У нас есть «живое» ядро, имеющее дельта-импорт.Мы вводим еще одно ядро для «перестройки» и выполняем полный индекс, который занимает около 48 часов.К этому времени мы отслеживаем все документы, которые были обновлены/удалены из «действующего» ядра, а затем выполняем дельта-импорт в «перестроенном» ядре, чтобы привести их оба в одинаковое состояние.В обычный день, когда оба ядра находятся в одном и том же состоянии, мы меняем их местами и обслуживаем из перестроенного ядра.(Кто будет следить за тем, чтобы ядро перестроения было полностью индексировано, а также применяло дельта-патчи?)
Иногда нам хотелось бы, чтобы «живое» и «перестроенное» ядро одновременно служило для «аб-тестирования».В те времена как «живое», так и «перестроенное» ядро для обеспечения согласованности имели дельта-импорт, и оба работали.В зависимости от результата мы хотели бы сохранить один и удалить другой путем замены.
Чтобы сделать всю эту установку стабильной в работе, мы планируем ввести процесс мониторинга, который будет проверять, индексирует ли ядро «перестроения» или закончило ли это.Если он проиндексирован, процесс монитора обновит его дельта-документами и активирует cron дельта-индексации для обоих ядер.По завершении фазы ab одно ядро будет разгружено, а другое ядро заменено.Тогда дополнительные crons будут отключены.
В этой конструкции есть еще несколько движущихся частей, и надежность процесса мониторинга имеет решающее значение для бесперебойной работы.Есть предложения/альтернативы?