Comandos Esenciales de Administración de MongoDB para Principiantes

La administración de MongoDB comienza en mongosh, pero el objetivo no es memorizar cada comando. El objetivo es saber cómo explorar de forma segura, confirmar dónde estás, hacer cambios pequeños de manera deliberada y evitar comandos destructivos en la base de datos equivocada.

Si eres nuevo en MongoDB, practica estos comandos primero en una instancia local o en una base de datos de desarrollo desechable. Algunos comandos en esta guía, como dropDatabase() y drop(), eliminan datos de forma permanente. MongoDB hará lo que le pidas; no sabrá que querías ejecutar el comando en otro lugar.

Conectar con mongosh

Para una instancia local de MongoDB en el puerto predeterminado, conéctate con:

mongosh

Para un servidor remoto, usa una cadena de conexión proporcionada por tu administrador o proveedor de alojamiento:

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

Para TLS, conjuntos de réplicas o MongoDB Atlas, la URI incluirá más opciones. Evita pegar contraseñas en el historial del shell cuando sea posible. Usa indicaciones, manejo de secretos específico del entorno o las herramientas de credenciales de tu plataforma.

Una vez conectado, verifica dónde has aterrizado:

db

Eso imprime el contexto de la base de datos actual. Muchos errores comienzan asumiendo que el shell apunta a una base de datos cuando apunta a otra.

Listar y cambiar de base de datos

Muestra las bases de datos visibles:

show dbs

Puede que no veas todas las bases de datos si tu usuario carece de permisos. Eso es normal en entornos seguros.

Cambia el contexto de la base de datos con use:

use myAppDB

MongoDB no crea la base de datos inmediatamente cuando ejecutas use. La crea cuando se escriben datos por primera vez, como cuando insertas un documento o creas explícitamente una colección.

Verifica la base de datos actual nuevamente:

db

Para scripts, prefiere manejadores de base de datos explícitos para que el código dependa menos del contexto del shell:

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

Colecciones: listar, crear, inspeccionar, eliminar

Lista las colecciones en la base de datos actual:

show collections

O usa JavaScript:

db.getCollectionNames()

Crea una colección explícitamente cuando necesites opciones como validación, comportamiento limitado o elecciones de índices agrupados compatibles con tu versión de MongoDB:

db.createCollection("logs")

La mayoría de las colecciones de aplicaciones se crean automáticamente en la primera inserción, pero la creación explícita es más clara para la configuración administrativa.

Inspecciona las estadísticas de la colección:

db.orders.stats()

Ve los índices:

db.orders.getIndexes()

Eliminar una colección es destructivo:

db.logs.drop()

Antes de ejecutarlo en cualquier entorno compartido, confirma la base de datos y la colección:

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

Para colecciones muy grandes, countDocuments({}) puede ser costoso. En ese caso, usa metadatos, muestreo o paneles operativos en lugar de ejecutar conteos amplios durante horas pico.

Insertar un documento de prueba y consultarlo

Incluso los administradores necesitan algunos conceptos básicos de CRUD para verificación. Inserta un documento pequeño:

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

Léelo de vuelta:

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

Elimina solo el documento de prueba:

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

Usa filtros específicos. Evita eliminaciones amplias mientras aprendes. Un comando como deleteMany({}) elimina todos los documentos de la colección.

Conceptos básicos de administración de usuarios

Los comandos de usuario se ejecutan contra la base de datos donde está definido el usuario. Los usuarios administrativos a menudo se crean en admin. Los usuarios de aplicaciones pueden crearse en la base de datos de la aplicación, dependiendo de tu modelo de seguridad.

Cambia a admin:

use admin

Crea un usuario administrativo con una contraseña solicitada:

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

Para una aplicación normal, usa permisos más restringidos. Por ejemplo, una aplicación que solo lee y escribe en myAppDB no debería recibir roles administrativos amplios:

use myAppDB

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

Lista los usuarios en la base de datos actual:

show users

Actualiza los roles con cuidado:

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

Elimina roles con la misma deliberación:

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

El hábito más seguro es el mínimo privilegio: dale al usuario solo la base de datos y el rol necesarios para el trabajo.

Estado del servidor y operaciones actuales

serverStatus devuelve un documento grande con contadores e información de tiempo de ejecución:

db.serverStatus()

Los principiantes generalmente no necesitan todo el documento. Extrae las secciones que te interesan:

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

Las operaciones actuales pueden ayudar cuando algo está atascado o lento:

db.currentOp()

En un servidor ocupado, fíltralo:

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

No mates operaciones sin cuidado. Si necesitas terminar una, inspecciónala primero y entiende si es una consulta de usuario, construcción de índices, copia de seguridad, migración o trabajo de replicación interna.

