Sc101: Solr Cores

I’m sure you’re aware that Solr is a search engine that help us search for content quickly. Sitecore 8.2 and below come pre-configured with Lucene.Net, which is also a search engine. Lucene.Net is more basic and has its limitations so more customers request or need a more capable search engine. Sitecore supports Solr, which is based on Lucene but extends it to provide more power.

What is a Core, and how to configure it?

An index is a storage type that is similar to a DB table where we can store data that belong to the same project (for small to medium sized projects) or same module/component (for larger projects). Sitecore for example uses an index to store Master DB’s content data in an index, Web DB’s content data in another index, Analytics data in another and so on… In a basic Sitecore installation the following indexes are usually needed:

  • sitecore_core_index
  • sitecore_master_index
  • sitecore_web_index
  • sitecore_analytics_index
  • sitecore_marketingdefinitions_master
  • sitecore_marketing_asset_index_master
  • sitecore_fxm_master_index
  • sitecore_fxm_web_index
  • social_messages_master
  • sitecore_testing_index
  • sitecore_suggested_test_index
  • sitecore_list_index

Solr has the ability to group several indexes into cores. So you could simply view a core as an index (if that’s how it is configured) or a set of indexes. By default Sitecore is configured to read its indexes from different cores:

<indexes hint="list:AddIndex">
 <index id="sitecore_master_index"type="Sitecore.ContentSearch.SolrProvider.SolrSearchIndex, Sitecore.ContentSearch.SolrProvider">
  <param desc="name">$(id)</param>
  <param desc="core">$(id)</param>
  <param desc="propertyStore"ref="contentSearch/indexConfigurations/databasePropertyStore"param1="$(id)"/>
  <configuration ref="contentSearch/indexConfigurations/defaultSolrIndexConfiguration"/>

In the above index config sample for a ‘sitecore_master_index’ index, you’d find the id of the index ‘id=”sitecore_master_index“‘. Instead of rewriting the same name as the index name, we can simply tell the index name param to read the id as its name by using the $(id) variable:  <param desc=”name”>$(id)</param>

The same is done for the core name, so in the above example Sitecore expects to find the ‘sitecore_master_index’ index inside a core named ‘sitecore_master_index’.

You could also edit the config to store this index in a core with a different name. This is useful when your server has several solr instances and you do not want several Sitecore master indexes with the same name: ‘sitecore_master_index’. In this case, you would either:

  1. set an id with a unique part such as: customername_master_index. But you’ll have to make sure you access the index with the new name in your code
  2. set a different core name and keep the index name as it is.

Option #1 is applied by simply changing the id value of the above config sample. Option #2, however, is applied by editing the core name only:  ‘<param desc=”core”>customername_master_index</param>’

Using option #2 also allows you to set several indexes with the same core name:  <paramdesc=”core”>customername_core</param>. You’d see only one Solr core named ‘customername_core’ in Solr Core Admin instead of a core for each Sitecore index.

Keep in mind that it is recommended to have a core for each index for performance reasons. When you rebuild an index, all the data in its corresponding core is cleared and then rebuilt. So if you have several indexes in the same core, rebuilding one of the indexes would clear the other indexes’ data.

How to create my Cores?

A core contains a schema.xml (or managed-schema, depending on Solr’s version) config file that contains the field definitions that will be stored in the core. Sitecore has several fields that are required for all cores such as the id, name, path of items. This means, schema.xml will have to be edited before using your core.

I’m not going to go into the details of creating Sitecore’s Solr cores. There are several articles on this topic. What I wanted to add here, however, is that if you’re starting on a project that already has Solr configured on other servers or dev’s machines, you can get the cores from their instances. This would save you a considerable amount of time, effort and troubleshooting. To do this follow the following steps:

  1. On the server or other developers’ machines where Solr is already setup, navigate to the Solr cores folder. It is usually located @ ‘C:\Solr\solr-{versionNumber}\server\solr’
  2. Take a copy of all Sitecore’s cores for your current project from that folder into another folder
  3. In the new folder,  open each core and delete the ‘data’ folder. This contains all the indexed data and so can significantly increase the size of the cores to be migrated. You don’t have to migrate the data as once you rebuild your indexes on your machine, they will get re-created
  4. At this point you can move the cores folders into your machine and paste them into your Solr instance’s cores folder. Make sure you’re using the same Solr version!
  5. Finally restart your Solr server and Solr should load your new cores
  6. Of course make sure your Sitecore instance is configured to read from cores with the same names to the cores that you have migrated

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s