4

We have a single Solr instance that we would like to point to two distinct Sitecore 9.0 Update-2 instances to - instance1.example.com and instance2.example.com.

Since they are separate instances, when creating the collections, I've prefixed them with an instance name, for example:

  • instance1_sitecore_core_index
  • instance1_sitecore_master_index
  • instance1_sitecore_web_index
  • instance1_sitecore_marketingdefinitions_master

  • ...

  • instance2_sitecore_core_index

  • instance2_sitecore_master_index
  • instance2_sitecore_web_index
  • instance2_sitecore_marketingdefinitions_master
  • ...

Setting up indexes for multi-site Sitecore suggests duplicating config files, Sitecore.ContentSearch.Solr.Index.Master.config and Sitecore.ContentSearch.Solr.Index.Web.config for example, and then updating the index id with a new name, and I'm concerned that it would still assume that a sitecore_web_index exists.

In addition, doing a search against a base Sitecore 9.0 Update-2 website directory doesn't return all eleven indexes, which suggests it wouldn't capture all the instances.

Is there any way to patch the configurations to have Sitecore treat sitecore_web_index as, for example, instance1_sitecore_web_index, and prefix the other Solr indexes as well?

Improve this question
8
  • You can keep index id as default and set core param instead with your prefixed value like this -> <param desc="core">instance1_$(id)</param> and for the second instance like this <param desc="core">instance2_$(id)</param>. Is this what you were looking for?
    – Peter Procházka
    Commented Aug 14, 2018 at 4:35
  • You can also create the separte solr Instance for each Sitecore website on the same machine, please check this blog: horizontalintegration.blog/2015/10/23/…
    – Ashish Bansal
    Commented Aug 14, 2018 at 9:49
  • 1
    @PeterProchazka can you put that as an answer so I can at least upvote it? That's actually what I was hoping we could do, especially after seeing \Website\App_Config\Include\Examples\Sitecore.ContentSearch.Solr.SwitchOnRebuild.config.example. However, what about the other indexes?
    – James Skemp
    Commented Aug 14, 2018 at 12:29
  • @AshishBansal if I understand the post correctly, it seems they setup two Solr instances with different install paths and ports. Unfortunately we're using a cloud service for our instance, so while a solution for some, not for those who want to use a single instance. But thanks!
    – James Skemp
    Commented Aug 14, 2018 at 12:31
  • 2
    @JamesSkemp Added answer + clarification + some sample ptach config to apply your new settings per instance.
    – Peter Procházka
    Commented Aug 14, 2018 at 13:28

1 Answer 1

Reset to default
3

You can achieve this setup pretty easily.

You have two instances of Sitecore. For each SOLR core definition you will keep core name (name parameter) and id the same (id attribute).

Normally config would look like this:

<index id="sitecore_master_index" .....>
   <param desc="name">$(id)</param>
   <param desc="core">$(id)</param>

You will just specify "core" parameter as follows:

<param desc="core">instance1_$(id)</param> or <param desc="core">instance2_$(id)</param> as you need based on instance name.

So config in your case would look like this at the end:

<index id="sitecore_master_index" .....>
   <param desc="name">$(id)</param>
   <param desc="core">instancename_$(id)</param>

For each solution you will have then config files for solr with same file name, solr ids and all the remaining settings. Only difference will be this "core" parameter.

Here is the patch config to apply your instance settings per solr core:

