| Scroll Ignore | ||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||||
|
Description
La méthode pour sauvegarder et restaurer manuellement la rétention dépend du type de module de rétention utilisé par vos Schedulers :
- Le module PickleRetentionFile ( voir le chapitre Sauvegarde et restauration de la rétention avec le module PickleRetentionFile ) ;
- Le module MongodbRetention ( voir le chapitre Sauvegarde et restauration de la rétention avec le module MongodbRetention ) ;
| Info |
|---|
Vous trouverez plus d'information sur ces modules sur les pages décrivant leur mise en place : |
| Anchor | ||||
|---|---|---|---|---|
|
Où trouver la rétention Pickle
Lorsque le module PickleRetentionFile est utilisé, la sauvegarde de la rétention se fait dans un fichier situé par défaut au chemin suivant : /var/lib/shinken/
Il est possible que ce chemin ait changé en fonction de la configuration des modules PickleRetentionFile utilisés par vos Schedulers.
| Info |
|---|
Pour plus d'informations sur la configuration des modules PickleRetentionFile, référez-vous à cette page : Module PickleRetentionFile ( Rétention par fichier plat ) |
Voici un exemple complet de nom de fichier de rétention Pickle :
| Code Block | ||
|---|---|---|
| ||
/var/lib/shinken/retention.dat_--_realm--all_--_scheduler--scheduler-master_--_id--0.retention |
| Info |
|---|
Pour plus d'informations, référez-vous au chapitre détaillant le chemin des fichiers de rétention Pickle de la page expliquant le module PickleRetentionFile ( voir dans la page de configuration du Module PickleRetentionFile le chapitre Détails de le chemin des données de rétention ) |
Comment sauvegarder la rétention Pickle
Pour sauvegarder ces fichiers de rétention, il suffit de les copier à l'endroit souhaité avec la commande cp <source> <destination> :
| Code Block | ||
|---|---|---|
| ||
cp /var/lib/shinken/retention.dat_--_realm--all_--_scheduler--scheduler-master_--_id--0.retention /root/retention_save/ |
Cette commande va copier le fichier de rétention retention.dat_--_realm--all_--_scheduler--scheduler-master_--_id--0.retention dans le dossier nommé /root/retention_save/
| Info |
|---|
|
Comment restaurer la rétention Pickle
Restauration des fichiers de rétention
Pour restaurer un fichier de rétention Pickle, il suffit de le remettre à l'endroit depuis lequel ils ont été copiés : /var/lib/shinken/
Si les fichiers ont été copiés dans un dossier nommé /root/retention_save/, alors la commande pour restaurer la rétention devrait ressembler à ça :
| Code Block | ||
|---|---|---|
| ||
cp /root/retention_save/retention.dat_--_realm--all_--_scheduler--scheduler-master_--_id--0.retention /var/lib/shinken/ |
| Warning |
|---|
Attention, la commande cp écrase la destination ! Avant de restaurer les fichiers Pickle, assurez-vous qu'il n'y a pas de fichier du même nom dans /var/lib/shinken/, ou assurez-vous de les sauvegarder si besoin. |
Redémarrage du Scheduler
Après avoir restauré les fichiers de rétention, il faut redémarrer le Scheduler pour que les changements fassent effet :
| Code Block | ||
|---|---|---|
| ||
service shinken-scheduler restart |
| Anchor | ||||
|---|---|---|---|---|
|
Sauvegarde et restauration de la rétention avec le module MongodbRetention
Où se trouve la rétention dans Mongo
Avec le module MongodbRetention, la rétention se trouve dans la base shinken ( par défaut ) dans les collections retention_hosts_raw et retention_services_raw.
| Note |
|---|
Pensez à vérifier que vous n'avez pas changé le nom de la base par défaut ( shinken ), dans le cas contraire, il faudra changer le nom de la base dans la commande ( paramètre "-d" ) |
Comment sauvegarder la rétention MongodbRetention
Avant de lancer la sauvegarde
Avant de sauvegarder la rétention, il est conseillé ( si possible ) de redémarrer le Scheduler afin de forcer la rétention, et donc d'avoir des données plus fraiches :
| Code Block | ||
|---|---|---|
| ||
service shinken-scheduler restart |
| Anchor | ||||
|---|---|---|---|---|
|
Détails de la commande mongodump
Pour enregistrer les données de ces collections, on utilise la commande mongodump :
| Code Block | ||
|---|---|---|
| ||
mongodump -d DATABASE_NAME -c COLLECTION_NAME -h HOST_NAME --poty=HTTP_PORT --ssl -o OUTPUT_NAME |
Explication des paramètres :
| Paramètre | Obligatoire | Exemple | Description | ||
|---|---|---|---|---|---|
| Oui | shinken | Nom de la base Mongo | ||
| Oui | retention_hosts_raw | Nom de la collection Mongo | ||
| Non | 192.168.1.25 | Adresse IP ou nom de l'hôte où se trouve la base MongoDB utilisée par le Scheduler pour sauvegarder sa rétention. Non nécessaire si la commande est lancée sur le même serveur. | ||
| Non | 27018 | Port HTTP de la base MongoDB ( et non du serveur ). Par défaut le port utilisé est 27017. Ce port peut être trouvé par défaut dans le fichier /etc/mongod.conf ( ou /etc/mongos.conf si vous utilisez MongoDB en cluster ). Si vous avez changé le port de MongoDB ( par défaut 27017 ) il faut le préciser via ce paramètre, même en local. | ||
| Non | - | Si votre base MongoDB utilise le SSL, il faut ajouter cette option qui ne prend pas d'arguments. | ||
| Non | retention_hosts_11_10_2021 | Nom du fichier de sortie de la commande. Ce paramètre est optionnel, mais nous vous recommandons de donner un nom parlant au dossier créé par mongodump. Si ce paramètre n'est pas renseigné, alors le dossier sera nommé dump. |
| Note |
|---|
Si vous utilisez MongoDB en mode cluster, il faut s'assurer de communiquer avec le bon service. Cette explication se trouve dans le chapitre expliquant le cas particulier du cluster MongoDB ( voir le chapitre Cas particulier de l'utilisation d'un cluster MongoDB ). |
| Info |
|---|
|
Ces deux commandes vont créer deux dossiers à l'emplacement /root/retention_mongo/ ( assurez-vous que ce chemin existe ) nommé retention_hosts_11_10_2021 et retention_services_11_10_2021 contenant des fichiers .json et .bson qui contiennent les données des collections correspondantes.
Quelques exemples de mongodump
Sauvegarde de la rétention sur une MongoDB en local
Pour sauvegarder la rétention dans deux dossiers retention_hosts_11_10_2021 et retention_services_11_10_2021 depuis un MongoDB sur le même serveur où ces commandes sont lancées :
| Code Block | ||
|---|---|---|
| ||
mongodump -d shinken -c retention_hosts_raw -o /root/retention_mongo/retention_hosts_11_10_2021 mongodump -d shinken -c retention_services_raw -o /root/retention_mongo/retention_services_11_10_2021 |
Sauvegarde de la rétention sur une MongoDB sur un autre serveur
Pour sauvegarder la rétention dans deux dossiers retention_hosts_11_10_2021 et retention_services_11_10_2021 depuis un MongoDB sur un serveur hébergé sur un serveur nommé host_bordeaux et où MongoDB utilise le port 27018.
| Code Block | ||
|---|---|---|
| ||
mongodump -d shinken -c retention_hosts_raw -h host_bordeaux --port=27018 -o /root/retention_mongo/retention_hosts_11_10_2021 mongodump -d shinken -c retention_services_raw -h host_bordeaux --port=27018 -o /root/retention_mongo/retention_services_11_10_2021 |
Sauvegarde de la rétention sur une MongoDB sur un autre serveur qui utilise le SSL
Pour sauvegarder la rétention dans deux dossiers retention_hosts_11_10_2021 et retention_services_11_10_2021 depuis un MongoDB sur un serveur hébergé sur un serveur nommé host_bordeaux, où MongoDB utilise le port 27017 ( port par défaut ) et utilisant le SSL :
| Code Block | ||
|---|---|---|
| ||
mongodump -d shinken -c retention_hosts_raw -h host_bordeaux --ssl -o /root/retention_mongo/retention_hosts_11_10_2021 mongodump -d shinken -c retention_services_raw -h host_bordeaux --ssl -o /root/retention_mongo/retention_services_11_10_2021 |
Exemple de retour avec succès de la commande
| Code Block | ||
|---|---|---|
| ||
2021-10-12T11:09:12.823+0200 writing shinken.retention_services_raw to /root/retention_hosts_11_10_2021/shinken/retention_services_raw.bson 2021-10-12T11:09:12.823+0200 writing shinken.retention_services_raw metadata to /root/retention_hosts_11_10_2021/shinken/retention_services_raw.metadata.json 2021-10-12T11:09:12.825+0200 the collection shinken.retention_services_raw appears to have been dropped after the dump started 2021-10-12T11:09:12.825+0200 done dumping shinken.retention_services_raw (45 documents) |
| Note |
|---|
Si sur la dernière ligne du retour de la commande, il y a écrit "(0 documents)", alors il y a peut-être un problème quelque part, comme le nom de la collection qui n'est pas correcte. |
Comment restaurer la rétention MongodbRetention
Avant de sauvegarder la rétention
Avant d'effectuer la restauration de la rétention, il est conseillé d'éteindre le Scheduler :
| Code Block | ||
|---|---|---|
| ||
service shinken-scheduler stop |
| Anchor | ||||
|---|---|---|---|---|
|
Détails de la commande mongorestore
La restauration des données issues de la commande mongodump se fait avec la commande mongorestore :
| Code Block | ||
|---|---|---|
| ||
mongorestore --drop --ssl -h HOST_NAME --port=HTTP_PORT RETENTION_FOLDER_PATH |
| Paramètre | Obligatoire | Exemple | Description | ||||
|---|---|---|---|---|---|---|---|
| Non mais conseillé | - | Sans ce paramètre, MongoDB va tenter de garder les collections présentes actuellement dans la base, ce qui peut résulter en des mélanges de données non souhaitées. Pour retrouver la rétention au même état qu'au moment de sa sauvegarde, il faut utiliser ce paramètre.
| ||||
| Non | - | Si votre base MongoDB utilise le SSL, il faut ajouter cette option qui ne prend pas d'arguments. | ||||
| Non | 192.168.1.25 | Adresse IP ou nom de l'hôte où se trouve la base MongoDB utilisée par le Scheduler pour sauvegarder sa rétention. Non nécessaire si la commande est lancée sur le même serveur. | ||||
| Non | 27018 | Port HTTP de la base MongoDB ( et non du serveur ). Par défaut le port utilisé est 27017. Ce port peut être trouvé par défaut dans le fichier /etc/mongod.conf ( ou /etc/mongos.conf si vous utilisez MongoDB en cluster ). Si vous avez changé le port de MongoDB ( par défaut 27017 ) il faut le préciser via ce paramètre, même en local. | ||||
| Oui | /root/retention_hosts_11_10_2021/ | Chemin vers le dossier contenant la sauvegarde de la rétention qui a été créé avec la commande mongodump ( pour plus d'explication voir le chapitre mongodump ). Le dossier doit être sur le même serveur que celle où la commande est lancée. |
| Note |
|---|
Si vous utilisez MongoDB en mode cluster, il faut s'assurer de communiquer avec le bon service. Cette explication se trouve dans le chapitre expliquant le cas particulier du cluster MongoDB ( voir le chapitre Cas particulier de l'utilisation d'un cluster MongoDB ). |
Quelques exemples de commandes de restauration
Restauration d'une rétention sur un MongoDB en local
Cette commande va restaurer dans un MongoDB local les données contenues dans le dossier /root/retention_hosts_11_10_2021/
| Code Block | ||
|---|---|---|
| ||
mongorestore --drop /root/retention_hosts_11_10_2021/ |
Restauration d'une rétention sur un MongoDB sur un autre serveur
Cette commande va restaurer dans un MongoDB sur un serveur nommé host_bordeaux où MongoDB utilise le port 27018 les données contenues dans le dossier /root/retention_hosts_11_10_2021/
| Code Block | ||
|---|---|---|
| ||
mongorestore --drop -h host_bordeaux --port=27018 /root/retention_hosts_11_10_2021/ |
Restauration d'une rétention sur un MongoDB sur un autre serveur qui utilise le SSL
Cette commande va restaurer dans un MongoDB sur un serveur nommé host_bordeaux avec le port 27018 et utilisant le SSL, les données contenues dans le dossier /root/retention_hosts_11_10_2021/
| Code Block | ||
|---|---|---|
| ||
mongorestore --drop --ssl -h host_bordeaux --port=27018 /root/retention_hosts_11_10_2021/ |
Exemple de retour avec succès d'une commande de restauration
| Code Block | ||
|---|---|---|
| ||
2021-10-12T11:11:01.024+0200 building a list of dbs and collections to restore from /root/retention_hosts_11_10_2021/ dir 2021-10-12T11:11:01.026+0200 reading metadata file from /root/retention_hosts_11_10_2021/shinken/retention_services_raw.metadata.json 2021-10-12T11:11:01.026+0200 restoring shinken.retention_services_raw from file /root/retention_hosts_11_10_2021/shinken/retention_services_raw.bson 2021-10-12T11:11:01.027+0200 finished restoring shinken.retention_services_raw (45 documents) 2021-10-12T11:11:01.027+0200 done |
| Note |
|---|
Si sur l'avant-dernière ligne du retour de la commande, il y a écrit "(0 documents)", alors il y a peut-être un problème quelque part, comme la commande mongodump qui s'est mal passée ( nom de collection incorrect par exemple ) |
Après la restauration de la rétention
Une fois la restauration terminée, vous pouvez redémarrer le Scheduler :
| Code Block | ||
|---|---|---|
| ||
service shinken-scheduler start |
| Anchor | ||||
|---|---|---|---|---|
|
Cas particulier de l'utilisation d'un cluster MongoDB
Si vous utilisez MongoDB en mode cluster, les commandes restent les mêmes, à la nuance près qu'il faut préciser le port du bon service et il faut s'assurer d'avoir fait la sauvegarde de tous les replicaset.
- Pour sauvegarder l'entièreté d'un replicaset, il faut s'assurer de lancer les commandes sur le service mongos et non mongod.
- Pour utiliser un service plutôt que l'autre, il suffit de trouver et utiliser son port à fournir aux commandes.
| Info |
|---|
Pour plus d'informations sur les clusters et les termes de MongoDB liés à ce sujet, référez-vous à la page d'explication sur la mise en place d'un cluster MongoDB ( voir la page Haute disponibilité de la base MongoDB (mise en place d'un cluster) ) |
Vérifier la présence du service mongos
Pour vérifier si un mongos est sur un serveur et qu'il est opérationnel, il est possible de vérifier en demandant le statut du service mongos :
| Code Block | ||
|---|---|---|
| ||
service mongos status |
Si un processus mongos tourne sur le serveur sur lequel la commande a été lancée, alors le retour de la commande devrait ressembler à ça :
| Code Block | ||
|---|---|---|
| ||
● mongos.service - SYSV: Mongo is a scalable, document-oriented database.
Loaded: loaded (/etc/rc.d/init.d/mongos; bad; vendor preset: disabled)
Active: active (running) since Tue 2021-10-19 11:04:58 CEST; 53min ago
Docs: man:systemd-sysv-generator(8)
Process: 2805 ExecStart=/etc/rc.d/init.d/mongos start (code=exited, status=0/SUCCESS)
CGroup: /system.slice/mongos.service
└─2820 /usr/bin/mongos -f /etc/mongos.conf
|
| Info |
|---|
Si la commande précédente échoue, il est possible que le processus mongos se trouve sur un autre serveur. |
| Anchor | ||||
|---|---|---|---|---|
|
Trouver le port du service mongos
Le port se trouve dans le fichier de configuration de mongos ( par défaut dans /etc/mongos.conf ) :
| Code Block | ||
|---|---|---|
| ||
...
# network interfaces
net:
port: 27018
bindIp: 192.168.1.100
sharding:
configDB: primary:27019, secondary1:27019, secondary2:27019
... |
Le port souhaité est celui indiqué dans la section "net", dans notre exemple, ce sera le port du service mongos est 27018.
Exemples de restauration et de sauvegarde
Après avoir trouvé le port du bon service, disons 27018, il faut le renseigner aux commandes de sauvegarde et de restauration :
Exemple de sauvegarde
| Code Block | ||
|---|---|---|
| ||
mongodump --port=27018 -d shinken -c retention_hosts_raw -o /root/retention_mongo/retention_hosts_11_10_2021 mongodump --port=27018 -d shinken -c retention_services_raw -o /root/retention_mongo/retention_services_11_10_2021 |
| Info |
|---|
Pour plus de détails sur la commande mongodump, référez-vous au chapitre : Détails de la commande mongodump |
Exemple de restauration
| Code Block | ||
|---|---|---|
| ||
mongorestore --port=27018 --drop /root/retention_mongo/retention_hosts_11_10_2021 mongorestore --port=27018 --drop /root/retention_mongo/retention_services_11_10_2021 |
| Info |
|---|
Pour plus de détails sur la commande mongorestore, référez-vous au chapitre : Détails de la commande mongorestore |
Faire la sauvegarde et restauration de tous les replicaset
Pour sauvegarder et restaurer l'entièreté d'un cluster MongoDB, il faut faire le tour de tous les replicaset.
Il peut y avoir plusieurs services mongos chargés des mêmes replicaset, il n'est pas nécessaire de faire une sauvegarde / restauration par mongos, mais une par replicaset.
Pour vérifier quel replicaset un service mongos est chargé, vous pouvez utiliser cette commande :
| Code Block | ||
|---|---|---|
| ||
mongo --quiet --port MONGOS_PORT --eval "printjson(rs.status().set)" |
| Note |
|---|
Pensez à remplacer MONGOS_PORT par le port du service mongos, vous pouvez vous référez au chapitre sur comment trouver le port du service mongos ( voir le chapitre Trouver le port du service mongos ) |
Cette commande retourne le nom du replicaset gérée par le service ayant le port 27018.
Exemple de retour :
| Code Block | ||
|---|---|---|
| ||
$ mongo --quiet --port 27018 --eval "printjson(rs.status().set)" "replicaset-name" |
| Info |
|---|
Pour plus d'informations sur la récupération d'informations d'un replicaset, référez-vous à l'étape 4 de la procédure de configuration de la page sur la mise en place d'un cluster MongoDB ( voir le chapitre Etape 4: Déclaration du replicaset dans Mongo ) |
Une fois vos replicaset identifiés, vous pouvez lancer les commande de sauvegarde et de restauration sur un mongos par replicaset.
Les détails de ces commandes sont disponibles dans ces chapitres :