Comandi Essenziali di Amministrazione MongoDB per Principianti

L'amministrazione di MongoDB inizia in mongosh, ma l'obiettivo non è memorizzare ogni comando. L'obiettivo è sapere come guardarsi intorno in sicurezza, confermare dove ci si trova, apportare piccole modifiche deliberate ed evitare comandi distruttivi sul database sbagliato.

Se sei nuovo di MongoDB, esercitati prima con questi comandi su un'istanza locale o su un database di sviluppo usa e getta. Alcuni comandi in questa guida, come dropDatabase() e drop(), rimuovono permanentemente i dati. MongoDB farà ciò che gli chiedi; non saprà che intendevi eseguire il comando da qualche altra parte.

Connettiti con mongosh

Per un'istanza MongoDB locale sulla porta predefinita, connettiti con:

mongosh

Per un server remoto, utilizza una stringa di connessione fornita dal tuo amministratore o provider di hosting:

mongosh "mongodb://[email protected]:27017/admin"

Per TLS, set di repliche o MongoDB Atlas, l'URI includerà più opzioni. Evita di incollare password nella cronologia della shell quando possibile. Utilizza prompt, gestione dei segreti specifica dell'ambiente o gli strumenti di credenziali della tua piattaforma.

Una volta connesso, controlla dove sei atterrato:

db

Questo stampa il contesto del database corrente. Molti errori iniziano supponendo che la shell sia puntata su un database quando invece è puntata su un altro.

Elenca e cambia database

Mostra i database visibili:

show dbs

Potresti non vedere tutti i database se il tuo utente non ha le autorizzazioni. Questo è normale in ambienti protetti.

Cambia il contesto del database con use:

use myAppDB

MongoDB non crea il database immediatamente quando esegui use. Lo crea quando i dati vengono scritti per la prima volta, ad esempio quando inserisci un documento o crei esplicitamente una collezione.

Controlla di nuovo il database corrente:

db

Per gli script, preferisci handle di database espliciti in modo che il codice dipenda meno dal contesto della shell:

const appdb = db.getSiblingDB("myAppDB")
appdb.getCollectionNames()

Collezioni: elenca, crea, ispeziona, rimuovi

Elenca le collezioni nel database corrente:

show collections

Oppure usa JavaScript:

db.getCollectionNames()

Crea una collezione esplicitamente quando hai bisogno di opzioni come validazione, comportamento limitato o scelte di indici/cluster supportate dalla tua versione di MongoDB:

db.createCollection("logs")

La maggior parte delle collezioni delle applicazioni vengono create automaticamente al primo inserimento, ma la creazione esplicita è più chiara per la configurazione amministrativa.

Ispeziona le statistiche della collezione:

db.orders.stats()

Vedi gli indici:

db.orders.getIndexes()

Eliminare una collezione è distruttivo:

db.logs.drop()

Prima di eseguirlo in qualsiasi ambiente condiviso, conferma il database e la collezione:

db
db.getCollectionNames()
db.logs.countDocuments({})

Per collezioni molto grandi, countDocuments({}) può essere costoso. In tal caso, usa metadati, campionamento o dashboard operative invece di eseguire conteggi ampi durante il traffico di punta.

Inserisci un documento di test e interrogalo

Anche gli amministratori hanno bisogno di alcune basi CRUD per la verifica. Inserisci un piccolo documento:

db.healthcheck.insertOne({ source: "admin-test", createdAt: new Date() })

Leggilo di nuovo:

db.healthcheck.find({ source: "admin-test" }).sort({ createdAt: -1 }).limit(5)

Rimuovi solo il documento di test:

db.healthcheck.deleteMany({ source: "admin-test" })

Usa filtri specifici. Evita eliminazioni ampie mentre impari. Un comando come deleteMany({}) rimuove ogni documento nella collezione.

Nozioni di base sull'amministrazione degli utenti

