Use of Solr Search Provider in Sitecore

It is a copy of this blog post to have all my Sitecore articles in one place.

Usage of Solr search provider on Sitecore solutions becomes more and more popular. Solr is built over Lucene and provides additional abilities. Comparing with Lucene, it's server based:

• You don’t have a separate index for each CM/CD server, you don’t have problems with indexes sync on different machines
• CD servers doesn’t do indexes build, it frees server resources
• You are able to scale your search servers
• The more big your Sitecore solution is, the more probability is that you will use Solr provider.

Out of the box, Sitecore provides three types of Solr indexes: SolrSearchIndex, SwitchOnRebuildSolrSearchIndex and SwitchOnRebuildSolrCloudSearchIndex. SwitchOnRebuildSolrSearchIndex is built under top of SolrSearchIndex. SwitchOnRebuildSolrCloudSearchIndex is built under top of SwitchOnRebuildSolrSearchIndex. Why do you need different implementation? Answer is simple: SwitchOnRebuildSolrSearchIndex solves big problem of SolrSearchIndex: After start of index rebuild on SolrSearchIndex you temporarily get empty index. It causes seeing no search results by user during index rebuild.

SwitchOnRebuildSolrSearchIndex solves this problem by having 2 cores: one core is used during index rebuild, cores are swapped after rebuild, second core started to used after rebuild. It causes 2 requirements: having different core per index and double amount Solr cores. Swap atomically swaps the names used to access two existing cores. The prior core remains available and can be swapped back, if necessary. Each core will be known by the name of the other, after the swap.

Note: names of cores remains unchanged. Changing of places “sitecore_web_core” and “sitecore_web_core_rebuild” are only for highlighting that content of the core was changed by swap.

But what is happening when we are starting to use few SOLR servers: master and slave:

From diagram above we can make conclusion, that having “rebuild” cores could be redundant. And usage of SwitchOnRebuildSolrSearchIndex could be replaced with SolrSearchIndex, but we should disable replication during index rebuild. It could be easily done adding two Sitecore events:
Disabling replication on indexing:start. (if it is full index rebuild, not incremental)
Enabling replication on indexing:end. (if it is full index rebuild, not incremental)

Both these event handlers do web request to Solr server:

• http://master_host:port/solr/replication?command=disablereplication
• http://master_host:port/solr/replication?command=enablereplication

There is one un-obvious thing that you should have in mind: indexing:end event could be called when server is shutting down. It is necessary to check if server is not shutting down before enabling replication.

Now we get simpler process and possibility to use SolrSearchIndex.

Conclusion: when you have few Solr instances (Master/Slave) on Sitecore environments then you can use SolrSearchIndex and enabling/disabling replication instead of SwitchOnRebuildSolrSearchIndex.