<?xml version="1.0"?>
<configuration xmlns:patch="http://www.sitecore.net/xmlconfig/" xmlns:role="http://www.sitecore.net/xmlconfig/role/" xmlns:search="http://www.sitecore.net/xmlconfig/search/">
   <sitecore search:require="solr">
      <contentSearch>
         <configuration type="Sitecore.ContentSearch.ContentSearchConfiguration, Sitecore.ContentSearch">
            <indexes hint="list:AddIndex">
               <index id="sitecore_master_index" type="Sitecore.ContentSearch.SolrProvider.SolrSearchIndex, Sitecore.ContentSearch.SolrProvider">
                  <param desc="core" patch:instead="param[@desc='core']">instancename_$(id)</param>
               </index>
               <index id="sitecore_core_index" type="Sitecore.ContentSearch.SolrProvider.SolrSearchIndex, Sitecore.ContentSearch.SolrProvider">
                  <param desc="core" patch:instead="param[@desc='core']">instancename_$(id)</param>
               </index>
               <index id="sitecore_web_index" type="Sitecore.ContentSearch.SolrProvider.SolrSearchIndex, Sitecore.ContentSearch.SolrProvider">
                  <param desc="core" patch:instead="param[@desc='core']">instancename_$(id)</param>
               </index>
               <index id="sitecore_marketingdefinitions_master" type="Sitecore.ContentSearch.SolrProvider.SolrSearchIndex, Sitecore.ContentSearch.SolrProvider">
                  <param desc="core" patch:instead="param[@desc='core']">instancename_$(id)</param>
               </index>
               <index id="sitecore_marketingdefinitions_web" type="Sitecore.ContentSearch.SolrProvider.SolrSearchIndex, Sitecore.ContentSearch.SolrProvider">
                  <param desc="core" patch:instead="param[@desc='core']">instancename_$(id)</param>
               </index>
               <index id="sitecore_marketing_asset_index_master" type="Sitecore.ContentSearch.SolrProvider.SolrSearchIndex, Sitecore.ContentSearch.SolrProvider">
                  <param desc="core" patch:instead="param[@desc='core']">instancename_$(id)</param>
               </index>
               <index id="sitecore_marketing_asset_index_web" type="Sitecore.ContentSearch.SolrProvider.SolrSearchIndex, Sitecore.ContentSearch.SolrProvider">
                  <param desc="core" patch:instead="param[@desc='core']">instancename_$(id)</param>
               </index>
               <index id="sitecore_testing_index" type="Sitecore.ContentSearch.SolrProvider.SolrSearchIndex, Sitecore.ContentSearch.SolrProvider">
                  <param desc="core" patch:instead="param[@desc='core']">instancename_$(id)</param>
               </index>
               <index id="sitecore_suggested_test_index" type="Sitecore.ContentSearch.SolrProvider.SolrSearchIndex, Sitecore.ContentSearch.SolrProvider">
                  <param desc="core" patch:instead="param[@desc='core']">instancename_$(id)</param>
               </index>
               <index id="sitecore_fxm_master_index" type="Sitecore.ContentSearch.SolrProvider.SolrSearchIndex, Sitecore.ContentSearch.SolrProvider">
                  <param desc="core" patch:instead="param[@desc='core']">instancename_$(id)</param>
               </index>
               <index id="sitecore_fxm_web_index" type="Sitecore.ContentSearch.SolrProvider.SolrSearchIndex, Sitecore.ContentSearch.SolrProvider">
                  <param desc="core" patch:instead="param[@desc='core']">instancename_$(id)</param>
               </index>
            </indexes>
         </configuration>
      </contentSearch>
   </sitecore>
</configuration>

Do not forget about added SXA indexes also if you will have them in the future and also for CD servers, you need to remove master indexes from the list.

In code you will reuse everything as you have as you are referencing solr index id so you will still reference "sitecore_master_index" or "sitecore_web_index" but based on the deployed configuration in each instance, you will effectively reference different Solr cores based on instance.

To identify Sitecore Solr cores quickly, you can go to ShowConfig admin page and search for <indexes hint="list:AddIndex".

You will see all 11 out of the box indexes and their respective configuration. You can quickly identify files in which are patched:

Example of search results for list:AddIndex in admin's show config page.

Improve this answer
5
  • 1
    I don't want to edit your answer in case it was intentional, but perhaps adding the wrapping elements around the patch file would be helpful? gist.github.com/JamesSkemp/ac988b63a826aea8f833df43d81f6973
    – James Skemp
    Commented Aug 14, 2018 at 17:17
  • 1
    It was intentional but I think it makes sense to have it there so somebody can just pick it up and use. Good point @JamesSkemp. Thanks
    – Peter Procházka
    Commented Aug 14, 2018 at 17:24
  • I know I spent more time than I would have liked realizing that search:require="lucene" needs to be added on old configs so ... there's that too. Thank you for the numerous updates you did on this answer to make it a great answer.
    – James Skemp
    Commented Aug 14, 2018 at 17:27
  • 1
    It is always like that :) Glad I could help you. I always try to not only answer the question but give some clarification for everybody ending on SSE to give also some quick overview and context.. You can edit my answer @JamesSkemp and update patch config so it's complete
    – Peter Procházka
    Commented Aug 14, 2018 at 17:50
  • 1
    +1 The config can be made less terse though by removing the type and patch:instead declarations from all nodes, they are superfluous and not required here.
    – jammykam
    Commented Aug 16, 2018 at 3:23

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.