I comandi utente vengono eseguiti sul database in cui l'utente è definito. Gli utenti amministrativi sono spesso creati in admin. Gli utenti dell'applicazione possono essere creati nel database dell'applicazione, a seconda del modello di sicurezza.

Passa a admin:

use admin

Crea un utente amministrativo con una password richiesta:

db.createUser({
  user: "appAdmin",
  pwd: passwordPrompt(),
  roles: [
    { role: "userAdminAnyDatabase", db: "admin" },
    { role: "readWriteAnyDatabase", db: "admin" }
  ]
})

Per un'applicazione normale, usa autorizzazioni più ristrette. Ad esempio, un'app che legge e scrive solo myAppDB non dovrebbe ricevere ruoli amministrativi ampi:

use myAppDB

db.createUser({
  user: "myAppUser",
  pwd: passwordPrompt(),
  roles: [
    { role: "readWrite", db: "myAppDB" }
  ]
})

Elenca gli utenti nel database corrente:

show users

Aggiorna i ruoli con attenzione:

db.grantRolesToUser("myAppUser", [ { role: "read", db: "reporting" } ])

Rimuovi i ruoli altrettanto deliberatamente:

db.revokeRolesFromUser("myAppUser", [ { role: "read", db: "reporting" } ])

L'abitudine più sicura è il privilegio minimo: dare all'utente solo il database e il ruolo necessari per il lavoro.

Stato del server e operazioni correnti

serverStatus restituisce un documento di grandi dimensioni con contatori e informazioni di runtime:

db.serverStatus()

I principianti di solito non hanno bisogno dell'intero documento. Estrai le sezioni che ti interessano:

db.serverStatus().connections
db.serverStatus().mem
db.serverStatus().opcounters

Le operazioni correnti possono aiutare quando qualcosa è bloccato o lento:

db.currentOp()

Su un server occupato, filtralo:

db.currentOp({ active: true, secs_running: { $gte: 5 } })

Non uccidere le operazioni con leggerezza. Se devi terminare una, ispezionala prima e capisci se è una query utente, una creazione di indice, un backup, una migrazione o un lavoro di replica interno.

Controlli del set di repliche

Se la tua implementazione è un set di repliche, questi comandi sono comuni:

rs.status()
rs.conf()

rs.status() mostra i membri, lo stato, le informazioni sull'optime e quale nodo è primario. Eseguilo quando le applicazioni segnalano errori di scrittura, quando un nodo è stato riavviato o quando si sospetta un ritardo di replica.

Per un rapido controllo di sanità della preferenza di lettura, chiedi chi il nodo corrente pensa di essere:

db.hello()

Gli esempi più vecchi possono usare isMaster(). Le versioni più recenti di MongoDB supportano hello; potresti ancora vedere il vecchio comando in script esistenti.

I comandi pericolosi meritano rituali

Per lavori distruttivi, rallenta. Un semplice rituale previene interruzioni reali:

db
show collections
// conferma il nome host o la stringa di connessione nel prompt del terminale o nelle note
// conferma il piano di backup o ripristino se questo è produzione
db.collectionName.drop()

Per la rimozione del database:

use databaseToRemove
db.dropDatabase()

Questo comando elimina il database corrente. Il pericolo non è la sintassi; il pericolo è essere nel contesto sbagliato.

Una checklist amministrativa per principianti

Quando ti connetti a un ambiente MongoDB, abituati a questa sequenza:

db
show dbs
use myAppDB
show collections
db.orders.getIndexes()
db.serverStatus().connections
db.currentOp({ active: true })

Questi comandi ti dicono dove sei, cosa esiste, se l'accesso di base funziona e se qualcosa di ovvio sta accadendo in questo momento.

L'amministrazione di MongoDB diventa molto meno intimidatoria quando tratti mongosh prima come uno strumento di ispezione e poi come uno strumento di modifica. Guarda, conferma, poi agisci. Usa ruoli ristretti, password richieste, query filtrate e nomi di database espliciti. Questa abitudine conta più che memorizzare una lunga lista di comandi.

