Configuring the managed repeater and subordinates to perform index check validation

You can configure the managed repeater and subordinate index cores to perform index validation during replication. Index validation is triggered every time index replication completes downloading new index files into the repeater or subordinate. If both nodes are synchronized, hence, no files are downloaded, index validation is not run. Index validation is configured at the core level.

Configuring index validation on the repeater and subordinates ensures data integrity of the index by running predefined index queries against the latest replicated index. An entry is logged into the administration logger with the query check status.

WebSphere Commerce Version 8.0.3.0 or later

Note: Index validation can be configured to run at every poll interval when the forceHealthCheckEveryPollInterval property is set. Default is


true

When index validation is configured, an optional query check properties file with a list of queries can be specified. Otherwise, a default query of q=*:* is run, which is expected to return results greater than zero. The results of the index validation queries are then compared with predefined minimum result counts that a query should return. An entry is logged into the administration logger indicating the query check status.

WebSphere Commerce Version 8.0.3.0 or later In addition to the query check operation, a new index status check operation can be configured. This operation validates the last replication status, and checks whether a subordinate index is in sync with its master. The checks are done by examining the response of the /replication?command=details instruction.

WebSphere Commerce Version 8.0.3.0 or later A new uponFailure recovery operation will be invoked if either of the check operations returns false. It will retry replication logic for a configurable number of times. The status check operation will log an entry in the admin log if the status check shows "failed", or when "passed" if the same core had previously failed.

Before you begin

If you do not want to use the default query of q=*:*, you can optionally update the query check properties file to suit your business needs. Updating the query check properties file allows you to define specific validation queries in either a file named queryCheck.properties under the conf directory of each core, or in any property file residing in a common location among all cores. If no file is provided, the default query is run. For more information, see Query check properties file.

About this task

The following list shows the high-level steps that are associated with configuring the managed repeater and subordinates to perform index check validation:

Enable the index query check operation option in the managed repeater or subordinate.
Optional: Configure the query check properties file and save it into its default location.
Optional: Copy the query check property file into a common location among all cores.

Procedure

Enable the index query check operation option in the managed repeater or subordinate.
1. Open the solr.xml under the managed-solr repeater or subordinate directory file for editing.
2. Add the following property into each of the core configurations that are configured for replication:
```
<property name="healthCheckOps.enable" value="true"/>
```
3. Save your changes and close the file.
Optional: Configure the query check properties file and save it into its default location.
1. Copy the query check properties file you created in the prerequisites into the conf directory of the managed-solr repeater or subordinate configured in Step 1.
  
  For example: managed-solr/repeater/solr/home/MC_3074457345616676668/en_US/CatalogEntry/conf.
Optional: Copy the query check property file into a common location among all cores.
1. Copy the query check properties file you created in the prerequisites into a common location for all cores.
  
  For example: managed-solr/repeater/solr/home.
2. Add a new property into the solrcore.properties file under the conf directory of the managed-solr repeater or subordinate you configured in Step 1 to point to the common query check properties file.
  
  Note: Create the solrcore.properties file if it does not already exist.
  For example, in the managed-solr/repeater/solr/home/MC_3074457345616676668/en_US/CatalogEntry/conf/solrcore.properties file, add the following property:
```
com.ibm.commerce.foundation.solr.operation.SolrDoQueryCheckOperation.fileName= 
/usr/WebSphere/AppServer/profiles/demo_solr/installedApps/demo_search_cell/Search_demo.ear/managed-solr/repeater/solr/home/commonQueryCheck.properties
```
Optional: Change the default SolrDoFetchIndexOperation configurable properties. To change the default number of attempt to fetch the index, edit or create the solrcore.properties file and add the following properties.
1. To change the default number of attempt to fetch the index, add com.ibm.commerce.foundation.solr.operation.SolrDoFetchIndexOperation.retryFetchIndexAttemptsLimit=10, or any other positive number. (Default value is 5 if not specified)
2. To change the default wait time before each retry attempt, add com.ibm.commerce.foundation.solr.operation.SolrDoFetchIndexOperation.retryFetchIndexDelay=60000, or any other value which represents Milliseconds. (The default value is 15000 milliseconds.)

Results

After the managed-solr templates are deployed into the primary node, the next time index replication is completed, the query check operation will run and log an entry into the administration logger with the index validation status per core.

If a status check was configured, additional log entries are added under the following circumstances.

When failure is detected.
When succeeding after a failure.
When indicating that a retry attempt will be performed.
When the system has reached the maximum number of attempts.

For example,

[Fri Sep 16 19:20:21 EDT 2016] [wcsolr45.torolab.ibm.com] [00001021] 
     <com.ibm.commerce.foundation.solr.operation.SolrSearchCoreOperationProcessor:executeOperatios(String operationStr)> 
     LIFECYCLE OPERATION com.ibm.commerce.foundation.solr.operation.SolrDoStatusCheckOperation ON MC_3074457345616676668_CatalogEntry_fr_FR 
     IS FAILED.
.
.
[Fri Sep 16 19:20:21 EDT 2016] [wcsolr45.torolab.ibm.com] [00001021] 
     <com.ibm.commerce.foundation.solr.operation.SolrDoFetchIndexOperation:doOperation(NamedList operationProps)> 
     LIFECYCLE OPERATION com.ibm.commerce.foundation.solr.operation.SolrDoFetchIndexOperation ON MC_3074457345616676668_CatalogEntry_fr_FR 
     IS RETRYING REPLICATION LOGIC IN 15,000 MILLISECONDS . ATTEMPT NUMBER [1]
.
.
[Fri Sep 16 19:20:36 EDT 2016] [wcsolr45.torolab.ibm.com] [00001024] 
     <com.ibm.commerce.foundation.solr.operation.SolrSearchCoreOperationProcessor:executeOperatios(String operationStr)> 
     LIFECYCLE OPERATION com.ibm.commerce.foundation.solr.operation.SolrDoStatusCheckOperation ON MC_3074457345616676668_CatalogEntry_fr_FR 
     IS FAILED.
.
.
[Fri Sep 16 19:20:36 EDT 2016] [wcsolr45.torolab.ibm.com] [00001024] 
     <com.ibm.commerce.foundation.solr.operation.SolrDoFetchIndexOperation:doOperation(NamedList operationProps)> 
     LIFECYCLE OPERATION com.ibm.commerce.foundation.solr.operation.SolrDoFetchIndexOperation ON MC_3074457345616676668_CatalogEntry_fr_FR 
     IS RETRYING REPLICATION LOGIC IN 15,000 MILLISECONDS . ATTEMPT NUMBER [2]
.
.
[Fri Sep 16 19:20:51 EDT 2016] [wcsolr45.torolab.ibm.com] [00001028] 
     <com.ibm.commerce.foundation.solr.operation.SolrSearchCoreOperationProcessor:executeOperatios(String operationStr)> 
     LIFECYCLE OPERATION com.ibm.commerce.foundation.solr.operation.SolrDoStatusCheckOperation ON MC_3074457345616676668_CatalogEntry_fr_FR 
     IS PASSED.