Une question fréquente est comment sauvegarder les données d’une collection et les restaurer au besoin. Dans cet article nous décrivons pour différents cas de figure comment restaurer partiellement ou totalement une collection Solr.
Pourquoi peut-il être nécessaire de sauvegarder les collections Solr ?
Une des caractéristiques de Solrcloud est la possibilité de dupliquer les données en créant des collections avec un facteur de réplication supérieur ou égale à deux. Plusieurs copies des données des shards de la collection sont ainsi présentes sur différents noeuds Solr. Il est donc possible si un nœud Solr est perdu (le serveur ou son stockage) de recréer les replicas qu’il hébergeait. Cette solution ne permet par contre pas de couvrir tous les cas de pertes de données comme des corruptions d’index, des actions accidentelles ou malveillantes de suppressions de collections ou de suppressions de données.
Pour ces cas de figure, il est nécessaire de ré-indexer la totalités des données depuis leur source (base de données, système de fichiers, web, …). La réindexation complète peut être compliquée et très longue. Il est donc souvent indispensable de disposer d’une sauvegarde datant de quelques heures voir de quelques jours afin de rétablir rapidement un service. La restauration sera suivi d’une ré-indexation partielle de mise à niveau des données ou d’une réindexation complète dans un autre index.
Scénario 1 : Recréation des replicas
Ce scénario suppose que le nœud Solr a du être totalement réinstallé ou que suite au redémarrage du nœud après un arrêt prolongé, le statut des réplicas de une ou plusieurs collections sont en « Recovery Failed »
Lors de la perte d’un nœud Solr, ce dernier pouvait héberger les données d’une ou plusieurs collections. Nous considérons ici le cas d’une collection dont les données du ou des shards hébergés sur ce nœud possèdent systématiquement des replicas sur un autre nœud Solr. Si pour une collection, ce n’est pas le cas, il faut pour cette dernière appliquer la procédure du scénario 2.
La première étape est de récupérer la liste des replicas du noeud Solr pour la collection à rétablir . Par l’intermédiaire d’un autre nœud fonctionnel, afficher le CLUSTERSTATUS de la collection. Solr2 est le nœud pour lequel il faut restaurer les données.
$ curl http://ip.du.serveur.fonctionnel:8983/solr/admin/collections?action=CLUSTERSTATUS
collections: {
sirene: {
pullReplicas: "0",
replicationFactor: "2",
shards: {
shard1: {
replicas: {
...
core_node12: {
core: "sirene_shard1_replica_n11",
base_url: "http://solr2:8983/solr",
node_name: "solr2:8983_solr",
state: "down"
}
}
}
Le nœud Solr2 pour la collection sirene hébergeait le réplica sirene_shard1_replica_n11 du shard1. Ce réplica est bien au statut « down ».
Nous allons supprimer ce réplica au moyen de commande DELETEREPLICA de la collection API
$ curl http://ip.du.serveur.fonctionnel:8983/solr/admin/collections?action=DELETEREPLICA&collection=sirene&shard=shard1&replica=sirene_shard1_replica_n11
Puis le recréer au moyen de la commande ADDREPLICA en spécifiant bien le nœud Solr cible (node=solr2:8983_solr)
$ curl http://ip.du.serveur.fonctionnel:8983/solr/admin/collections?action=ADDREPLICA&collection=sirene&shard=shard1&node=solr2:8983_solr
Les données sont automatiquement synchronisées d’un replica fonctionnel.
Scénario 2 : Restauration d’une collection
Sauvegarde
Le préalable à une restauration est bien évidement de disposer d’un backup de la collection.
Pour réaliser le backup, l’ensemble des nœuds Solr doivent accéder à un partage réseau commun avec les droits d’écriture pour l’utilisateur « solr ».
Sur un des nœuds de Solr, nous réalisons un backup de la collection « sirene » dans le partage « /opt/data/backup » et sous le nom « sirene_backup ».
$ curl http://ip.du.serveur:8983/solr/admin/collections?action=BACKUP&name=sirene_backup&collection=sirene&location=/opt/data/backup
{
responseHeader: {
status: 0,
QTime: 329
},
success: {
solr1:8983_solr: {
responseHeader: {
status: 0,
QTime: 209
}
},
solr4:8983_solr: {
responseHeader: {
status: 0,
QTime: 229
}
}
}
}
Le résultat est ceci dans le partage :
$ ls -l /opt/data/backup/sirene_backup/ total 16 -rw-rw-r-- 1 solr solr 183 Mar 14 16:39 backup.properties drwxrwxr-x 2 solr solr 4096 Mar 14 16:39 snapshot.shard1 drwxrwxr-x 2 solr solr 4096 Mar 14 16:39 snapshot.shard2 drwxrwxr-x 3 solr solr 4096 Mar 14 16:39 zk_backup
Restauration
La restauration recrée la collection et donc avant la restauration de la collection, il faut commencer par la supprimer complètement.
$ curl http://ip.du.serveur:8983/solr/admin/collections?action=DELETE&name=sirene
A titre d’exemple, nous restaurons la collection « sirene » dans une seconde collection « sirene2 »
$ curl http://ip.du.serveur:8983/solr/admin/collections?action=RESTORE&name=sirene_backup&location=/opt/data/backup&collection=sirene2
{
"responseHeader": {
"status": 0,
"QTime": 4782
},
"success": {
"solr1:8983_solr": {
"responseHeader": {
"status": 0,
"QTime": 739
},
"core": "sirene2_shard2_replica_n85"
},
"solr4:8983_solr": {
"responseHeader": {
"status": 0,
"QTime": 675
},
"core": "sirene2_shard1_replica_n87"
}
}
}
Le résultat est une collection sirene2 avec une distribution possiblement différente de la collection sirene, mais avec la même topologie (2 shards de 2 replicas).
|
Vous souhaitez bénéficier d’une expertise Solr ou intégrer une ressource ponctuelle à vos projets ? Rendez vous sur la page Contact |