Leggi attentamente le dimensioni del database e delle collezioni

I principianti spesso usano show dbs come strumento di dimensionamento, ma è solo un punto di partenza. I motori di archiviazione, la compressione, gli indici e lo spazio eliminato possono rendere i numeri delle dimensioni sorprendenti. Usa le statistiche delle collezioni quando hai bisogno di maggiori dettagli:

db.orders.stats()

Guarda anche la dimensione dell'indice:

db.orders.totalIndexSize()

Gli indici non sono gratuiti. Accelerano le letture e alcuni ordinamenti, ma ogni indice aggiunge overhead di scrittura e archiviazione. Se una collezione ha molti indici e le scritture sono lente, elencali e chiedi quali query li usano effettivamente:

db.orders.getIndexes()
db.orders.find({ customerId: "c123" }).explain("executionStats")

Non eliminare gli indici con leggerezza in produzione. Un indice dall'aspetto inutilizzato potrebbe supportare un report mensile o una schermata amministrativa usata raramente. Controlla i log delle query, i proprietari dell'applicazione e il monitoraggio prima di rimuoverlo.

Consapevolezza di base del backup

L'amministrazione da riga di comando dovrebbe essere sempre collegata alle abitudini di backup. Prima della manutenzione distruttiva, sappi come viene eseguito il backup del database e come è stato testato il ripristino. In MongoDB autogestito, potresti vedere mongodump e mongorestore per backup logici:

mongodump --uri "mongodb://user@host:27017/myAppDB" --out ./backup

Per grandi sistemi di produzione, gli snapshot del filesystem, gli snapshot del provider cloud, Ops Manager o i backup di Atlas potrebbero essere più appropriati. Il punto a livello principiante è semplice: non trattare drop, deleteMany o modifiche di ruolo come reversibili a meno che tu non abbia un percorso di ripristino testato.

Un backup che non hai mai ripristinato è un'ipotesi. Esercitati a ripristinare in un ambiente non di produzione in modo da conoscere le credenziali, l'accesso alla rete e la compatibilità della versione prima di un incidente.

Controlla i log quando i comandi non sono sufficienti

mongosh mostra le risposte del server, ma non sostituisce i log. Se gli utenti segnalano query lente, errori di autenticazione o variazioni di connessione, controlla i log di MongoDB e i log della tua piattaforma. Nelle implementazioni Linux autogestite, i log potrebbero essere in /var/log/mongodb/, a seconda del pacchetto e della configurazione. Nei contenitori, usa i log del runtime del contenitore. In Atlas, usa l'interfaccia utente di Atlas e i log scaricabili.

Un errore comune dei principianti è fissare serverStatus() mentre il vero indizio è un errore di autenticazione, un problema DNS, una mancata corrispondenza TLS o l'esaurimento del pool di connessioni dell'applicazione nei log al di fuori di MongoDB.

Conosci la differenza tra ruoli del database e accesso al sistema operativo

Gli utenti di MongoDB non sono utenti Linux. Creare myAppUser in MongoDB non crea un account shell. Dare a qualcuno accesso SSH a un server di database non gli dà automaticamente autorizzazioni sul database, anche se potrebbe dargli un accesso indiretto pericoloso se il server è mal configurato.

Mantieni questi livelli separati:

Utente Linux: controlla l'accesso all'host e ai file
Utente MongoDB: controlla l'autenticazione e l'autorizzazione del database
Politica di rete: controlla chi può raggiungere la porta MongoDB
TLS: protegge il traffico e può supportare l'identità basata su certificato

Un'implementazione sicura deve considerare tutti questi aspetti. Una password MongoDB forte non è sufficiente se il database ascolta pubblicamente senza regole firewall. Una rete privata non è sufficiente se ogni applicazione utilizza un ruolo amministrativo.

Un'abitudine più sicura per le shell di produzione

