we respect your data
At Sagittarius, we want to share our passion and excitement for digital. By providing your details you agree to be contacted by us.
We will treat your personal data with respect and you can find details in our Privacy Statement - this includes:
- What information do we collect about you
- How will we use the information about you
- Access to your information and correction
win with us.
We exist to make your business thrive and our greatest reward is our returning clients. Our focus is and always will be on our clients and not on industry awards and accreditations, which could account for why we’ve won so many of them…
Use of Solr Search Provider in Sitecore .
Usage of Solf 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:
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.