Index verification extension points

The search index verification framework provides extension points for you for more fine-grained monitoring of index health.

Enable extension points

During verification, the replication handler triggers the check operation for cores in the managed configuration. On the master server, the entry point to call the operations is the core operation request handler, or our own defined custom request handler. Check operations logic is automatically triggered and run every time index replication completely downloads new index files and switches over to the new index. As a result, the upon success or upon failure operations are automatically triggered on the repeater and subordinate servers. In the managed configuration, we can use the search index verification framework by enabling healthCheckOps and setting the checkOps flag in the solrconfig.xml file.

<lst name="healthCheckOps">
       <str name="enable">${healthCheckOps.enable:false}</str>
       <str name="forceHealthCheckEveryPollInterval">${healthCheckOps.forceHealthCheckEveryPollInterval:true}</str>
       <str name="checkOps">${healthCheckOps.checkOps:com.ibm.commerce.foundation.solr.operation.SolrDoQueryCheckOperation}</str>
	<str name="uponSuccessOps">${healthCheckOps.uponSuccessOps:}</str>
	<str name="uponFailureOps">${healthCheckOps.uponFailureOps:}</str> 
</lst>	

healthCheckOps.checkOps provides access to classes we use to customize the verification process. In the example above, the class being called is SolrDoQueryCheckOperation. The classes enable you to back up, replicate and query your indexes.

Backing up the index

To protect customers' index, it is better to back up the replicated index once a replication is successful, but otherwise restore the latest backup copy of the index. We can use two classes for this purpose.

SolrDoIndexBackupOperation

Makes an index backup, by default, into core's /data/backups directory.

Once the backup is done, a folder named snapshot.timestamp will be created in /data/backups folder.

We can also invoke SolrDoIndexBackupOperation through core name/operation?command=backup. Using this syntax, the class accepts two extra optional parameters.

location

The folder other than /data/backups to hold backups, It can be a relative path (without leading slash /), which creates an arbitrary depth of path starting as a sibling of /data folder. Otherwise, the absolute path specifies the extract location for backups, if without file permission problem.

numberToKeep

the number of copies to be kept in the location Here is an example: <core name>/operation?command=backup&location=test/1&numberToKeep=2 This will have your backup stored in /test/1/snapshot.<timestamp> folder and at most two copies will be available.

SolrDoBackupRestoreOperation

Restores an index backup from core's /data/backups directory unless a location is specified. Once the restore is done, a folder named snapshot.backup timestamp.restored.restore timestamp be created in the /data folder./data/index.properties will be updated (or created if not exists) to point to the restored folder.

This class can also be invoked through core name/operation?command=restore, and can also take two optional parameters.

location

A folder other than /data/backups in which to look for backups. If there are multiple copies of backups, the latest one will be picked up by default.

backupName

A specific copy denoted by snapshot.timestamp to be used to restore the index. This parameter overrides the default behavior of selecting the latest index. For example:

core name/operation?command=restore&location=test/1&backupName=snapshot.timestamp

We can make these two operations automatically performed, based upon replication success or failure, by specifying the following properties.

• healthCheckOps.uponSuccessOps=com.ibm.commerce.foundation.solr.operation.SolrDoIndexBackupOperation

• healthCheckOps.uponFailureOps=com.ibm.commerce.foundation.solr.operation.SolrDoBackupRestoreOperation

See Extending the solrconfig.xml file.

Auxiliary operations

SolrDoFetchIndexOperation

Performs a replication from the Search master or a repeater. By default, it will retry the operation 5 times, each try having a 15 second interval. The class can be invoked through core name/operation?command=fetchIndex, and can take two optional parameters.

retryFetchIndexAttemptsLimit

Maximum number of retries allowed.

retryFetchIndexDelay

Interval between retries.

SolrDoStatusCheckOperation

Verifies the connectivity between master and repeater, or repeater and subordinate. It will report failure if the master node is not available. It will verify whether indexes on the master and subordinate node are synchronized.

SolrDoQueryCheckOperation

Performs a *:* query against the current active index, and reports the number of documents in the index.