Actions sur la base de données

MongoDB

Nettoyage

Cette section va lister différentes commandes pour purger des collections de la base de données. La connexion à la base et le nettoyage peuvent se faire via la ligne de commande (mongo canopsis -u cpsmongo -p MOT_DE_PASSE --host XXXX) ou bien via Robo3T. Dans les sous-sections suivantes, les commandes ont été réalisées en ligne de commande.

Attention

Cette manipulation a un impact métier important et ne doit être réalisée que par une personne compétente. Avant toute opération, il est vivement conseillé de faire une sauvegarde de la base MongoDB en utilisant mongorestore ainsi que d'arrêter Redis (systemctl stop redis) et le moteur che.

Avant de supprimer des documents, vous pouvez toujours vérifier la liste des documents concernés avec db.<nom de la collection>.find(<requête>) et voir leur nombre db.<nom de la collection>.count(<requête>). Ces fonctions prennent en paramètre une requête, qui va filtrer sur les documents de la collection.

Une fois que vous avez vérifié que les documents correspondent à ce que vous voulez supprimer, vous pouvez utiliser la commande db.<nom de la collection>.remove(<requête>). Au moment de la suppression, un message va indiquer le nombre d'éléments supprimés.

> db.periodical_alarm.remove({"t" : 1537894605})
WriteResult({ "nRemoved" : 3 })
> db.entities.remove({"name": "foldable"})
WriteResult({ "nRemoved" : 17 })

Attention

La requête vide {} va s'appliquer à tous les documents de la collection. Par conséquent, db.<nom de la collection>.remove({}) va vider complètement la collection. Pensez donc à ne jamais avoir {} comme paramètre, sauf si vous voulez vider complètement la collection.

Le tableau suivant montre plusieurs examples de requêtes sur les collections d'objets Canopsis, avec la collection MongoDB en italique et le filtre en gras. Pour rappel, les entités sont stockées dans la collection default_entities tandis que les alarmes sont stockées dans periodical_alarm, les pbehaviors dans default_pbehavior et les vues dans views.

Type d'objets Requête MongoDB
Action de type snooze db.default_action.find({"type":"snooze"})
Alarmes résolues db.periodical_alarm.find({"v.resolved":{$ne:null}})
Alarmes non résolues db.periodical_alarm.find({"v.resolved":null})
Alarmes associées à l'entité XXX/ZZZ db.periodical_alarm.find({"v.component" : "ZZZ", "v.resource" : "XXX"})
Alarmes non mises à jour depuis le 1er janvier 2019 00:00:00 GMT db.periodical_alarm.find({"v.last_update_date":{$lte:1546300800}})
Expression régulière sur l'attribut client dans l'entité db.default_entities.find({"infos.client.value":{$regex:'.*SSBU.*',$options:'i'}})
Pbehaviors créés par emile-zola db.default_pbehavior.find({"author":"emile-zola"})
Pbehaviors avec un tstart placé dans le futur db.default_pbehavior.find({"tstart" : {$gt : Math.floor(Date.now() / 1000)}}))
Vues désactivées db.views.find({"enabled":false})

Pour les requêtes sur les dates, vous pouvez vous aider de sites comme epochconverter.com pour convertir les dates en timestamp UNIX. Le timestamp correspondant au temps courant est Math.floor(Date.now() / 1000). Vous pouvez également vous servir des objets Date() pour les requêtes temporelles (voir la documentation officielle de MongoDB sur Date()) qu'il faudra convertir en timestamp pour le filtrage. L'exemple suivant montre l'affichage des alarmes non mises à jour depuis un mois.

> var d = new Date();
> d.setMonth(d.getMonth() - 1);
> oneMonthAgo = Math.floor(d / 1000);
> db.periodical_alarm.find({"v.last_update_date":{$lte:oneMonthAgo}})

Il est également possible de filtrer grâce aux expressions régulières en utilisant l'opérateur $regex (voir la documentation officielle de MongoDB sur $regex). Les deux lignes ci-dessous sont équivalentes, elles vont afficher les alarmes dont la ressource correspond à la regex .[0-9a-fA-F]+.

> db.periodical_alarm.find({"v.resource":{$regex:'[0-9a-f]+',$options:'i'}}) // L'option i rend la regex insensible à la casse
> db.periodical_alarm.find({"v.resource":{$regex:/[0-9a-f]+/i}})             // On retrouve ici également l'option i

Sauvegarde

Utilisez la commande mongodump via une tâche cron. De préférence, faites la sauvegarde sur un système de fichiers externe à la machine (NAS, SAN). Vous pouvez consulter la documentation de la commande en suivant ce lien.

Note

Le mot de passe par défaut est canopsis, mais il peut être nécessaire d'adapter la commande selon votre contexte.

mongodump --username cpsmongo --password canopsis --db canopsis --out /chemin/vers/sauvegarde

Restauration

Attention

Cette manipulation a un impact métier important et ne doit être réalisée que par une personne compétente. La restauration de la base de données ne doit être effectuée que si celle-ci est endommagée, pour corriger l'incident.

Avant de procéder à la restauration, arrêtez l'hyperviseur.

canoctl stop

Utilisez la commande mongorestore. De préférence, récupérez la sauvegarde depuis un système de fichiers externe à la machine (NAS, SAN). Vous pouvez consulter la documentation de la commande en suivant ce lien.

mongorestore --username cpsmongo --password canopsis --db canopsis /chemin/vers/sauvegarde

Note

Lors de la sauvegarde de la base, la commande crée un sous-dossier dans /chemin/vers/sauvegarde pour y stocker les fichiers. Ce sous-dossier doit être ajouté au chemin dans la commande mongorestore.

Si la restauration est réussie vous pouvez redémarrer l'hyperviseur.

canoctl start

InfluxDB

Sauvegarde

Utilisez la commande influxd backup via une tâche cron. De préférence, faites la sauvegarde sur un système de fichiers externe à la machine (NAS, SAN). Vous pouvez consulter la documentation de la commande en suivant ce lien.

influxd backup -portable -database canopsis /chemin/vers/sauvegarde

Restauration

Attention

Cette manipulation a un impact métier important et ne doit être réalisée que par une personne compétente. La restauration de la base de données ne doit être effectuée que si celle-ci est endommagée, pour de corriger l'incident.

Avant de procéder à la restauration, arrêtez l'hyperviseur.

canoctl stop

Utilisez la commande influxd restore. De préférence, récupérez la sauvegarde depuis un système de fichiers externe à la machine (NAS, SAN). Vous pouvez consulter la documentation de la commande en suivant ce lien.

influxd restore -portable /chemin/vers/sauvegarde

Note

Il est possible que la commande retourne un message d'erreur :

error updating meta: DB metadata not changed. database may already exist restore: DB metadata not changed. database may already exist

Il s'agit uniquement des métadonnées qui sont déjà présentes dans InfluxDB et qui n'ont pas changé. Le contenu de la table canopsis a bien été restauré.

Si la restauration est réussie vous pouvez redémarrer l'hyperviseur.

canoctl start