Verificaciones del conjunto de réplicas

Si tu implementación es un conjunto de réplicas, estos comandos son comunes:

rs.status()
rs.conf()

rs.status() muestra miembros, salud, estado, información de optime y qué nodo es primario. Ejecútalo cuando las aplicaciones informen fallos de escritura, cuando un nodo se haya reiniciado o cuando se sospeche de retraso en la replicación.

Para una verificación rápida de preferencia de lectura, pregunta quién cree el nodo actual que es:

db.hello()

Los ejemplos más antiguos pueden usar isMaster(). Las versiones más nuevas de MongoDB admiten hello; aún puedes ver el comando antiguo en scripts existentes.

Los comandos peligrosos merecen rituales

Para trabajo destructivo, ve despacio. Un simple ritual previene interrupciones reales:

db
show collections
// confirma el nombre del host o la cadena de conexión en tu terminal o notas
// confirma el plan de copia de seguridad o restauración si esto es producción
db.collectionName.drop()

Para eliminación de base de datos:

use databaseToRemove
db.dropDatabase()

Ese comando elimina la base de datos actual. El peligro no es la sintaxis; el peligro es estar en el contexto equivocado.

Una lista de verificación administrativa para principiantes

Cuando te conectes a un entorno MongoDB, acostúmbrate a esta secuencia:

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

Esos comandos te dicen dónde estás, qué existe, si el acceso básico funciona y si algo obvio está sucediendo ahora mismo.

La administración de MongoDB se vuelve mucho menos intimidante cuando tratas mongosh como una herramienta de inspección primero y una herramienta de cambio después. Mira, confirma, luego actúa. Usa roles estrechos, contraseñas solicitadas, consultas filtradas y nombres de base de datos explícitos. Ese hábito importa más que memorizar una larga lista de comandos.

Lee los tamaños de base de datos y colecciones con cuidado

Los principiantes a menudo usan show dbs como herramienta de dimensionamiento, pero es solo un punto de partida. Los motores de almacenamiento, la compresión, los índices y el espacio eliminado pueden hacer que los números de tamaño sean sorprendentes. Usa estadísticas de colección cuando necesites más detalle:

db.orders.stats()

Mira también el tamaño del índice:

db.orders.totalIndexSize()

Los índices no son gratuitos. Aceleran las lecturas y algunas ordenaciones, pero cada índice añade sobrecarga de escritura y almacenamiento. Si una colección tiene muchos índices y las escrituras son lentas, enuméralos y pregunta qué consultas los usan realmente:

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

No elimines índices sin cuidado en producción. Un índice que parece no usado puede soportar un informe mensual o una pantalla administrativa raramente utilizada. Verifica los registros de consultas, los propietarios de la aplicación y la monitorización antes de eliminarlo.

Conciencia básica de copias de seguridad

La administración de línea de comandos siempre debe estar conectada a hábitos de copia de seguridad. Antes del mantenimiento destructivo, sabe cómo se respalda la base de datos y cómo se ha probado la restauración. En MongoDB autogestionado, puedes ver mongodump y mongorestore para copias de seguridad lógicas:

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

Para grandes sistemas de producción, las instantáneas del sistema de archivos, las instantáneas del proveedor de la nube, Ops Manager o las copias de seguridad de Atlas pueden ser más apropiadas. El punto a nivel de principiante es simple: no trates drop, deleteMany o cambios de roles como reversibles a menos que tengas una ruta de restauración probada.

Una copia de seguridad que nunca has restaurado es una suposición. Practica la restauración en un entorno que no sea de producción para que conozcas las credenciales, el acceso a la red y la compatibilidad de versiones antes de un incidente.

Verifica los registros cuando los comandos no son suficientes

mongosh muestra las respuestas del servidor, pero no reemplaza los registros. Si los usuarios informan consultas lentas, fallos de autenticación o cambios de conexión, verifica los registros de MongoDB y los registros de tu plataforma. En implementaciones Linux autogestionadas, los registros pueden estar en /var/log/mongodb/, dependiendo del paquete y la configuración. En contenedores, usa los registros de tiempo de ejecución del contenedor. En Atlas, usa la interfaz de usuario de Atlas y los registros descargables.

Un error común de principiante es mirar fijamente serverStatus() mientras la pista real es un fallo de autenticación, un problema de DNS, una discrepancia TLS o un agotamiento del grupo de conexiones de la aplicación en registros fuera de MongoDB.

Conoce la diferencia entre roles de base de datos y acceso al sistema operativo