Quando lavori in produzione, rendi il prompt e la connessione ovvi. Alcuni team usano colori del terminale, alias della shell o utenti di sola lettura per l'ispezione. Come minimo, esegui alcuni controlli di identità dopo la connessione:

db.runCommand({ connectionStatus: 1 })
db
db.hello()

connectionStatus mostra gli utenti e i ruoli autenticati. db mostra il contesto. hello fornisce informazioni sulla topologia. Questi tre controlli prevengono un numero sorprendente di errori.

Per l'ispezione di routine, usa un account di sola lettura. Passa a un account privilegiato solo per la finestra di modifica specifica. Questo piccolo attrito è utile. Ti costringe a notare quando stai per fare qualcosa che può modificare i dati.

Quando fermarsi e chiedere aiuto

Alcuni comandi di MongoDB sono adatti ai principianti; altri no. Fai attenzione con la riconfigurazione del set di repliche, i metadati dello sharding, le riconfigurazioni forzate, l'uccisione di operazioni, la compattazione di collezioni e la modifica delle impostazioni di autenticazione su un sistema live. Queste azioni possono influenzare la disponibilità.

Se il comando modifica la topologia del cluster o rimuove dati, fermati e chiedi una seconda revisione. I migliori amministratori non sono quelli che digitano più velocemente. Sono quelli che sanno quando un comando merita un backup, una finestra di manutenzione e un altro paio di occhi.

Comprendi read concern e write concern a livello generale

I principianti non hanno bisogno di ottimizzare read e write concern dal primo giorno, ma dovrebbero sapere che queste impostazioni esistono. Write concern controlla l'acknowledgement che MongoDB dà dopo una scrittura. Un write concern più forte può attendere la replica su più membri. Uno più debole può tornare prima ma dà meno garanzie sulla durabilità in caso di guasti.

Read concern controlla quale livello di coerenza dei dati una lettura richiede. In molte applicazioni semplici, i valori predefiniti vanno bene, ma nei set di repliche e nei sistemi distribuiti, queste impostazioni influenzano ciò che la tua applicazione può assumere in sicurezza dopo un failover o durante un ritardo di replica.

La lezione amministrativa è pratica: quando qualcuno segnala "MongoDB ha perso una scrittura" o "l'app ha letto dati obsoleti", non guardare solo al comando di inserimento. Controlla le impostazioni del driver, write concern, read preference, read concern, lo stato del set di repliche e il comportamento di ripetizione dell'applicazione.

Fai attenzione agli esempi copiati da Internet

La sintassi di MongoDB è cambiata nel tempo. I post di blog più vecchi possono usare la shell mongo legacy invece di mongosh, nomi di helper vecchi o comandi che funzionano ancora ma non sono più preferiti. Alcuni esempi vengono anche eseguiti con l'autenticazione disabilitata, il che non è un'ipotesi di produzione sicura.

Quando copi un comando, fatti tre domande:

Per quale versione di MongoDB è stato scritto?
In quale contesto di database viene eseguito?
Quali autorizzazioni deve avere l'utente connesso?

Se il comando è distruttivo, aggiungi una quarta domanda: come ripristino se questo va storto?

Usa Compass e Atlas senza abbandonare la shell

Gli strumenti grafici sono utili. MongoDB Compass può aiutare a ispezionare documenti, indici e piani di query. Atlas fornisce monitoraggio, backup, avvisi e gestione degli utenti per cluster ospitati. Questi strumenti sono spesso più facili per l'ispezione visiva rispetto all'output grezzo della shell.

Tuttavia, impara i comandi della shell. Durante gli incidenti, l'automazione, gli ambienti solo SSH o le revisioni della documentazione, un comando mongosh preciso è più facile da condividere che "clicca sulla terza scheda nell'interfaccia utente." Il miglior flusso di lavoro non è shell contro GUI. Usa la GUI per esplorare e la shell per esprimere azioni ripetibili in modo chiaro.