простое развертывание Solr с двумя серверами для резервирования

Question

Я развертываю веб-приложение Apache Solr на двух резервных серверах Tomcat 6, обеспечить избыточность и улучшенную доступность. На данный момент масштабируемость не является проблемой.

У меня есть балансировщик нагрузки, который может динамически маршрутизировать трафик на один сервер или другой или оба.

Я знаю, что Solr поддерживает конфигурацию master / slave, но для этого требуется ручное восстановление, если slave получает обновления во время простоя master (что и будет в моем случае использования).

Я рассматриваю более простой подход с использованием возможности перезагрузки ядра: - только один из двух серверов получает трафик в любое время («активный» экземпляр), но оба работают, - оба экземпляра используют одни и те же данные индекса и - перед перенаправлением трафика из-за сбоя, теперь активному экземпляру говорят перезагрузить ядро ​​(я) индекса

Успешно проведено ограниченное тестирование отработки отказа при чтении и записи индекса. Какие последствия / проблемы я пропускаю?

Ваши мысли и мнения приветствуются.

Answer 1

Простой подход к резервированию, который вы рассматриваете, кажется разумным, но вы не сможете использовать его для аварийного восстановления, если не сможете совместно использовать данные / индекс в / из другого физического местоположения, используя NAS / SAN.

Вот несколько советов: -

1. Создайте резервные копии для аварийного восстановления и проверьте работу этих резервных копий, так как, возможно, индекс поврежден, поскольку в SOLR / Lucene нет внутренних контрольных сумм.Индекс может быть удален или некоторые записи могут быть удалены и объединены без вашего ведома, а резервные копии могут быть полезны для восстановления этих записей / документов в более позднее время, если вам нужно провести расследование.

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

3. Изолироватьобновления для одного местоположения, процесса и потока для обеспечения целостности транзакций в случае переключения, так как может быть сложно управлять согласованностью, поскольку SOLR не использует векторные часы для синхронизации обновлений, как некоторые базы данных.Лично я бы держал копию всех обновлений по порядку отдельно от SOLR в каком-то другом магазине на случай, если нужно будет повторить небольшое временное окно.

В общем, мой опыт работы с SOLRбыло отлично, если вы не используете передовые функции и плагины.У меня есть один экземпляр, который в настоящее время имеет 40 миллионов документов и время безотказной работы более года без каких-либо проблем.Это не значит, что у вас не будет проблем, но дает представление о том, насколько стабильной она может быть.

Answer 2

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

Оба экземпляра используют одни и те же файлы. Если файлы по какой-либо причине повреждены или недоступны (аппаратная ошибка, программная ошибка), второй экземпляр завершится так же, как и первый.

В аналогичном примечании, файлы сохранены и доступны таким образом, что они всегда действительны, когда неактивный экземпляр читает их? Будет ли неактивный экземпляр пытаться прочитать файлы, когда активный экземпляр записывает их? Что будет, если это произойдет? Если активный экземпляр прерывается во время записи файлов индекса (сбой питания, перебои в сети, переполнение диска), что произойдет, если неактивный экземпляр попытается загрузить их? Те же вопросы применяются в обратном порядке, если «неактивный» экземпляр будет записывать в файлы (что не исключено, если он не был разработан с учетом этого использования; например, он может обновить какую-то статистику простоя) .

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

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