Поддержка Apache Solr для отказоустойчивости в настройке Master-Slave

Наша команда разработчиков в настоящее время изучает миграцию нашей поисковой системы в Apache Solr, и мы будем очень благодарны за советы по настройке. Мы индексируем около двухсот миллионов строк базы данных. Мы добавляем около ста тысяч новых строк в течение дня. Эти новые строки базы данных должны быть доступны для поиска в течение двух минут после их получения.

Мы не хотим, чтобы индексирование искажало поисковика, поэтому наша мысль состоит в том, чтобы два сервера Solr работали на разных машинах в настройке репликации. Первым экземпляром Solr будет указатель. Он будет использовать DataImportHandler для индексирования дельта и включить автосообщение, чтобы предотвратить чрезмерные ставки фиксации. Оптимизация индекса будет проводиться в течение запланированных периодов. Второй экземпляр Solr (подчиненный) будет основным поисковым устройством и будет иметь индексы, хранящиеся на твердотельных накопителях RAIDed.

Что нас беспокоит, это переход на другой ресурс. Наши поиски являются критически важными. Если основной искатель по какой-либо причине опускается, наша служба поиска автоматически отключит запросы к индектеру node. Однако индексирование не менее критично. Если индексчик умирает, нам нужно иметь теплый режим восстановления после сбоя. Есть ли рекомендуемый способ автоматизации перехвата master node при репликации Solr? Я начал изучать ZooKeeper, но я не был уверен, что это лучший подход.

Ответы

Ответ 1

Как вы определили, поиск отказов может быть обработан с использованием репликации.

Мастер отказоустойчивости немного сложнее. Одна идея для чего-то вроде следующей логической установки

+--------+       +--------+
|  Slave |  ...  |  Slave |
+--------+       +--------+
     |               |
     v (replicate)   v
+---------------------------+
|     Load balancer         |
+---------------------------+
         /         \
        v           v
+--------+       +--------+
| Master | --->  | Master |
+--------+       +--------+
  • Чтобы обновить основные индексы repeater, можно использовать, когда мастер горячей резервной копии может реплицироваться из основного мастера
  • В любом
    • Используйте что-то вроде обработчика Ping для основного мастера как уведомление о сохранении. Если это невозможно, напишите небольшой программный компонент, который запускает обработчик импорта данных вторичного мастера.
    • Держите обработчики импорта данных активными на всех основных серверах, позволяя любому из них выполнять операцию без дополнительной настройки.

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

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