SolrCloud - кластер из 2 узлов
Мы планируем внедрить SolrCloud в наше решение (в основном по причинам репликации данных и аварийного восстановления), к сожалению, у некоторых наших клиентов есть только 2DC, и один DC может быть полностью разрушен.
Мы знаем, что запуск ZK в 2 местах проблематичен, так как ZK требует кворума. А простои на любой стороне с двумя узлами ZK могут привести к отказу кластера. И сбой кластера также может быть вызван сетевым разделением между расположениями (ведущий перестанет быть ведущим из-за утраты кворума, ведомый не может выбрать себя по той же причине).
-
Таким образом, наш текущий план А состоит в том, чтобы использовать один ZK для обоих сайтов и создать резервную копию ZK на другом сайте. Так что, если сайт без ZK умирает, мы в порядке. Если сайт с ZK умрет, мы сможем запустить новый ZK из резервной копии и перенастроить Solr.
-
Мы также рассмотрели план B с классической репликацией master-slave между сайтами. НО мы используем псевдонимы с маршрутизацией по времени, следовательно, нам нужны функции SolrCloud, следовательно, нам также потребуется реплицировать данные / конфигурацию в ZooKeeper (не только индекс Solr). Таким образом, этот случай выглядит как дополнительная ручная работа в Solr, в то время как нам все равно нужно сделать резервную копию / восстановить ZK. Так что этот план был отклонен.
-
План C может состоять в том, чтобы иметь 2ZK, но один с большим весом. Это должно пережить разделение и умереть от ZK с меньшим весом. Первый ZK-узел должен автоматически резервироваться с использованием стандартной кластерной механики. Но я даже не знаю, кто использует ZK таким образом...
-
Есть ли более умный способ, как настроить SolrCloud в среде 2 узлов? Какое решение мы должны предпочесть?
Мы не ожидаем высокой доступности; мы хотим добиться аварийного восстановления. В случае сбоя узла ожидается вмешательство администратора, мы должны быть устойчивыми только к коротким сетевым сбоям.
Изменить: CDCR (перекрестная репликация центра данных) с псевдонимами с маршрутизацией по времени
Мы рассматриваем возможность использования TRA, потому что наши данные основаны на времени, и клиенты обычно интересуются только последним срезом / разделом. Без TRA индекс растет, а производительность падает, больше (неиспользуемого / старого) материала находится в индексе и оперативной памяти...
Здесь возникает проблема с CDCR, согласно документам, обязательны параметры исходного и целевого набора. Но с TRA коллекции создаются с тем же solrconfig.xml автоматически (каждые X дней / месяцев). Эта проблема в CDCR известна (см. Комментарии), но еще не решена.
Также кажется, что CDCR действительно не синхронизирует ZooKeeper (я не нашел упоминаний о функциональности в документах, jira и в коде), что может быть приемлемо для статического числа коллекций, но очень проблематично для динамически создаваемых коллекций (особенно некоторые механизмы в фоновом режиме вне кода пользователей / разработчиков).
Изменить: По словам Дэвида (основной автор TRA), комбинация CDCR и TRA не должна поддерживаться.