Introduction
Ce document décrit comment réparer MongoDB sur l'appliance Secure Network Analytics (anciennement StealthWatch) Manager après un arrêt non nettoyé.
Conditions préalables
Exigences
Aucune exigence spécifique n'est associée à ce document.
Composants utilisés
Ce document n'est pas limité à des versions de matériel et de logiciel spécifiques.
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. Si votre réseau est actif, assurez-vous de comprendre l'impact potentiel de toute commande. »
Consulter les données du journal
Utilisez la commande pour consulter le fichier mongodb.log.
732smc:~# less /lancope/var/mongodb/log/mongodb.log
2021-06-21T14:54:43.029+0000 I CONTROL ***** SERVER RESTARTED *****
2021-06-21T14:54:43.033+0000 I CONTROL [initandlisten] MongoDB starting : pid=87057 port=27017 dbpath=/lancope/var/database/dbs/mdb/ 64-bit host=ussecrapstwsmc1
2021-06-21T14:54:43.033+0000 I CONTROL [initandlisten] db version v3.0.15
2021-06-21T14:54:43.033+0000 I CONTROL [initandlisten] git version: b8ff507269c382bc100fc52f75f48d54cd42ec3b
2021-06-21T14:54:43.033+0000 I CONTROL [initandlisten] build info: Linux 3555b2234f08 4.9.0-2-amd64 #1 SMP Debian 4.9.13-1 (2017-02-27) x86_64 BOOST_LIB_VERSION=1_49
2021-06-21T14:54:43.033+0000 I CONTROL [initandlisten] allocator: tcmalloc
2021-06-21T14:54:43.033+0000 I CONTROL [initandlisten] options: { config: "/etc/mongodb/mongodb.conf", net: { port: 27017 }, processManagement: { fork: true }, storage: { dbPath: "/lancope/var/database/dbs/mdb/" }, systemLog: { destination: "file", logAppend: true, path: "/lancope/var/mongodb/log/mongodb.log" } }
2021-06-21T14:54:43.050+0000 W - [initandlisten] Detected unclean shutdown - /lancope/var/database/dbs/mdb/mongod.lock is not empty.
2021-06-21T14:54:43.063+0000 I STORAGE [initandlisten] **************
old lock file: /lancope/var/database/dbs/mdb/mongod.lock. probably means unclean shutdown,
but there are no journal files to recover.
this is likely human error or filesystem corruption.
please make sure that your journal directory is mounted.
found 2 dbs.
see: http://dochub.mongodb.org/core/repair for more information
*************
2021-06-21T14:54:43.063+0000 I STORAGE [initandlisten] exception in initAndListen: 12596 old lock file, terminating
2021-06-21T14:54:43.063+0000 I CONTROL [initandlisten] dbexit: rc: 100
Réparer la base de données si elle ne démarre pas
Étape 1 : vérification de l’état des mongoles
Pour vérifier l'état de lc-mongodb.service, émettez la commande.
Si Mongo est dans un état actif, vos résultats ressembleront à :
732smc:/# systemctl is-active lc-mongodb
active
732smc:/#
Si Mongo n'est pas dans un état actif, vos résultats ressembleront à :
732smc:/# systemctl is-active lc-mongodb
inactive
732smc:/#
Étape 2 : Arrêtez le service Mongo
Si le service lc-mongodb est dans un état, arrêtez-le à l'aide de la commande.
732smc:/# /bin/systemctl stop lc-mongodb.service
732smc:/# /bin/systemctl status lc-mongodb.service | grep Active
Active: inactive (dead) since Thu 2022-04-07 12:33:49 UTC; 1s ago7
Attendez quelques instants et assurez-vous que le mongo reste dans un état d'arrêt. Utilisez la commande selon les besoins pour vous assurer que le service est dans un état.
Étape 3 : collecte de l'ID de processus (PID)
Vérifiez si le fichier de verrouillage contient toujours un PID. Entrez la commande suivante .
Cette sortie montre que le fichier de verrouillage contient le PID du service mongo. Ce fichier ne doit contenir des données que si le service est dans un état actif.
Remarque : Prenez note du PID s'il est renvoyé, tel qu'il est utilisé à l'étape 4
732smc:/# cat /lancope/var/database/dbs/mdb/mongod.lock
14259
732smc:/#
Ce résultat montre que le fichier de verrouillage ne contient pas de PID. Ce fichier doit être vide si le processus n'est pas dans un état actif. En l'absence de PID, passez à l'étape 7.
732smc:/# cat /lancope/var/database/dbs/mdb/mongod.lock
732smc:/#
Étape 4 : vérification de l’état du PID
Si le fichier mongod.lock vérifié à l'étape 3 contenait un PID, exécutez la commande [1]4259 avec votre PID à partir de l'étape 3) pour vérifier l'existence du PID, puis tuez ce PID s'il est trouvé.
Remarque : L'expression entre crochets n'est pas obligatoire, mais entraîne l'exclusion de la commande « grep » dans le résultat.
732smc:/# ps faux | grep [1]4259
mongodb 14259 0.3 0.4 516180 71520 ? Sl 12:38 0:03 /lancope/mongodb/bin/mongod --fork --config /etc/mongodb/mongodb.conf
732smc:/# kill -9 14259
732smc:/#
Étape 5. Effacer le contenu du fichier de verrouillage
Effacez le contenu du fichier de verrouillage à l'aide de la commande. Vérifiez que le fichier est maintenant vide à l'aide de la commande.
732smc:/# > /lancope/var/database/dbs/mdb/mongod.lock
732smc:/# cat /lancope/var/database/dbs/mdb/mongod.lock
732smc:/#
Étape 6. Tentative de démarrage de MongoDB
Essayez de démarrer le service lc-mongodb avec la commande. Une fois votre invite renvoyée, vérifiez l'état du processus à l'aide de la commande.
732smc:/# /bin/systemctl start lc-mongodb.service
732smc:/# /bin/systemctl status lc-mongodb.service | grep Active
Active: active (running) since Thu 2022-04-07 12:38:37 UTC; 27s ago
732smc:/#
Si le processus est dans un état actif, vérifiez à nouveau dans quelques minutes pour vous assurer qu'il reste dans un état actif. Vous n'avez pas besoin de réparer la base de données si elle reste en état de fonctionnement. Si le processus ne reste pas actif, passez à l'étape 7 et lancez un processus de réparation.
Étape 7. Lancer la réparation
Entrez la commande suivante
732smc:/# sudo -u mongodb /lancope/mongodb/bin/mongod --dbpath /lancope/var/database/dbs/mdb/ --repair
732smc:/#
Étape 8. Tentative de démarrage du MongoDB réparé
Exécutez la commande pour démarrer le service. Le processus doit rester actif et peut être vérifié à l'aide de cette commande.
732smc:/# /bin/systemctl start lc-mongodb.service
732smc:/# /bin/systemctl status lc-mongodb.service | grep Active
Active: active (running) since Thu 2022-04-07 12:38:37 UTC; 27s ago
Commentaires