В Solr Cloud нет традиционных master или slave - есть набор реплик, одна из которых определяется как лидер.Выбор лидера является автоматическим - то есть первая реплика, которая говорит, что хочет быть лидером, получает этот статус.Это в состоянии сбора.В вашем примере есть три реплики, одна из которых предназначена для лидера.Если эта реплика исчезает, одна из двух оставшихся реплик становится новым лидером, и все продолжается как обычно.Роль лидера заключается в том, чтобы быть актуальной версией индекса и обрабатывать любые обновления - сначала для своего собственного индекса, а затем направлять эти обновления на любые реплики .
Там.также несколько типов реплик , и не все из них подходят для повышения до лидера - но в конфигурации по умолчанию они могут быть.
Вот в чем дело - поскольку нетНа самом деле, все три индекса содержат одни и те же данные, и все они являются репликами одного и того же шарда, поэтому запрос не нужно направлять через мастер.Если вы используете тупой haproxy, вы можете безопасно распределить запросы по всем трем узлам, и они должны быть в состоянии ответить на запрос, не связываясь с другими узлами (при условии, что все они содержат все сегменты коллекции).
Однако, если вы используете SolrJ или другой клиент с поддержкой Zookeeper (и используете клиент, совместимый с Zookeeper), клиент вместо этого будет поддерживать связь с Zookeeper и считывать информацию о состоянии вашего кластера.Это позволяет клиенту узнать, какие серверы в настоящий момент являются репликами для вашей коллекции, и связаться с любым из тех узлов, которые он может решить, имеют необходимую информацию для вашего запроса.В вашем случае результат будет таким же, за исключением того, что ваш клиент будет знать, не подключаться к каким-либо узлам, которые исчезают, и будет автоматически знать об узлах, которые добавляются в кластер.
«Запросы на маршрутизацию одного узла Solr к другому узлу» актуальны только в том случае, если у узла, к которому вы обращаетесь, нет реплик для запрашиваемой коллекции - т. Е. Ему придется связаться сдругой узел, чтобы получить этот контент.В этом случае будет происходить межкластерный запрос, и нагрузка на кластер будет немного выше, чем необходимо.Когда коллекция реплицируется на все три узла - или когда вы используете SolrJ, этот межкластерный запрос не должен выполняться.