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

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

13 голосов
/ 15 июня 2011

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

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

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

1 Ответ

14 голосов
/ 16 июня 2011

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

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

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

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

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

...