Replicating WebSphere Commerce search

You can replicate your search index data on both your master machine and subordinate machine to help improve reliability, fault-tolerance, and performance. Replicating WebSphere Commerce search maintains your search index data in more than one location, and involves copying designated changes for one location to another and synchronizing the data in both locations.

Note: The spell correction index cannot be replicated and must therefore be rebuilt locally on each subordinate server. There are two options to configure when this rebuild can take place by using the solrconfig.xml file - buildOnOptimize and buildOnCommit. When updates to the search index are frequent, building on commit can be expensive, especially for large indexes. Use buildOnOptimize or explicit build instead. For more information, see SpellCheckComponent

Procedure

On your master machine:
1. Open the following files:
  - solrhome/MC_masterCatalogId/en_US/CatalogEntry/conf/solrconfig.xml
  - solrhome/MC_masterCatalogId/en_US/CatalogEntry/unstructured/conf/solrconfig.xml
  - solrhome/MC_masterCatalogId/en_US/CatalogGroup/conf/solrconfig.xml
  - Where replication is set up for United States English (en_US). If you want to replicate for another language, change en_US to the locale of your choice.
2. Find and uncomment the section that resembles the following snippet:
```
<requestHandler name="/replication" class="solr.ReplicationHandler" >
    <lst name="master">
      <str name="replicateAfter">commit</str>
      <str name="replicateAfter">startup</str>
      <str name="confFiles">schema.xml,stopwords.txt,synonyms.txt</str>
    </lst>
</requestHandler>
```
3. Ensure that there is only a master section as above, and if necessary, by removing the slave (subordinate) section of the snippet.
  For more information, see SolrReplication
4. Save your changes and close the file.
5. Restart your search server and WebSphere Commerce server.
On your subordinate machine:
1. Open the following file:
  - solrhome/MC_masterCatalogId/en_US/catalogEntry/conf/solrconfig.xml
  - solrhome/MC_masterCatalogId/en_US/CatalogEntry/unstructured/conf/solrconfig.xml
  - solrhome/MC_masterCatalogId/en_US/CatalogGroup/conf/solrconfig.xml
2. Find and uncomment the section that resembles the following snippet:
  If search server application security is not enabled:
```
<requestHandler name="/replication" class="solr.ReplicationHandler" >
<lst name="slave">
<str name="masterUrl">http://searchServerName:searchServerPort/solr/coreName/replication</str>
<str name="pollInterval">00:00:60</str>
</lst>
</requestHandler>
```
  Where coreName is the name of the core related to the solrconfig.xml file you are updating.
  For example, if you are updating the solrhome/MC_masterCatalogId/en_US/CatalogEntry/unstructured/conf/solrconfig.xml file, the core name would be MC_masterCatalogId_CatalogEntry_Unstructured_en_US.
  If search server application security is enabled (Securing the WebSphere Commerce search server):
```
<requestHandler name="/replication" class="com.ibm.commerce.foundation.internal.server.services.search.handler.solr.SolrSearchReplicationHandler">
<lst name="slave">
<str name="masterUrl">http://searchServerName:searchServerPort/solr/MC_masterCatalogId_CatalogEntry_en_US/replication</str>
<str name="pollInterval">00:00:60</str>
<str name="httpBasicAuthUser">admin_user_id</str>
<str name="httpBasicAuthPassword">encrypted_admin_password</str>
</lst>
</requestHandler>
```
  Note: The default 60-second poll interval serves as a sample, where you must set it to the value that best fits your requirements. That is, when you set the poll interval, you must consider your replication schedule. There are two potential approaches:
  
  Use the replication enabling and disabling functions on the master server to have central control of the replication schedule. In this scenario, you might set a small interval number on targets so that the replication can start immediately after the replication is enabled on the master. After the replication completes, you can disable the replication on the master. In this scenario, you can manually control when to replicate WebSphere Commerce search.
  
  Use the pollInterval parameter to schedule automatic replication.
  
  Perform the same steps for the CatalogGroup snippet.
  
  When you use a staging server, consider minimizing the scheduled gap between stagingprop and index replication.
  When you start or restart the subordinate server, replication is not immediately started. The subordinate replication is triggered by the first query on the subordinate server and the replication starts when in the next interval cycle. So if you want immediate replication, set a smaller poll interval to let replication occur as soon as possible. After the replication is complete, reset the poll interval to its proper value and restart the subordinate and search server.
3. Ensure that there is only a slave section as above, and if necessary, by removing the master section of the snippet.
  For more information, see SolrReplication.
4. Save your changes and close the file.
5. Ensure that the following directory does not exist. It is created and populated with the replicated data later on:
  - solrhomeMC_masterCatalogId/en_US/CatalogEntry/data
  - solrhomeMC_masterCatalogId/en_US/CatalogEntry/unstructured/data
  - solrhome/MC_masterCatalogId/en_US/CatalogGroup/data
6. Restart your search server and WebSphere Commerce server.
Build the WebSphere Commerce search index on the master server.
Query your subordinate machine to trigger creating the solrhome/MC_10001/en_US/CatalogEntry/data and solrhome/MC_10001/en_US/CatalogEntry/unstructured/data directories.
For example, http://solrserverhostname:3737/solr/MC_10001_CatalogEntry_en_US/select?q=*:*
Wait until the first poll interval occurs.
Ensure that the data is replicated on your subordinate machine by navigating to the following directory:
- solrhome/MC_10001/en_US/CatalogEntry/data
- solrhome/MC_10001/en_US/CatalogEntry/unstructured/data
- solrhome/MC_masterCatalogId/en_US/CatalogGroup/data
This directory did not exist in a previous step, but should now exist with the replicated data copied from the master machine.
You can check the replication status on each subordinate node.
1. Run the following command:
```
http://subordinate_host:port/solr/MC_10001_CatalogEntry_en_US/replication?command=details
```
2. Check the value of the isReplicating flag to see its replication status.