Los usuarios de MongoDB no son usuarios de Linux. Crear myAppUser en MongoDB no crea una cuenta de shell. Dar a alguien acceso SSH a un servidor de base de datos no les da automáticamente permisos de base de datos, aunque puede darles acceso indirecto peligroso si el servidor está mal configurado.

Mantén esas capas separadas:

Usuario de Linux: controla el acceso al host y los archivos
Usuario de MongoDB: controla la autenticación y autorización de la base de datos
Política de red: controla quién puede alcanzar el puerto de MongoDB
TLS: protege el tráfico y puede soportar identidad basada en certificados

Una implementación segura necesita considerar todas ellas. Una contraseña fuerte de MongoDB no es suficiente si la base de datos escucha públicamente sin reglas de firewall. Una red privada no es suficiente si cada aplicación usa un rol de administrador.

Un hábito más seguro para shells de producción

Cuando trabajes en producción, haz que el indicador y la conexión sean obvios. Algunos equipos usan colores de terminal, alias de shell o usuarios de solo lectura para inspección. Como mínimo, ejecuta algunas verificaciones de identidad después de conectarte:

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

connectionStatus muestra usuarios autenticados y roles. db muestra el contexto. hello da información de topología. Esas tres verificaciones previenen un número sorprendente de errores.

Para inspección rutinaria, usa una cuenta de solo lectura. Cambia a una cuenta privilegiada solo para la ventana de cambio específica. Esa pequeña fricción es útil. Te obliga a notar cuando estás a punto de hacer algo que puede cambiar datos.

Cuándo detenerse y pedir ayuda

Algunos comandos de MongoDB son amigables para principiantes; otros no. Ten cuidado con la reconfiguración del conjunto de réplicas, metadatos de fragmentación, reconfiguraciones forzadas, matar operaciones, compactar colecciones y cambiar configuraciones de autenticación en un sistema en vivo. Esas acciones pueden afectar la disponibilidad.

Si el comando cambia la topología del clúster o elimina datos, pausa y obtén una segunda revisión. Los mejores administradores no son los que escriben más rápido. Son los que saben cuándo un comando merece una copia de seguridad, una ventana de mantenimiento y otro par de ojos.

Entender la preocupación de lectura y escritura a alto nivel

Los principiantes no necesitan ajustar la preocupación de lectura y escritura el primer día, pero deben saber que estas configuraciones existen. La preocupación de escritura controla el acuse de recibo que MongoDB da después de una escritura. Una preocupación de escritura más fuerte puede esperar la replicación a más miembros. Una más débil puede regresar antes pero da menos garantía sobre durabilidad en fallos.

La preocupación de lectura controla qué nivel de consistencia de datos pide una lectura. En muchas aplicaciones simples los valores predeterminados están bien, pero en conjuntos de réplicas y sistemas distribuidos, estas configuraciones influyen en lo que tu aplicación puede asumir de forma segura después de una conmutación por error o durante el retraso de replicación.

La lección administrativa es práctica: cuando alguien informe "MongoDB perdió una escritura" o "la aplicación leyó datos obsoletos", no mires solo el comando de inserción. Verifica la configuración del controlador, la preocupación de escritura, la preferencia de lectura, la preocupación de lectura, la salud del conjunto de réplicas y el comportamiento de reintento de la aplicación.

Ten cuidado con ejemplos copiados de internet

La sintaxis de MongoDB ha cambiado con el tiempo. Las publicaciones de blog más antiguas pueden usar el shell mongo heredado en lugar de mongosh, nombres de ayudantes antiguos o comandos que aún funcionan pero ya no son preferidos. Algunos ejemplos también se ejecutan con autenticación deshabilitada, lo que no es una suposición segura de producción.

Al copiar un comando, haz tres preguntas:

¿Para qué versión de MongoDB fue escrito esto?
¿En qué contexto de base de datos se ejecuta?
¿Qué permisos necesita el usuario conectado?

Si el comando es destructivo, añade una cuarta pregunta: ¿cómo restauro si esto sale mal?

Usa Compass y Atlas sin abandonar el shell

Las herramientas gráficas son útiles. MongoDB Compass puede ayudar a inspeccionar documentos, índices y planes de consulta. Atlas proporciona monitorización, copias de seguridad, alertas y gestión de usuarios para clústeres alojados. Esas herramientas son a menudo más fáciles para la inspección visual que la salida cruda del shell.

Aun así, aprende los comandos del shell. Durante incidentes, automatización, entornos solo SSH o revisiones de documentación, un comando preciso de mongosh es más fácil de compartir que "haz clic en la tercera pestaña de la interfaz de usuario". El mejor flujo de trabajo no es shell versus GUI. Usa la GUI para explorar y el shell para expresar acciones repetibles claramente.