Commandes d'administration MongoDB essentielles pour les débutants
Maîtrisez les commandes d'administration essentielles pour MongoDB à l'aide du shell `mongosh`. Ce guide couvre les tâches fondamentales pour les débutants, notamment le changement de base de données, la création/suppression de collections, la gestion des utilisateurs avec des rôles, et les vérifications cruciales de l'état du système comme `serverStatus`. Apprenez les commandes de base nécessaires pour gérer en toute sécurité votre environnement NoSQL.
Commandes d'administration MongoDB essentielles pour les débutants
L'administration de MongoDB commence dans mongosh, mais le but n'est pas de mémoriser chaque commande. Le but est de savoir comment naviguer en toute sécurité, confirmer où vous êtes, apporter de petites modifications délibérément et éviter les commandes destructrices sur la mauvaise base de données.
Si vous débutez avec MongoDB, exercez-vous d'abord sur une instance locale ou une base de données de développement jetable. Certaines commandes de ce guide, telles que dropDatabase() et drop(), suppriment définitivement des données. MongoDB fera ce que vous demandez ; il ne saura pas que vous vouliez exécuter la commande ailleurs.
Se connecter avec mongosh
Pour une instance MongoDB locale sur le port par défaut, connectez-vous avec :
mongosh
Pour un serveur distant, utilisez une chaîne de connexion fournie par votre administrateur ou votre hébergeur :
mongosh "mongodb://[email protected]:27017/admin"
Pour TLS, les ensembles de réplicas ou MongoDB Atlas, l'URI inclura plus d'options. Évitez de coller des mots de passe dans l'historique du shell dans la mesure du possible. Utilisez des invites, une gestion des secrets spécifique à l'environnement ou les outils d'identification de votre plateforme.
Une fois connecté, vérifiez où vous avez atterri :
db
Cela affiche le contexte actuel de la base de données. De nombreuses erreurs commencent par supposer que le shell pointe vers une base de données alors qu'il pointe vers une autre.
Lister et changer de base de données
Afficher les bases de données visibles :
show dbs
Vous ne verrez peut-être pas toutes les bases de données si votre utilisateur ne dispose pas des autorisations nécessaires. C'est normal dans les environnements sécurisés.
Changer le contexte de la base de données avec use :
use myAppDB
MongoDB ne crée pas la base de données immédiatement lorsque vous exécutez use. Il la crée lorsque des données sont écrites pour la première fois, par exemple lorsque vous insérez un document ou créez explicitement une collection.
Vérifiez à nouveau la base de données actuelle :
db
Pour les scripts, préférez les handles de base de données explicites afin que le code dépende moins du contexte du shell :
const appdb = db.getSiblingDB("myAppDB")
appdb.getCollectionNames()
Collections : lister, créer, inspecter, supprimer
Lister les collections dans la base de données actuelle :
show collections
Ou utilisez JavaScript :
db.getCollectionNames()
Créez une collection explicitement lorsque vous avez besoin d'options telles que la validation, le comportement limité (capped) ou les choix d'index/cluster pris en charge par votre version de MongoDB :
db.createCollection("logs")
La plupart des collections d'application sont créées automatiquement lors de la première insertion, mais la création explicite est plus claire pour la configuration administrative.
Inspecter les statistiques d'une collection :
db.orders.stats()
Voir les index :
db.orders.getIndexes()
Supprimer une collection est destructeur :
db.logs.drop()
Avant de l'exécuter dans un environnement partagé, confirmez la base de données et la collection :
db
db.getCollectionNames()
db.logs.countDocuments({})
Pour les très grandes collections, countDocuments({}) peut être coûteux. Dans ce cas, utilisez les métadonnées, l'échantillonnage ou les tableaux de bord opérationnels plutôt que d'exécuter des comptages larges pendant les heures de pointe.
Insérer un document de test et l'interroger
Même les administrateurs ont besoin de quelques bases CRUD pour la vérification. Insérez un petit document :
db.healthcheck.insertOne({ source: "admin-test", createdAt: new Date() })
Relisez-le :
db.healthcheck.find({ source: "admin-test" }).sort({ createdAt: -1 }).limit(5)
Supprimez uniquement le document de test :
db.healthcheck.deleteMany({ source: "admin-test" })
Utilisez des filtres spécifiques. Évitez les suppressions larges pendant l'apprentissage. Une commande comme deleteMany({}) supprime tous les documents de la collection.
Bases de l'administration des utilisateurs
Les commandes utilisateur s'exécutent sur la base de données où l'utilisateur est défini. Les utilisateurs administratifs sont souvent créés dans admin. Les utilisateurs d'application peuvent être créés dans la base de données de l'application, selon votre modèle de sécurité.
Passez à admin :
use admin
Créez un utilisateur administratif avec un mot de passe invité :
db.createUser({
user: "appAdmin",
pwd: passwordPrompt(),
roles: [
{ role: "userAdminAnyDatabase", db: "admin" },
{ role: "readWriteAnyDatabase", db: "admin" }
]
})
Pour une application normale, utilisez des autorisations plus restreintes. Par exemple, une application qui ne fait que lire et écrire dans myAppDB ne devrait pas recevoir de rôles d'administration larges :
use myAppDB
db.createUser({
user: "myAppUser",
pwd: passwordPrompt(),
roles: [
{ role: "readWrite", db: "myAppDB" }
]
})
Listez les utilisateurs dans la base de données actuelle :
show users
Mettez à jour les rôles avec précaution :
db.grantRolesToUser("myAppUser", [ { role: "read", db: "reporting" } ])
Supprimez les rôles tout aussi délibérément :
db.revokeRolesFromUser("myAppUser", [ { role: "read", db: "reporting" } ])
L'habitude la plus sûre est le moindre privilège : donnez à l'utilisateur uniquement la base de données et le rôle nécessaires à la tâche.
Statut du serveur et opérations en cours
serverStatus renvoie un document volumineux avec des compteurs et des informations d'exécution :
db.serverStatus()
Les débutants n'ont généralement pas besoin de tout le document. Extrayez les sections qui vous intéressent :
db.serverStatus().connections
db.serverStatus().mem
db.serverStatus().opcounters
Les opérations en cours peuvent aider lorsque quelque chose est bloqué ou lent :
db.currentOp()
Sur un serveur occupé, filtrez-le :
db.currentOp({ active: true, secs_running: { $gte: 5 } })
Ne tuez pas les opérations à la légère. Si vous devez en terminer une, inspectez-la d'abord et comprenez s'il s'agit d'une requête utilisateur, d'une construction d'index, d'une sauvegarde, d'une migration ou d'un travail de réplication interne.
Vérifications des ensembles de réplicas
Si votre déploiement est un ensemble de réplicas, ces commandes sont courantes :
rs.status()
rs.conf()
rs.status() affiche les membres, l'état, les informations sur l'opération en cours (optime) et quel nœud est primaire. Exécutez-le lorsque les applications signalent des échecs d'écriture, lorsqu'un nœud a redémarré ou lorsque l'on soupçonne un retard de réplication.
Pour une vérification rapide de la préférence de lecture, demandez qui le nœud actuel pense être :
db.hello()
Les exemples plus anciens peuvent utiliser isMaster(). Les versions plus récentes de MongoDB prennent en charge hello ; vous pouvez encore voir l'ancienne commande dans des scripts existants.
Les commandes dangereuses méritent des rituels
Pour les travaux destructeurs, ralentissez. Un rituel simple évite les pannes réelles :
db
show collections
// confirmer le nom d'hôte ou la chaîne de connexion dans votre invite de terminal ou vos notes
// confirmer le plan de sauvegarde ou de restauration s'il s'agit de la production
db.collectionName.drop()
Pour la suppression d'une base de données :
use databaseToRemove
db.dropDatabase()
Cette commande supprime la base de données actuelle. Le danger n'est pas la syntaxe ; le danger est d'être dans le mauvais contexte.
Une liste de contrôle administrative pour débutants
Lorsque vous vous connectez à un environnement MongoDB, habituez-vous à cette séquence :
db
show dbs
use myAppDB
show collections
db.orders.getIndexes()
db.serverStatus().connections
db.currentOp({ active: true })
Ces commandes vous indiquent où vous êtes, ce qui existe, si l'accès de base fonctionne et si quelque chose d'évident se produit en ce moment.
L'administration de MongoDB devient beaucoup moins intimidante lorsque vous traitez mongosh d'abord comme un outil d'inspection et ensuite comme un outil de modification. Regardez, confirmez, puis agissez. Utilisez des rôles restreints, des mots de passe invités, des requêtes filtrées et des noms de base de données explicites. Cette habitude est plus importante que de mémoriser une longue liste de commandes.
Lire attentivement les tailles des bases de données et des collections
Les débutants utilisent souvent show dbs comme outil de dimensionnement, mais ce n'est qu'un point de départ. Les moteurs de stockage, la compression, les index et l'espace supprimé peuvent rendre les chiffres de taille surprenants. Utilisez les statistiques de collection lorsque vous avez besoin de plus de détails :
db.orders.stats()
Regardez également la taille des index :
db.orders.totalIndexSize()
Les index ne sont pas gratuits. Ils accélèrent les lectures et certains tris, mais chaque index ajoute une surcharge d'écriture et de stockage. Si une collection a de nombreux index et que les écritures sont lentes, listez-les et demandez quelles requêtes les utilisent réellement :
db.orders.getIndexes()
db.orders.find({ customerId: "c123" }).explain("executionStats")
Ne supprimez pas les index à la légère en production. Un index qui semble inutilisé peut prendre en charge un rapport mensuel ou un écran d'administration rarement utilisé. Vérifiez les journaux de requêtes, les propriétaires d'applications et la surveillance avant de le supprimer.
Sensibilisation de base à la sauvegarde
L'administration en ligne de commande doit toujours être liée aux habitudes de sauvegarde. Avant une maintenance destructive, sachez comment la base de données est sauvegardée et comment la restauration a été testée. Dans MongoDB autogéré, vous pouvez voir mongodump et mongorestore pour les sauvegardes logiques :
mongodump --uri "mongodb://user@host:27017/myAppDB" --out ./backup
Pour les grands systèmes de production, les instantanés du système de fichiers, les instantanés du fournisseur de cloud, Ops Manager ou les sauvegardes Atlas peuvent être plus appropriés. Le point pour le débutant est simple : ne traitez pas drop, deleteMany ou les changements de rôle comme réversibles à moins d'avoir un chemin de restauration testé.
Une sauvegarde que vous n'avez jamais restaurée est une hypothèse. Entraînez-vous à restaurer dans un environnement non productif afin de connaître les identifiants, l'accès réseau et la compatibilité des versions avant un incident.
Vérifier les journaux lorsque les commandes ne suffisent pas
mongosh affiche les réponses du serveur, mais ne remplace pas les journaux. Si les utilisateurs signalent des requêtes lentes, des échecs d'authentification ou une variation du nombre de connexions, vérifiez les journaux MongoDB et les journaux de votre plateforme. Dans les déploiements Linux autogérés, les journaux peuvent se trouver sous /var/log/mongodb/, selon le package et la configuration. Dans les conteneurs, utilisez les journaux d'exécution du conteneur. Dans Atlas, utilisez l'interface utilisateur Atlas et les journaux téléchargeables.
Une erreur courante chez les débutants est de fixer serverStatus() alors que le véritable indice est un échec d'authentification, un problème DNS, une incompatibilité TLS ou un épuisement du pool de connexions d'application dans les journaux en dehors de MongoDB.
Connaître la différence entre les rôles de base de données et l'accès au système d'exploitation
Les utilisateurs MongoDB ne sont pas des utilisateurs Linux. Créer myAppUser dans MongoDB ne crée pas de compte shell. Donner à quelqu'un un accès SSH à un serveur de base de données ne lui donne pas automatiquement des autorisations sur la base de données, bien que cela puisse lui donner un accès indirect dangereux si le serveur est mal configuré.
Gardez ces couches séparées :
Utilisateur Linux : contrôle l'accès à l'hôte et aux fichiers
Utilisateur MongoDB : contrôle l'authentification et l'autorisation de la base de données
Politique réseau : contrôle qui peut atteindre le port MongoDB
TLS : protège le trafic et peut prendre en charge l'identité basée sur les certificats
Un déploiement sécurisé doit tous les prendre en compte. Un mot de passe MongoDB fort ne suffit pas si la base de données écoute publiquement sans règles de pare-feu. Un réseau privé ne suffit pas si chaque application utilise un rôle d'administration.
Une habitude plus sûre pour les shells de production
Lorsque vous travaillez en production, rendez l'invite et la connexion évidentes. Certaines équipes utilisent des couleurs de terminal, des alias shell ou des utilisateurs en lecture seule pour l'inspection. Au minimum, effectuez quelques vérifications d'identité après la connexion :
db.runCommand({ connectionStatus: 1 })
db
db.hello()
connectionStatus affiche les utilisateurs et rôles authentifiés. db montre le contexte. hello donne des informations sur la topologie. Ces trois vérifications évitent un nombre surprenant d'erreurs.
Pour une inspection de routine, utilisez un compte en lecture seule. Passez à un compte privilégié uniquement pour la fenêtre de modification spécifique. Cette petite friction est utile. Elle vous oblige à remarquer lorsque vous êtes sur le point de faire quelque chose qui peut modifier des données.
Quand s'arrêter et demander de l'aide
Certaines commandes MongoDB sont adaptées aux débutants ; d'autres non. Soyez prudent avec la reconfiguration des ensembles de réplicas, les métadonnées de sharding, les reconfigurations forcées, le kill d'opérations, la compaction de collections et la modification des paramètres d'authentification sur un système en direct. Ces actions peuvent affecter la disponibilité.
Si la commande modifie la topologie du cluster ou supprime des données, faites une pause et obtenez une deuxième vérification. Les meilleurs administrateurs ne sont pas ceux qui tapent le plus vite. Ce sont ceux qui savent quand une commande mérite une sauvegarde, une fenêtre de maintenance et un autre regard.
Comprendre le read concern et le write concern à un niveau élevé
Les débutants n'ont pas besoin de régler le read concern et le write concern dès le premier jour, mais ils doivent savoir que ces paramètres existent. Le write concern contrôle l'accusé de réception que MongoDB donne après une écriture. Un write concern plus fort peut attendre la réplication sur plus de membres. Un plus faible peut revenir plus tôt mais donne moins d'assurance quant à la durabilité en cas de panne.
Le read concern contrôle le niveau de cohérence des données demandé par une lecture. Dans de nombreuses applications simples, les valeurs par défaut sont suffisantes, mais dans les ensembles de réplicas et les systèmes distribués, ces paramètres influencent ce que votre application peut supposer en toute sécurité après un basculement ou pendant un retard de réplication.
La leçon administrative est pratique : lorsque quelqu'un signale "MongoDB a perdu une écriture" ou "l'application a lu des données obsolètes", ne regardez pas seulement la commande d'insertion. Vérifiez les paramètres du pilote, le write concern, la read preference, le read concern, l'état de l'ensemble de réplicas et le comportement de nouvelle tentative de l'application.
Faire attention aux exemples copiés sur Internet
La syntaxe de MongoDB a changé au fil du temps. Les anciens articles de blog peuvent utiliser l'ancien shell mongo au lieu de mongosh, d'anciens noms d'aide, ou des commandes qui fonctionnent encore mais ne sont plus préférées. Certains exemples s'exécutent également avec l'authentification désactivée, ce qui n'est pas une hypothèse de production sûre.
Lorsque vous copiez une commande, posez trois questions :
Pour quelle version de MongoDB a-t-elle été écrite ?
Dans quel contexte de base de données s'exécute-t-elle ?
De quelles autorisations l'utilisateur connecté a-t-il besoin ?
Si la commande est destructive, ajoutez une quatrième question : comment restaurer si cela tourne mal ?
Utiliser Compass et Atlas sans abandonner le shell
Les outils graphiques sont utiles. MongoDB Compass peut aider à inspecter les documents, les index et les plans de requête. Atlas fournit la surveillance, les sauvegardes, les alertes et la gestion des utilisateurs pour les clusters hébergés. Ces outils sont souvent plus faciles pour l'inspection visuelle que la sortie brute du shell.
Néanmoins, apprenez les commandes du shell. Lors d'incidents, d'automatisation, d'environnements SSH uniquement ou de revues de documentation, une commande mongosh précise est plus facile à partager que "cliquez sur le troisième onglet de l'interface utilisateur". Le meilleur workflow n'est pas shell contre GUI. Utilisez la GUI pour explorer et le shell pour exprimer clairement des actions reproductibles.