Points d'extension de vérification d'index

La structure de vérification de l'index de recherche vous fournit des points d'extension pour une surveillance plus précise de l'intégrité de l'index.

Activation des points d'extension

Lors de la vérification, le gestionnaire de réplication déclenche l'opération de vérification des noyaux dans la configuration gérée. Sur le serveur principal, le point d'entrée pour appeler les opérations est le gestionnaire de requêtes d'opération de base, ou votre propre gestionnaire de requête personnalisé. La logique des opérations Vérifier est automatiquement déclenchée et exécutée chaque fois que la réplication de l'index télécharge complètement de nouveaux fichiers d'index et bascule vers le nouvel index. Par conséquent, les opérations Lors de la réussite ou Lors de l'échec sont automatiquement déclenchées sur le répéteur et les serveurs subordonnés.

Dans la configuration gérée, vous pouvez utiliser la structure de vérification de l'index de recherche en activant healthCheckOps et en définissant l'indicateur checkOps dans le fichier solrconfig.xml.


<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 permet d'accéder aux classes que vous pouvez utiliser pour personnaliser le processus de vérification. Dans l'exemple ci-dessus, la classe appelée est SolrDoQueryCheckOperation. Les classes vous permettent de sauvegarder, de reproduire et d'interroger vos index.

Sauvegarde de l'index

Pour protéger l'index des clients, il est préférable de sauvegarder l'index répliqué une fois qu'une réplication est réussie, ou de restaurer la dernière copie de sauvegarde de l'index. Vous pouvez utiliser deux classes à cette fin.

SolrDoIndexBackupOperation

Effectue une sauvegarde d'index, par défaut, dans le répertoire de base /data/backups.

Une fois la sauvegarde terminée, un dossier nommé snapshot.timestamp sera créé dans le dossier /data/backups.

Vous pouvez également appeler SolrDoIndexBackupOperation via core name/operation?command=backup. A l'aide de cette syntaxe, la classe accepte deux paramètres facultatifs supplémentaires.

emplacement: Le dossier autre que /data/backups pour contenir des sauvegardes. Il peut s'agir d'un chemin d'accès relatif (sans barre oblique de début /), ce qui crée une profondeur arbitraire de chemin commençant comme un élément apparenté du dossier /data. Sinon, le chemin absolu spécifie l'emplacement d'extraction pour les sauvegardes, s'il n'y a pas de problème de droit d'accès au fichier.
numberToKeep: le nombre d'exemplaires à conserver dans l'emplacement. Voici un exemple : <core name>/operation?command=backup&location=test/1&numberToKeep=2 Votre sauvegarde sera stockée dans le dossier /test/1/snapshot.<timestamp> et au maximum deux copies seront disponibles.

SolrDoBackupRestoreOperation

Restaure une sauvegarde d'index à partir du répertoire /data/backups du noyau, sauf si un emplacement est indiqué. Une fois la restauration effectuée, un dossier nommé snapshot.backup timestamp.restored.restore timestamp sera créé dans /data folder./data/index.properties sera mis à jour (ou créé s'il n'existe pas) pour pointer vers le dossier restauré.

Cette classe peut également être appelée via core name/operation?command=restore, et peut également prendre deux paramètres facultatifs.

emplacement

Un dossier autre que /data/backups dans lequel rechercher des sauvegardes. S'il existe plusieurs copies de sauvegardes, la dernière sera récupérée par défaut.

backupName

Une copie spécifique désignée par snapshot.timestamp à utiliser afin de restaurer l'index. Ce paramètre remplace le comportement par défaut de la sélection de l'index le plus récent. Par exemple :

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

Vous pouvez effectuer ces deux opérations automatiquement, en fonction de la réussite ou de l'échec de la réplication, en spécifiant les propriétés suivantes.

healthCheckOps.uponSuccessOps=com.ibm.commerce.foundation.solr.operation.SolrDoIndexBackupOperation
healthCheckOps.uponFailureOps=com.ibm.commerce.foundation.solr.operation.SolrDoBackupRestoreOperation

Pour plus d'informations, voir Extension du fichier solrconfig.xml.

Opérations auxiliaires

SolrDoFetchIndexOperation

Effectue une réplication à partir du maître de recherche ou d'un répéteur. Par défaut, il réessayera l'opération 5 fois, chaque essai ayant un intervalle de 15 secondes. La classe peut être appelée via core name/operation?command=fetchIndex, et peut prendre deux paramètres facultatifs.

retryFetchIndexAttemptsLimit: Nombre maximal de tentatives autorisé.
retryFetchIndexDelay: Intervalle entre les tentatives.

SolrDoStatusCheckOperation

Vérifie la connectivité entre le maître et le répéteur, ou le répéteur et le subordonné. Elle signalera l'échec si le nœud maître n'est pas disponible. Elle vérifie si les index du nœud maître et du nœud subordonné sont synchronisés.

SolrDoQueryCheckOperation

Effectue une requête *:* au niveau de l'index actif actuel et signale le nombre de documents dans l'index.