Page History

Vous trouverez plus d'information sur ces modules sur les pages décrivant leur mise en place :

• Module PickleRetentionFile ( Rétention par fichier plat )
• Module MongodbRetention ( Rétention en base de donnée centralisée par royaume )

Pour plus d'informations sur la configuration des modules PickleRetentionFile, référez-vous à cette page : Module PickleRetentionFile ( Rétention par fichier plat )

/var/lib/shinken/retention.dat_--_realm--all_--_scheduler--scheduler-master_--_id--0.retention

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 )

cp /var/lib/shinken/retention.dat_--_realm--all_--_scheduler--scheduler-master_--_id--0.retention /root/retention_save/

• Le dossier de destination /root/retention_save/ doit exister avant de lancer la commande.

• Le dossier de destination /root/retention_save/ n'est qu'un exemple, choisissez où bon vous semble.

cp /root/retention_save/retention.dat_--_realm--all_--_scheduler--scheduler-master_--_id--0.retention /var/lib/shinken/ 

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.

service shinken-scheduler restart

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" )

service shinken-scheduler restart

mongodump -d DATABASE_NAME -c COLLECTION_NAME -h HOST_NAME --potyport=HTTP_PORT --ssl -o OUTPUT_NAME

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 ).

• Pour savoir quels paramètres utiliser, vous pouvez vous référer au fichier de configuration de votre Scheduler, par défaut ici : /etc/shinken/schedulers/scheduler-master.cfg
• Il est possible d'utiliser plusieurs fois le même OUTPUT_NAME, les données seront alors toutes sauvegardées dans le même dossier et donc peuvent être toutes restaurées avec qu'une seule commande mongorestore.

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

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

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

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)

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.

service shinken-scheduler stop

mongorestore --drop --ssl -h HOST_NAME --port=HTTP_PORT RETENTION_FOLDER_PATH

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 ).

mongorestore --drop /root/retention_hosts_11_10_2021/

mongorestore --drop -h host_bordeaux --port=27018 /root/retention_hosts_11_10_2021/

mongorestore --drop --ssl -h host_bordeaux --port=27018 /root/retention_hosts_11_10_2021/

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

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 )

service shinken-scheduler start

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) )

service mongos status

● 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

Si la commande précédente échoue, il est possible que le processus mongos se trouve sur un autre serveur.

...

# network interfaces
net:
  port: 27018
  bindIp: 192.168.1.100

sharding:
    configDB: primary:27019, secondary1:27019, secondary2:27019


...

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

Pour plus de détails sur la commande mongodump, référez-vous au chapitre : Détails de la commande mongodump

mongorestore --port=27018 --drop /root/retention_mongo/retention_hosts_11_10_2021
mongorestore --port=27018 --drop /root/retention_mongo/retention_services_11_10_2021

Pour plus de détails sur la commande mongorestore, référez-vous au chapitre  : Détails de la commande mongorestore

mongo --quiet --port MONGOS_PORT --eval "printjson(rs.status().set)"

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 )

$ mongo --quiet --port 27018 --eval "printjson(rs.status().set)"
"replicaset-name"

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 )