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

Question

Привет коллеги-техники,

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

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

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

Solr DataImport

Для всех операций я хочу использовать один обработчик импорта данных. Я хочу смешать данные и дельта-импорт в один файл конфигурации, такой как http://wiki.apache.org/solr/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, если вы еще этого не сделали.

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

Answer 2

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

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

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

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

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