Even though, it may look like an obvious choice to use Solr Clusters to reduce search downtime in our Sitecore instance; the decision might not be as straight forward. While a Solr cluster architecture can provide better performance and lower downtime, switching to this kind of architecture can add additional operational costs to the server infrastructure and additional effort to support this architecture if there are issues down the road.

Solr “Legacy Scaling” vs. SolrCloud

When talking about Solr “cluster” architectures, we have two different choices:

Solr “Legacy Scaling

Also known as a Master/Slave configuration, this architecture involves one or more Solr servers running in standalone mode with what the community calls “legacy scaling” features enabled. This configuration is actually not really different from standalone mode because you can work for years with Solr running on a single server and then add index replication or distributed queries to different servers. It is considered a “legacy” mode since it’s still supported by Solr but future development is moving toward the SolrCloud architecture.

For more information, please review the official documentation about this architecture here:

SolrCloud (recommended)

SolrCloud is the new cluster architecture supported by Apache. SolrCloud mode offers index replication, failover, load balancing, and distributed queries with the help of ZooKeeper and other specialized features in Solr. In standalone mode, Solr still offers index replication and distributed queries in a master/slave model, but these activities are not coordinated with ZooKeeper but are managed manually. Failover and load balancing also need to be configured and managed entirely outside Solr with 3rd party tools. Unlike the old master-slave cluster, SolrCloud automates many of the processes with the help of Zookeeper. Precisely SolrCloud aims to provide a seamless flow of operations by automating the tasks that were performed manually in master-slave cluster.

However, when using Solr in SolrCloud mode, every index update is distributed across the cluster to every shard and replica of the cluster. For some use cases, such as particularly high indexing, this is too heavyweight, and standalone mode is preferred.

For more information about this architecture, please review the official Apache documentation here:


The decision comes down to the prominence and reliance in search in our site and if it’s worth it to introduce additional server uptime costs, support, and complexity to maintain a cluster architecture.

Leave a Reply

Your email address will not be published. Required fields are marked *