1

2
APUNTES Y EJERCICIOS
MONGO DB Y ATLAS

TEMARIO
Section 1: PHILOSOPHY AND FEATURES (7%)

1.1 Identify the characteristics of MongoDB.

MongoDB tiene varias características destacadas:

1. Alta disponibilidad: MongoDB está diseñado para garantizar la alta

disponibilidad de los datos. Puede tomar servidores fuera de línea en cualquier

momento sin pérdida de servicio o datos. Esto se aplica tanto a los servidores

locales como a MongoDB Atlas, que ofrece un servicio de base de datos multi-

nube resiliente a la pérdida de un proveedor de nube completo.

2. Capacidad de actualización inteligente: MongoDB ofrece operadores de

actualización especializados que permiten realizar operaciones atómicas y

complejas en los documentos. Puedes verificar el estado de los valores en el

3
 documento, calcular nuevos valores basados en otros campos, ordenar y truncar

arrays, e incluso crear nuevos documentos en lugar de modificar los existentes.

3. Experiencia de usuario para desarrolladores: MongoDB se ha enfocado en

brindar una excelente experiencia de usuario para los desarrolladores. Ofrece

soporte para una amplia variedad de lenguajes de programación y ha agregado

características específicas para el uso y operación de MongoDB en entornos

empresariales. Con MongoDB Atlas, puedes comenzar a usar MongoDB

fácilmente en la nube y aprovechar capacidades adicionales como búsqueda de

texto completo y servicios de backend para aplicaciones móviles y web.

4. Escalabilidad y transaccionalidad: MongoDB tiene una arquitectura escalable

que distribuye el trabajo en múltiples servidores, lo que permite manejar picos de

tráfico a medida que crece tu negocio. Además, MongoDB admite transacciones

de base de datos que agrupan múltiples cambios en una base de datos y los

aplican o rechazan en bloque.

5. Modelo de documentos: MongoDB es una base de datos orientada a

documentos, lo que significa que los datos se almacenan en documentos

flexibles y anidados en formato JSON (BSON). Esto permite almacenar

información estructurada y no estructurada en el mismo documento, y mapear

fácilmente los documentos a objetos en la mayoría de los lenguajes de

programación populares.

LOS DOCUMENTOS EN MONGODB TIENEN UNA LIMITACIÓN DE TAMAÑO

MÁXIMO DE 16Mb.

1.2 Identify the differences between a MongoDB and RDBMS database.

4
MongoDB y las bases de datos RDBMS (Relational Database Management System)

tienen varias diferencias. Aquí hay algunas diferencias clave:

1. Modelo de datos: MongoDB utiliza un modelo de documentos, donde los datos

se almacenan en documentos flexibles y anidados en formato JSON (BSON).

Por otro lado, las bases de datos RDBMS utilizan un modelo de tablas con filas y

columnas.

2. Esquema: MongoDB es una base de datos sin esquema, lo que significa que no

se requiere un esquema predefinido para los documentos. Cada documento

puede tener una estructura diferente y puede contener diferentes campos. En

cambio, las bases de datos RDBMS tienen un esquema predefinido con tablas y

columnas, y los datos deben cumplir con ese esquema.

3. Escalabilidad: MongoDB está diseñado para ser escalable horizontalmente, lo

que significa que puede distribuir los datos en múltiples servidores para manejar

grandes volúmenes de datos y tráfico. Las bases de datos RDBMS suelen ser

escalables verticalmente, lo que implica aumentar la capacidad de hardware de

un solo servidor.

4. Consultas: MongoDB utiliza un lenguaje de consulta llamado MongoDB Query

Language (MQL) para realizar consultas en documentos. MQL es similar a SQL

en términos de funcionalidad, pero tiene una sintaxis diferente. Las bases de

datos RDBMS utilizan SQL (Structured Query Language) para realizar consultas

en tablas y realizar operaciones relacionales.

5
 5. Transacciones: MongoDB admite transacciones ACID (Atomicidad,

Consistencia, Aislamiento, Durabilidad) a nivel de documento, lo que permite

agrupar múltiples operaciones en una transacción y garantizar la integridad de

los datos. Algunas bases de datos RDBMS también admiten transacciones

ACID, pero la implementación puede variar.

TABLAS DE COMPARACIÓN:

6
1.3 Identify the methods to access and administer a MongoDB.

Puerto por defecto 27017.

Para conectarse usar los programas:

● mongosh (Mongo Shell)

● compass (Aplicación de Escritorio)

● Atlas (Servicio en la nube)

Los métodos para acceder y administrar una base de datos MongoDB se conocen como

"Database Methods". Estos métodos te permiten interactuar con las bases de datos,

colecciones y usuarios, así como verificar el estado de una base de datos.

7
DATABASE METHODS TABLE

NOMBRE DESCRIPCIÓN

db.auth() Authenticates a user to a database.

db.adminCommand() Runs a command against the admin database.

db.aggregate() Runs admin/diagnostic pipeline which does not

require an underlying collection.

db.commandHelp() Returns help information for a database

command.

db.createCollection() Creates a new collection or a view. Commonly

used to create a capped collection.

db.createUser() Creates a new user.

db.dropUser() Removes a single user.

db.getUser() Returns information about the specified user.

db.updateUser() Updates user data.

db.currentOp() Reports the current in-progress operations.

db.dropDatabase() Removes the current database.

db.fsyncLock() Flushes writes to disk and locks the database to

prevent write operations and assist backup
operations. Wraps fsync.

db.fsyncUnlock() Allows writes to continue on a database locked

with db.fsyncLock().

db.getCollection() Returns a collection or view object. Used to

access collections with names that are not valid in
mongosh.

db.getCollectionNames() Lists all collections and views in the current

database.

db.getProfilingStatus() Returns a document that reflects the current

profiling level and the profiling threshold.

db.getReplicationInfo() Returns a document with replication statistics.

db.hello() Returns a document that reports the state of the

replica set.

db.help() Displays descriptions of common db object

methods.

db.hostInfo() Returns a document with information about the

system MongoDB runs on. Wraps hostInfo

8
 db.killOp() Terminates a specified operation.

db.printReplicationInfo() Prints a formatted report of the replica set status

from the perspective of the primary.

db.printCollectionStats() Prints statistics from every collection. Wraps

db.collection.stats().

db.runCommand() Runs a database command.

db.serverStatus() Returns a document that provides an overview of

the state of the database process.

db.stats() Returns a document that reports on the state of

the current database.

1.4 Identify the function of sharding.

Sharding para escalabilidad horizontal (Replicaset para disponibilidad)

La función de fragmentación (sharding) en MongoDB es un método para distribuir datos a

través de múltiples máquinas. MongoDB utiliza la fragmentación para admitir

implementaciones con conjuntos de datos muy grandes y operaciones de alto rendimiento.

Cuando se utiliza la fragmentación, los datos de una colección se dividen en fragmentos y

se distribuyen en varios servidores llamados "shards". Cada shard contiene un subconjunto

de los datos fragmentados. Esto permite que MongoDB maneje grandes volúmenes de

datos y cargas de trabajo intensivas distribuyendo la carga entre los shards.

Además, MongoDB utiliza "mongos" como enrutador de consultas. El mongos actúa como

interfaz entre las aplicaciones cliente y el clúster fragmentado. Recibe las consultas de las

aplicaciones cliente y las enruta a los shards correspondientes para obtener los resultados.

Section 2: CRUD (26%)

2.1 Given a scenario with a type of structured document that needs to

be inserted into a database, identify properly and improperly formed

insert commands.

9
2.2 Given an update scenario where an entire updated document (no

update operators used) is provided, identify the output and how the

database changed state.

2.2 Given an update scenario where $set is used, identify the output and

how the database changed state.

2.3 Give a scenario about updating a document and information about

where it should be inserted if it does not exist, identify the upsert

command that should be used.

db.collection.updateOne(

<filter>,

<replacement>,

{ upsert: true }

10
2.4 Give a scenario where multiple documents need to be updated,

identify the correct update expression.

updateMany()

2.5 Give a findAndModify scenario where another operation is run

concurrently, identify the output and how the database changed state.

the findAndModify operation is atomic. This means that if the find condition matches a
document, the update is performed on that document, and concurrent queries and additional
updates on that document are not affected until the current update is complete.

the output of the findAndModify operation will be the updated document, and the
database will change state by modifying the specified fields in the matched document.

2.6 Give a scenario where a document should be deleted from the

database, identify the delete expression that should be used.

movies.deleteOne(query);

2.7 Given a scenario where a single document should be looked up by a

simple equality constraint (eg {x: 3}), identify the expression that should

be used.

db.collection.find({ x: 3 })

2.8 Identify documents matched by a query with an equality constraint

on an array field.
Querying on Array Elements in MongoDB

Review the following code, which demonstrates how to query array elements in MongoDB.

Find Documents with an Array That Contains a Specified Value

11
In the following example, "InvestmentFund" is not enclosed in square brackets, so MongoDB
returns all documents within the products array that contain the specified value.
db.accounts.find({ products: "InvestmentFund"})

Find a Document by Using the $elemMatch Operator

Use the $elemMatch operator to find all documents that contain the specified subdocument.
For example:

db.sales.find({
items: {
$elemMatch: { name: "laptop", price: { $gt: 800 }, quantity:
{ $gte: 1 } },
},
})

2.9 Identify documents matched by an expression with comparison

operators in it.

2.10 Identify documents matched by an expression with $in.

2.11 Identify documents matched by an $elemMatch expression.

2.12 Identify documents matched by an expression that has several

logical operators.

db.customer.find( {name: { $eq:“Tim”} } ): el nombre igual a Tim.

● $ne: “no igual a"

● $gt: "mayor que"

● $gte: “mayor o igual que”

● $lt: “menor que”

● $lte: “menor o igual que”

● $in: “en” seleccionar documentos donde el valor de un campo esté dentro de un

conjunto de valores especificado. Ejemplo: { field: { $in: [value1, value2, ...] } }

12
 ● $nin: "no en" seleccionar docs donde el valor de un campo no esté dentro de un

conjunto de valores especificado. Ejemplo: { field: { $nin: [value1, value2, ...] } }

● $all: Array All Array elements are included in field array value

2.13 Given a query with a sort and limit, identify the correct output.

2.14 Identify the correct projection among a set of expressions.

2.15 Identify the expressions used to count the number of documents

matching a query.

2.16 Given an aggregation expression using $match, $group, identify the

correct output.

The $match stage filters documents based on specified conditions, while the $group
stage groups documents by a specified key.

2.17 Given a scenario with a type of structured document that needs to

be inserted into a database, identify properly and improperly formed

insert commands.

Section 3: INDEXES (18%)

● El límite máximo de índices por colección es de 64 índices.

● El límite de longitud del nombre del índice es de 127 bytes.

3.1 Given a query that is performing a collection scan, identify which

index would improve the performance of this query.

13
Seguir la regla ESR (Equality, Sort, Range)

Ejemplo de sentencia equality: .find( { model: "Cordoba" } )

Ejemplo de sentencia sort:.sort( { model: 1 } )

Ejemplo de sentencia range:.find( { age: { $lt: 10 } } )

Mejor indice siguiendo ESR para:

db.cars.find(

manufacturer: 'Ford',

cost: { $gt: 15000 }

} ).sort( { model: 1 } )

sería { manufacturer: 1, model: 1, cost: 1 }

3.2 Given a query that is performing a collection scan on an equality

match on an array field, identify which index would improve the

performance of this query.

3.3 Given a query with no constraint and a sort of two fields that is

doing collection scan, identify which index would improve the

performance of this query.

Hay que tener en cuenta el orden del SORT.

Si solo hay sort en un campo no importa si está ascendente(1) o descendente(-1)

Pero si se hace sort sobre 2 campos, el índice TIENE que estar definido igual (o

EXACTAMENTE el contrario)

14
Por ejemplo, un índice { a: 1, b: -1 } puede admitir una clasificación en { a:

1, b: -1 } y { a: -1, b: 1 } pero NO en { a: - 1, b: -1 } o {a: 1, b: 1}.

3.4 Identify which index exists or the number of indexes that exist for a

collection.

db.collection.getIndexes()

3.5 Identify the explain plan outputs that signify a potential

performance issue, specifically whether an index is present or not for

the given query.

Si indica COLLSCAN es algo que se puede mejorar, ya que hace un escaneo de toda la

colección, lo que demuestra que NO está utilizando ningún índice.

Hay que intentar que en vez de COLLSCAN haya IXSCAN, que se consigue creando el

índice adecuado.

3.6 Identify the purpose of a hidden index.

Para permitir a los usuarios evaluar el impacto potencial de eliminar un índice sin

eliminarlo realmente. Al ocultar un índice los usuarios pueden evaluar el rendimiento de

sus consultas sin el índice y decidir si conservarlo o eliminarlo. Los índices ocultos no son

visibles para el planificador de consultas y no se pueden utilizar para respaldar una

consulta.

3.7 Given an error message received when creating an index, identify

the multi-key index limitation caused this.

"ok" : 0,

"errmsg" : "Index build failed: exception: cannot index

15
 parallel arrays [exams] [homeworks]",

"code" : 16755,

"codeName" : "Location16755"

the error message indicates that the index build failed because the index includes multiple array
fields (exams and homeworks), which violates the multikey index limitation.

3.8 Identify how to validate if a query is using an index and the name of

the index being used.

Usar el método explain().

Por ejemplo:

db.collection.find({ <consulta> }).explain()

En el resultado, busque el campo winningPlan. Este da información sobre el plan de

consulta elegido por MongoDB. Dentro, busque el campo inputStage. Este campo

proporciona información sobre la etapa del plan de consulta.

Si el campo inputStage contiene una etapa IXSCAN, significa que se está utilizando un

índice para la consulta. La etapa IXSCAN representa una operación de escaneo de índice.

Para obtener el nombre del índice que se utiliza para la consulta, busque el campo

indexName dentro del campo inputStage.

3.9 Given a query, identify the field that should be indexed first.

Section 4: SERVER ADMINISTRATION (10%)

4.1 Identify the steps to start mongod.

Comando para iniciar mongod con la configuración predeterminada: mongod

16
De forma predeterminada, mongod escucha las conexiones en el puerto 27017 y almacena

datos en el directorio /data/db.

/var/log/mongodb/mongod.log - Ubicación de Logs de Mongo en Linux.

/etc/mongod.conf - Ubicación de archivos .conf de Mongo en Linux.

Para especificar un directorio, utilizar la opción --dbpath. Por ejemplo:

mongod --dbpath /srv/mongodb/

Para especificar un puerto TCP diferente, usar la opción --port. Por ejemplo:

mongod --port 12345

En sistemas Unix/Linux:

systemctl start mongod

Ambos métodos son correctos

En Windows:

mkdir -p /path/to/data/db

mongod --dbpath /path/to/data/db

4.2 Identify how to determine if mongod is running.

En sistemas Unix/Linux:

ps aux | grep mongod (Buscar el proceso)

systemctl status mongod (comandos de administración de servicios )

17
En sistemas Windows:

⦁ Busca un proceso llamado mongod.exe en el Administrador de Tareas.

⦁ Puedes abrir la consola de servicios (services.msc) y buscar el servicio llamado "MongoDB"

para ver si está en ejecución.

Usando el Cliente MongoDB:

> db.runCommand({ serverStatus: 1 })

4.3 Identify how to stop mongod.

En sistemas Unix/Linux:

⦁ Usando el comando pkill o kill:

pkill mongod

kill PID_del_proceso_mongod

⦁ Usando el comando systemctl:

systemctl stop mongod

En sistemas Windows:

⦁ Abre el Administrador de Tareas, ve a la pestaña "Detalles" o "Procesos", encuentra el

proceso mongod.exe, haz clic derecho y selecciona "Finalizar tarea".

Usando el Cliente MongoDB:

> db.adminCommand({ shutdown: 1 })

4.4 Identify how to add parameters to mongod.

Usando la línea de comandos:

mongod --dbpath /ruta/al/directorio/de/datos --port 27017

18
Usando un archivo de configuración:

# Ejemplo de mongod.cfg

systemLog:

destination: file

path: "/ruta/al/archivo/de/log/mongod.log"

logAppend: true

storage:

dbPath: "/ruta/al/directorio/de/datos"

net:

bindIp: 127.0.0.1

port: 27017

⦁ Ejecuta mongod con el archivo de configuración:

mongod -f /ruta/al/mongod.cfg

4.5 Identify how to check a parameter value in mongod.

Usando el Cliente de MongoDB:

> db.runCommand({ getCmdLineOpts: 1 })

Usando el Comando mongod:

19
 mongod --version

Consultando el Archivo de Log:

cat /ruta/al/archivo/de/log/mongod.log

4.6 Identify how to use the mongosh.

Instalación:

Puedes descargarlo desde el sitio web oficial de MongoDB o instalarlo a través de

un gestor de paquetes como npm (Node Package Manager).

npm install -g mongodb

Conexión a la Base de Datos:

Abre una terminal y ejecuta mongosh. Luego, conecta a tu servidor MongoDB

especificando la URL de conexión o el nombre del host y el puerto.

mongosh "mongodb://localhost:27017/tu_base_de_datos"

4.7 Identify how to add and remove nodes in a replica set.

4.7.1 Agregar un Nodo a un Conjunto de Réplicas:

1- Inicia una nueva instancia de mongod:

mongod --replSet nombre_del_conjunto_de_replicas --port

27017 -- dbpath /ruta/al/directorio/de/datos

2- Conéctate a un nodo existente:

mongo --host nodo_existente:27017

3- Inicia el conjunto de réplicas:

rs.add("nuevo_nodo:27017")

4- Verifica el estado:

20
 rs.status()

4.7.2 Eliminar un Nodo de un Conjunto de Réplicas:

1- Conéctate al nodo primario:

mongo --host nodo_primario:27017

2- Inicia el proceso de eliminación:

rs.remove("nodo_a_eliminar:27017")

3- Verifica el estado:

rs.status()

Section 5: MONITORING (9%)

5.1 Identify the meaning of common alerts.

1. Replica Set Member State Change: Indica que el estado de un miembro del

conjunto de réplicas ha cambiado. Puede ser causado por una variedad de razones,

como problemas de conectividad o fallos en el nodo.

2. High Replica Set Member Oplog Window: Se refiere a que el tiempo disponible

para la replicación (oplog window) es bajo. Puede indicar que la replicación no

puede mantenerse al día con la velocidad de escritura, lo que puede llevar a un

estado de "votación" o pérdida de datos.

3. Low Free Storage Space: Indica que el espacio libre en el disco está llegando a

niveles bajos. Esto puede llevar a problemas de rendimiento y, eventualmente, a la

imposibilidad de realizar operaciones de escritura.

4. Connection Pool Queued Connection: Muestra que las conexiones a la base de

datos están en cola, lo que podría indicar que el servidor está experimentando una

carga elevada o que hay un problema de rendimiento.

21
 5. Page Faults: Indica que el sistema operativo está teniendo dificultades para

manejar el conjunto de datos en memoria y se están produciendo "page faults". Esto

puede afectar negativamente al rendimiento.

6. Excessive Locking: Se refiere a que hay bloqueos prolongados en la base de datos.

Los bloqueos excesivos pueden afectar el rendimiento y deben investigarse para

identificar la causa.

7. CPU Usage: Alerta sobre el alto uso de la CPU, lo que podría indicar una carga

significativa en el servidor. Esto puede afectar negativamente el rendimiento y debe

investigarse.

8. Slow Queries: Muestra que hay consultas que están tardando más de lo esperado

en ejecutarse. Esto podría deberse a índices faltantes o problemas de diseño de

consultas.

9. Network Throughput: Indica problemas con el rendimiento de la red. Puede ser

causado por una conexión lenta o problemas de red.

10. Storage Engine Metrics: Alerta sobre métricas específicas del motor de

almacenamiento (por ejemplo, WiredTirger) que pueden indicar problemas con la

gestión de la memoria o el almacenamiento.

5.2 Identify how to run currentOp.

Conéctate al Servidor:

mongo --host tu_servidor:puerto

Ejecuta currentOp:

db.currentOp()

Filtrar Resultados con currentOp:

db.currentOp({

ns: "nombre_de_tu_base_de_datos.nombre_de_tu_coleccion"

})

22
5.3 Identify how to see currently active operations.

Conéctate al Servidor MongoDB:

mongo --host tu_servidor:puerto

Ejecuta el Comando currentOp:

db.currentOp()

Revisa el documento que devuelve el comando:

"inprog" : [

"opid" : 1,

"active" : true,

"secs_running" : 86400,

"op" : "query",

"ns" : "mi_base_de_datos.mi_coleccion",

"query" : { "campo": "valor" },

"numYields" : 0,

"locks" : {},

"waitingForLock" : false,

"lockStats" : {

"Global" : {

"acquireCount" : {

"r" : NumberLong(1)

23
 },

"Database" : {

"acquireCount" : {

"r" : NumberLong(1)

},

"Collection" : {

"acquireCount" : {

"r" : NumberLong(1)

Analiza los Resultados:

1. inprog: Este es el campo principal que contiene la lista de operaciones en curso.

2. opid: Identificador de operación (Operation ID). Un número único que identifica

de manera única cada operación en curso.

3. active: Indica si la operación está actualmente activa (true) o si ya ha finalizado

(false).

4. secs_running: La cantidad de segundos que la operación ha estado en ejecución.

24
 5. op: Tipo de operación. Puede ser "query", "update", "insert", "remove", entre

otros.

6. ns: Nombre del espacio de nombres. Indica la base de datos y la colección

afectada por la operación.

7. query: La consulta que está siendo ejecutada como parte de la operación.

8. numYields: Número de veces que la operación ha liberado el hilo de ejecución

para permitir que otros hilos accedan.

9. locks: Información sobre bloqueos asociados con la operación. Puede incluir

detalles sobre los bloqueos globales, de base de datos y de colección.

10. waitingForLock: Indica si la operación está esperando un bloqueo.

11. lockStats: Estadísticas detalladas sobre los bloqueos adquiridos durante la

operación.

5.4 Identify how to monitor storage.

Obtener estadísticas de espacio para todas las bases de datos

db.adminCommand({ dbStats: 1, scale: 1024 * 1024 * 1024 })

Obtener estadísticas de espacio para una base de datos específica

db.getSiblingDB('nombre_de_tu_base_de_datos').stats({ scale: 1024

* 1024 * 1024 })

Utilización de Sistema de Archivos:

df -h

5.5 Identify the indications that storage is running out.

25
Obtener Estadísticas de Espacio de una Base de Datos:

db.stats()

db.getSiblingDB('nombre_de_tu_base_de_datos').stats()

Verificar el Tamaño de una Colección:

db.nombre_de_tu_coleccion.stats()

Consultar el Espacio Libre en el Sistema de Archivos:

system("df -h")

Configurar Alertas de Espacio:

function verificarEspacio() {

var stats = db.stats();

var espacioLibreGB = stats.storageSize / (1024 * 1024 * 1024);

if (espacioLibreGB < 5) {

print("¡Alerta! El espacio libre es bajo. Actualmente queda:

" + espacioLibreGB.toFixed(2) + " GB");

// Ejecutar la función cada 10 minutos

setInterval(verificarEspacio, 600000);

5.6 Given a graphic showing connections to a database, identify the

number of connections.

1. Eje Y (Vertical): Examina la escala en el eje y del gráfico. Cada marca en el eje y

representa un valor específico. La unidad de medida dependerá del sistema que

estés utilizando (por ejemplo, conexiones concurrentes).

26
 2. Puntos en el Gráfico: Observa los puntos individuales en el gráfico. Cada punto

representa el número de conexiones en un momento específico del tiempo. Puedes

identificar el valor exacto en el eje y correspondiente a cada punto.

3. Líneas o Barras: Dependiendo del tipo de gráfico (línea, barra, área, etc.), el

número de conexiones puede representarse de diferentes maneras. En un gráfico

de líneas, cada punto está conectado por líneas, mientras que en un gráfico de

barras, cada barra representa el valor en un momento específico.

4. Herramientas de Visualización: Algunas herramientas de visualización de datos

permiten interactividad, lo que te permite pasar el ratón sobre un punto específico

para ver el valor exacto. Utiliza esta función si está disponible.

5. Leyenda: Si hay múltiples líneas en el gráfico, es posible que haya una leyenda

que indique a qué se refiere cada línea. La leyenda generalmente se encuentra en la

parte superior o lateral del gráfico y proporciona información sobre las series de

datos representadas.

6. Tiempo en el Eje X: Observa el eje x para determinar el momento específico del

tiempo al que corresponde cada punto en el gráfico. Dependiendo de la escala de

tiempo, podrías ver datos por hora, día, semana, etc

Section 6: SECURITY (15%)

Habilitar control de acceso

MongoDB emplea control de acceso basado en roles (RBAC) para controlar el acceso a
un sistema MongoDB. A un usuario se le concede uno o más roles que determinan el
acceso del usuario a los recursos y operaciones de la base de datos. Fuera de las
asignaciones de roles, el usuario no tiene acceso al sistema.

27
Habilitar el control de acceso en una implementación de MongoDB exige la autenticación.

Con el control de acceso habilitado, los usuarios deben identificarse y solo pueden realizar

acciones que cumplan con los permisos otorgados por los roles asignados a su usuario.

Autenticación (Authentication):

La autenticación es el proceso de verificar la identidad de un cliente. Cuando el

control de acceso ( autorización ) está habilitado, MongoDB requiere que todos los

clientes se autentiquen para determinar su acceso.

Mecanismos de autenticación:

- SCRAM es el mecanismo de autenticación predeterminado para MongoDB.

- Autenticación de certificado x.509 MongoDB admite la autenticación de

certificados x.509 para la autenticación de clientes y la autenticación interna de los

miembros de conjuntos de réplicas y clústeres fragmentados. La autenticación del

certificado x.509 requiere una conexión TLS/SSL segura. Para utilizar MongoDB con x.509,

debe utilizar certificados válidos generados y firmados por una autoridad certificadora. Los

certificados de cliente x.509 deben cumplir los requisitos del certificado de cliente.

- Autenticación Kerberos Este método está soportado por la versión MongoDb

Enterprise. Es un protocolo de autenticación estándar de la industria que se utiliza en grandes

sistemas cliente/servidor. Kerberos permite que MongoDB y las aplicaciones aprovechen la

infraestructura y los procesos de autenticación existentes. Con la autenticación Kerberos, los

clientes de MongoDB pueden autenticarse en instancias mongod y mongos.

- Autenticación de proxy LDAP

La autenticación de proxy LDAP en MongoDB es una característica compatible con MongoDB

Enterprise. Permite a MongoDB enviar solicitudes de autenticación a un servicio de Protocolo

ligero de acceso a directorios (LDAP, Lightweight Directory Access Protocol). Esto significa que

MongoDB puede utilizar un servidor LDAP para la autenticación.

28
Hay dos métodos de autenticación de proxy LDAP admitidos por MongoDB:

- Autenticación LDAP a través de bibliotecas del sistema operativo

- Autenticación LDAP a través de saslauthd: los servidores MongoDB en Linux también

pueden vincularse a un servidor LDAP utilizando el demonio saslauthd

ENCRIPTACIÓN (ENCRYPTION)

Encryption at Rest: Protege los datos almacenados en reposo.

El cifrado a nivel de disco en MongoDB se refiere al cifrado de datos en reposo en el disco.

Esta característica permite a MongoDB cifrar los archivos de datos almacenados en el

servidor de la base de datos, asegurando que solo las partes con la clave de descifrado

puedan decodificar y leer los datos. El cifrado a nivel de disco proporciona una capa

adicional de seguridad para proteger los datos confidenciales incluso si el medio de

almacenamiento físico está comprometido.

Transport Encryption (Network Encryption): Protege los datos durante su transmisión a

través de la red.

MongoDB admite TLS/SSL (Seguridad de la capa de transporte/Capa de sockets

seguros) para cifrar todo el tráfico de red de MongoDB. TLS/SSL garantiza que el tráfico de

red MongoDB solo sea legible por el cliente previsto.

In-Use Encryption: Protege los datos mientras están siendo procesados por una aplicación

o proceso en memoria.

El cifrado de nivel de campo del lado del cliente (CSFLE, Client Side Field Level) es una

característica que le permite cifrar datos en su aplicación antes de enviarlos a través de la

red a MongoDB. Con CSFLE habilitado, ningún producto MongoDB tiene acceso a sus datos

sin cifrar.

6.1 Identify the purpose of enabling TLS.

29
Transport Layer Security (TLS): Encripta los datos para que no sean accesibles durante el

transporte verificando que el destinatario y el lector son la misma persona con una clave

pública y otra privada. En Atlas está habilitado por defecto y no se puede inhabilitar pero

en local hay que configurarlo.

6.1.1 Habilitar TLS (Transport Layer Security)

1- Generar Certificados: Genera certificados TLS para el servidor y, opcionalmente,

para los clientes. Puedes usar herramientas como OpenSSL para este

propósito.

2- Configurar MongoDB para Usar TLS: Modifica la configuración de MongoDB

para habilitar TLS. Esto implica especificar los certificados, claves privadas y

configuraciones de cifrado en el archivo de configuración de MongoDB

(mongod.conf).

# Ejemplo de sección en mongod.conf

net:

port: 27017

bindIp: 0.0.0.0

tls:

mode: requireTLS

certificateKeyFile: /ruta/al/clave-privada.pem

certificateFile: /ruta/al/certificado.pem

CAFile: /ruta/al/CA.pem

'mode: requireTLS': Esta opción indica que las conexiones deben usar TLS.

30
 3- Reiniciar MongoDB: Reinicia el servidor de MongoDB para aplicar los cambios en

la configuración.

4- Configurar Clientes para Usar TLS: Configura los clientes de MongoDB para que

utilicen TLS. Esto puede implicar especificar certificados y claves privadas en el

archivo de configuración del cliente o proporcionarlos como parámetros de

conexión.

Se configura en el fichero de configuración en el apartado net:{} y no en security

Para conectarse con tls¿? :

6.1.2 Propósito de habilitar TLS

El propósito de habilitar TLS en MongoDB es proporcionar una capa adicional de

seguridad mediante la encriptación de las comunicaciones entre los clientes y el

servidor de base de datos.

Es una práctica recomendada para garantizar la seguridad de las transmisiones de

datos sensibles y proteger la integridad y la autenticidad de las comunicaciones en

un entorno de base de datos.

6.2 Identify the purpose of enabling authentication.

La autenticación es el proceso de verificar la identidad de un usuario que intenta

acceder a una base de datos. Requerir que un usuario ingrese un nombre de

31
 usuario y contraseña válidos es un mecanismo de autenticación comúnmente

utilizado.

Añadir al archivo '/etc/mongod.conf':

...

security:

authorization: enabled

...

6.3 Identify how to define a role for authorization.

La autorización determina los permisos específicos que tiene un usuario en la base de

datos. Permite asignar roles:

Sintaxis:

db.createUser({

user: <username> ,

pwd: <password> ,

roles: [<roles_subdocuments>...]

})

Ejemplo:

db.createUser(

user: "globalUserAdmin",

pwd: passwordPrompt(),

32
 roles: [

{ role: "userAdminAnyDatabase", db: "admin" },

{ role: "readWrite", db: "sample_supplies" }

Otros métodos:

db.getUser()

33
6.4 Identify how to assign a role to a user for authorization.

Asignar roles definidos en la base de datos actual:

db.grantRolesToUser(

"sally",

34
 "read",

"backup"

Asignar roles asociados a otras bases de datos:

db.grantRolesToUser(

"sally",

{ role: "read", db: "sales"},

{ role: "readWrite", db: "callLogs"}

6.5 Identify how to revoke a role from a user for authorization.

Eliminar roles definidos en la base de datos actual:

db.revokeRolesFromUser(

"sally",

"read",

"backup"

Eliminar roles asociados a otras bases de datos:

db.revokeRolesFromUser(

35
 "financeUser",

{ role: "read", db: "sample_training" }

6.6 Identify how to add a privilege to a role for authorization.

db.grantPrivilegesToRole(

"miRol",
[
{

resource: { db: "miBaseDeDatos", collection: "" },

actions: ["find", "insert", "update", "remove"]

}
]
)

6.7 Identify the purpose of encryption at rest.

Encryption at rest: Es el proceso de encriptar los datos almacenados junto con las copias

de seguridad con el fin de protegerlos de ataques físicos. El cifrado en reposo protege los

datos almacenados cifrando los archivos de datos en el servidor de la base de datos, junto

con las copias de seguridad de los datos.

6.8 Identify the limitations of encryption at rest.

● Key management (gestión de claves): Si la clave utilizada para cifrar los datos en

reposo se pierde o es robada, los datos podrían verse comprometidos o quedar

36
 inaccesibles. Cualquiera que tenga la clave de cifrado tendrá acceso a los datos del

servidor.

● Insider threats (amenazas internas): Los usuarios confiables con autorización

pueden usar sus privilegios para descifrar datos protegidos mediante cifrado en

reposo. Por lo tanto, estos usuarios de confianza pueden exponer o alterar los

datos.

● Attacks on data in memory (ataques a los datos en memoria): Con el cifrado en

reposo, los datos se descifran para su uso. Una vez que los datos están en uso, por

ejemplo cuando el servidor de la base de datos los procesa, son vulnerables a los

ataques.

6.9 Identify the purpose of field-level encryption.

Field-level encryption in MongoDB serves the purpose of providing an additional layer of

security to protect sensitive data. It allows you to encrypt specific data fields within
documents before transmitting the data to the server.

The purpose of field-level encryption is to ensure that unauthorized parties, including server
administrators, cannot read the encrypted data.

CS-FLE- (Client-Side Field Level Encryption) : Encripta los datos antes de enviarlos al

servidor por lo que se almacenan ya encriptados. Se puede aplicar sobre un campo en

concreto del documento, de este modo el servidor no dispone de llaves para desencriptar.

De esta manera solo se pueden desencriptar en el lado del cliente.

Client-Side Field Level Encryption (CSFLE) provides an additional layer of security to protect

sensitive data, such as personal identifying information, financial information, or health

information. CSFLE keeps data encrypted on the server both once it’s loaded into memory, as

well as when it’s at rest on disk.

6.10 Identify where the audit log can be written.

37
La salida del log puede ser en JSON o BSON. Y el destino del flujo: SYSLOG, FILE o

CONSOLE

fichero de configuración donde se encuentra entre otros, el fichero mongod.conf

/var/log/mongodb/mongod.log - Ubicación de Logs de Mongo en Linux.

/etc/mongod.conf - Ubicación de archivos .conf de Mongo en Linux.

1. Syslog: You can enable auditing and print audit events to the syslog in JSON format.
This option is available on Linux and macOS, but not on Windows. To enable this,

specify syslog for the --auditDestination setting when starting the mongod

instance.

2. Console: You can enable auditing and print audit events to the console (stdout) in JSON
format. This option is available on all platforms. To enable this, specify console for the

--auditDestination setting when starting the mongod instance.

3. File: You can enable auditing and write audit events to a file in either JSON or BSON
format. This option is available on all platforms. To enable this, specify the path to the

audit log file using the auditLog.path setting in the mongod configuration file.

Section 7: REPLICATION (14%)

TABLA DE LOS MÉTODOS DE REPLICATION

NOMBRE DESCRIPCIÓN

rs.add() Adds a member to a replica set.

rs.addArb() Adds an arbiter to a replica set.

rs.conf() Returns the replica set configuration document.

rs.freeze() Prevents the current member from seeking

election as primary for a period of time.

rs.help() Returns basic help text for replica set functions.

38
 rs.initiate() Initializes a new replica set.

rs.printReplicationInfo() Prints a formatted report of the replica set status

from the perspective of the primary.

rs.printSecondaryReplicationInfo() Prints a formatted report of the replica set status

from the perspective of the secondaries.

rs.printSlaveReplicationInfo() Deprecated since version 4.4.1: Use

ESTE ESTÁ DEPRECATED!!!! rs.printSecondaryReplicationInfo()
instead.

rs.reconfig() Reconfigures a replica set by applying a new

replica set configuration object.

rs.reconfigForPSASet() Safely perform some reconfiguration changes on a

primary-secondary-arbiter (PSA) replica set or on
a replica set that is changing to a PSA
architecture.

rs.remove() Remove a member from a replica set.

rs.status() Returns a document with information about the

state of the replica set.

rs.stepDown() Causes the current primary to become a

secondary which forces an election.

rs.syncFrom() Sets the member that this replica set member will
sync from, overriding the default sync target
selection logic.

7.1 Identify the purpose of replication.

Los propósitos de la replicación son:

● Proporcionar redundancia y alta disponibilidad de los datos.

● Tolerancia a fallos en caso de pérdida de un servidor.

● Aumentar la capacidad de lectura al permitir que las operaciones de lectura se

envíen a diferentes servidores.

● Mantener copias adicionales de los datos para fines específicos, como recuperación

ante desastres, informes o copias de seguridad. Al mantener múltiples copias de los

datos en diferentes servidores de base de datos, la replicación ofrece tolerancia a

fallos en caso de pérdida de un servidor.

39
7.2 Identify the purpose of the primary.

El propósito del primario es recibir todas las operaciones de escritura. El nodo

primario es el único miembro del conjunto de réplicas que acepta operaciones de escritura.

Luego, registra estas operaciones en el oplog (registro de operaciones) del nodo primario.

Los miembros secundarios replican este oplog y aplican las operaciones a sus conjuntos de

datos.

Todos los miembros del conjunto de réplicas pueden aceptar operaciones de lectura. Sin

embargo, de forma predeterminada, una aplicación dirige sus operaciones de lectura al

miembro primario. Puedes cambiar este comportamiento predeterminado utilizando las

preferencias de lectura.

¡Importante! Un conjunto de réplicas puede tener como máximo un nodo primario. Si el

nodo primario actual no está disponible, se lleva a cabo una elección para determinar el

nuevo nodo primario.

7.3 Identify the purpose of the secondary.

Algunos de los propósitos del secundario son:

● Mantener una copia del conjunto de datos del primario: Un secundario replica

los cambios realizados en los datos del primario aplicando las operaciones del oplog

del primario a su propio conjunto de datos. Esto garantiza que el secundario tenga

una copia actualizada de los datos del primario.

● Proporcionar redundancia y alta disponibilidad: Si el primario se vuelve

inaccesible, el conjunto de réplicas realiza una elección para seleccionar uno de los

secundarios como el nuevo primario. Esto garantiza que la base de datos siga

estando disponible incluso si el primario falla.

● Permitir la lectura de datos: Aunque los clientes no pueden escribir datos en los

secundarios, sí pueden leer datos de los secundarios. Esto permite distribuir la

carga de lectura entre los secundarios y mejorar la capacidad de lectura del sistema.

40
 ● Configurar secundarios para propósitos específicos: Puedes configurar un

secundario para cumplir con requisitos específicos. Por ejemplo, para que no

participe en las elecciones y se utilice como un servidor de respaldo en frío. También

puedes configurar un secundario para que no sea visible para las aplicaciones y se

utilice para ejecutar aplicaciones que requieren separación del tráfico normal.

Además, puedes configurar un secundario para mantener un "snapshot" histórico

para recuperación de errores.

7.4 Identify uses for read preference.

La preferencia de lectura (read preference) en MongoDB se utiliza para dirigir las

operaciones de lectura a los miembros de un conjunto de réplicas. Aquí hay algunos

usos comunes para la preferencia de lectura:

● Distribución de carga de lectura: Puedes configurar la preferencia de lectura para

enviar las operaciones de lectura a los secundarios en lugar del primario. Esto

permite distribuir la carga de lectura entre los secundarios y mejorar la capacidad

de lectura del sistema.

● Reducción de la latencia de lectura: Si tienes secundarios en diferentes

ubicaciones geográficas, puedes configurar la preferencia de lectura para enviar las

operaciones de lectura al secundario más cercano a los clientes. Esto reduce la

latencia de lectura y mejora el rendimiento de las aplicaciones distribuidas.

● Lecturas consistentes: Si necesitas leer datos que reflejen las operaciones de

escritura más recientes, puedes configurar la preferencia de lectura para leer desde

el primario. Esto garantiza que las operaciones de lectura reflejen los cambios más

recientes en los datos.

1. readPreference: "primary": Dirige todas las operaciones de lectura al nodo

primario. Es la opción predeterminada si no se especifica ninguna preferencia

2. readPreference: "primaryPreferred": Dirige las operaciones de lectura al nodo

primario, pero si este no está disponible, las dirigirá a un secundario.

41
 3. readPreference: "secondary": Dirige las operaciones de lectura exclusivamente

a nodos secundarios. No se dirigen a nodos primarios.

4. readPreference: "secondaryPreferred": Dirige las operaciones de lectura a un

secundario si está disponible, pero si no lo está, las dirigirá al primario.

5. readPreference: "nearest": Dirige las operaciones de lectura al nodo más

cercano en términos de latencia de red. Puede ser un primario o un secundario.

Ejemplo de cómo se especifica una preferencia de lectura en MongoDB:

Mongoshell:

db.collection.find().readPref("primary");

Console:

mongodb://db0.example.com,db1.example.com,db2.example.com/?

replicaSet=myRepl&readPreference=secondary&maxStalenessSeconds=

120

7.5 Identify the information that can be found in the output of rs.status.

La salida de rs.status() en MongoDB proporciona información sobre el estado actual

del conjunto de réplicas desde la perspectiva del miembro donde se ejecuta el método.

Algunos datos que se pueden encontrar en la salida de rs.status():

● set: El nombre del conjunto de réplicas.

● date: La fecha y hora en que se generó la salida.

● myState: El estado del miembro actual en el conjunto de réplicas.

● term: El término actual del conjunto de réplicas.

● ok: Un indicador de si la operación se completó correctamente.

● syncSourceHost: El host del miembro del que se está sincronizando el

miembro actual.

42
 ● syncSourceId: El ID del miembro del que se está sincronizando el miembro

actual.

● heartbeatIntervalMillis: El intervalo de tiempo entre los latidos del

conjunto de réplicas.

● majorityVoteCount: El número de votos necesarios para alcanzar la mayoría

en el conjunto de réplicas.

● writeMajorityCount: El número de votos necesarios para realizar una

escritura mayoritaria en el conjunto de réplicas.

● votingMembersCount: El número total de miembros con derecho a voto en el

conjunto de réplicas (disponible a partir de la versión 4.4).

● writableVotingMembersCount: El número total de miembros con derecho a

voto y capacidad de escritura en el conjunto de réplicas (disponible a partir de la

versión 4.4).

● optimes: Información sobre las operaciones de tiempo en el conjunto de

réplicas, como la última operación confirmada, el tiempo de lectura de la mayoría

y el tiempo de aplicación de la operación.

● members: Es un array que contiene información detallada sobre cada miembro

del conjunto de réplicas. Cada miembro es representado como un documento

con propiedades como:

1. name: Nombre del nodo.

2. health: Indica si el nodo está saludable o no.

3. state: Indica el estado del nodo (primario, secundario, etc.).

4. stateStr: Estado del nodo como una cadena legible.

5. uptime: Tiempo que ha estado funcionando el nodo.

6. optime: Marca de tiempo de la última operación replicada por el nodo.

7. optimeDate: Fecha de la última operación replicada.

43
 8. Otras propiedades que proporcionan detalles sobre la replicación y la

conexión.

7.6 Identify the purpose of setting write concern.

Establecer inquietudes de escritura (write concern) te permite controlar el nivel de

confirmación que se solicita a MongoDB para las operaciones de escritura. Esto afecta

la rapidez con la que se devuelve la operación de escritura.

● Con una inquietud de escritura débil, las operaciones de escritura se devuelven

rápidamente.

● Con inquietudes de escritura más fuertes, los clientes deben esperar hasta que

MongoDB confirme la operación de escritura en el nivel de inquietud de escritura

solicitado.

● Con inquietudes de escritura insuficientes, las operaciones de escritura pueden

parecer haber tenido éxito para un cliente, pero es posible que no se persistan en

algunos casos de falla del servidor.

Las operaciones que no especifican una inquietud de escritura explícita heredan la

configuración de la inquietud de escritura predeterminada global.

⦁ Tipos de write concern:

1. Majority: La mayoría de los miembros de un conjunto de réplicas deben persistir

los datos antes que se reconozca la operación de escritura.

2. <number>: Representa el número de miembros necesarios que tienen la

necesidad de reconocer la operación de escritura.

⦁ Configuración del write concern:

db.adminCommand({

setDefaultRWConcern : 1,

44
 defaultReadConcern: { level : "majority" },

defaultWriteConcern: { w: "majority" }

})

7.7 Identify the purpose of an election.

En una replicación de MongoDB, una elección

tiene el propósito de seleccionar un nuevo

nodo primario en caso de que el nodo

primario actual se vuelva inaccesible. Durante

una elección, los nodos secundarios envían votos

para elegir al nuevo nodo primario. El nodo que

recibe la mayoría de los votos se convierte en el

nuevo nodo primario.

Propósito principal: Garantizar la continuidad del servicio y la disponibilidad de los datos

en caso de una falla del nodo primario. Una vez elegido un nuevo nodo primario, los nodos

secundarios comienzan a replicar los cambios realizados por el nuevo nodo primario.

En un conjunto de replicas podemos tener un máximo de 7 miembros. Se recomienda que

sea un número impar (3,5 o 7) para que las votaciones sean más eficientes.

Se inicia una elección si los miembros secundarios pierden la conectividad con el principal

durante más tiempo que el tiempo de espera configurado, que es de 10 segundos de

forma predeterminada.

7.8 Given a replica set and the primary fails, identify what will occur.

1. Detección de la Falla (Failover): El conjunto de réplicas utiliza mecanismos internos

para detectar la falla del nodo principal. Esto puede incluir el uso de heartbeat entre nodos

para verificar su estado y la elección del primario.

45
2. Elección de un Nuevo Primario: Cuando se detecta la falla del nodo principal, los nodos

restantes en el conjunto de réplicas realizan una elección de primario. Cada nodo vota por

sí mismo y por otros nodos que considera elegibles. El nodo que recibe la mayoría de los

votos se convierte en el nuevo primario.

3. Reconfiguración del Conjunto de Réplicas: Una vez que se ha elegido un nuevo

primario, se realiza una reconfiguración del conjunto de réplicas para reflejar este cambio.

Todos los demás nodos en el conjunto actualizan su configuración para reconocer al nuevo

primario.

4. Inicio de Operaciones de Escritura y Lectura: Con el nuevo primario establecido y la

reconfiguración completa, el conjunto de réplicas vuelve a estar disponible para

operaciones de escritura y lectura. Los clientes pueden dirigirse al nuevo primario para

realizar operaciones.

5. Regreso del nodo que tuvo la falla: Una vez que el nodo que falló (el primario original)

se restaura, vuelva a entrar al conjunto de réplicas como nodo secundario. Una vez que se

actualiza propone una votación en la que sí tiene mayor "priority" volverá a ser elegido

como primario.

7.9 Identify the purpose of oplog.

El oplog es una 'capped collection' (Con un comportamiento similar a un 'ring buffer') que

desempeña un papel fundamental en la sincronización y la consistencia de los datos entre

los nodos del conjunto de réplicas. Su propósito principal es registrar todas las operaciones

de escritura que ocurren en el nodo primario (primario) para que los nodos secundarios

(secundarios) puedan replicar esas operaciones y mantenerse actualizados.

Failover y Elección de Primario: En caso de una falla en el nodo primario, el oplog es

crucial para la elección del nuevo primario y la recuperación rápida. Cuando un nuevo

46
primario es elegido, los secundarios utilizan el oplog para ponerse al día con las

operaciones que ocurrieron durante el tiempo en que el nodo primario estaba inactivo.

Monitorización y Auditoría: El oplog también se puede utilizar para monitorizar las

operaciones que ocurren en el conjunto de réplicas. Puede ser útil para propósitos de

auditoría y seguimiento de cambios.

db.oplog.rs.find()

db.oplog.rs.find({"ns" : "sample_supplies.sales" }).sort({$natural: -1}).limit(5)

Backup Incremental: El oplog se utiliza para realizar copias de seguridad incrementales. Al

realizar una copia de seguridad inicial y luego aplicar las operaciones del oplog, se puede

reconstruir la base de datos en cualquier punto en el tiempo.

Implementación de Sharding: Cuando se utiliza la fragmentación (sharding) en MongoDB,

el oplog es esencial para asegurar que las operaciones de escritura se repliquen

correctamente en los fragmentos (shards).

Section 8: BACKUP AND RECOVERY (1%)

El mongoimport es una herramienta que importa contenido desde un JSON extendido, CSV

o TSV creada por mongoexport, o potencialmente, otra herramienta de exportación de

terceros.

El mongoexport es una herramienta que produce una exportación JSON o CSV de datos

almacenados en una instancia de MongoDB.

8.1 Identify how to create a backup of a replica set.

1. RTO (Recovery Time Objective): El RTO es el tiempo máximo que una

empresa puede tolerar después de un corte o interrupción antes de que la

interrupción se vuelva insoportable para las operaciones comerciales normales.

En otras palabras, es el tiempo que lleva restaurar completamente los sistemas y

47
 reanudar las operaciones comerciales después de un evento de interrupción. El

RTO se determina en función de varios factores, como la criticidad de los

sistemas, los recursos disponibles y el costo del tiempo de inactividad. Por

ejemplo, si una empresa tiene un RTO de tres horas, esto significa que todos los

sistemas deben estar en funcionamiento a más tardar tres horas después de un

corte.

2. RPO (Recovery Point Objective): El RPO es la cantidad máxima de pérdida de

datos que una empresa está dispuesta a tolerar en caso de una interrupción,

expresada como una cantidad de tiempo. En otras palabras, es el punto en el

tiempo hasta el cual una empresa está dispuesta a aceptar la pérdida de datos

en caso de un evento de interrupción. El RPO se determina en función de varios

factores, como la criticidad de los datos, el tiempo y el esfuerzo requeridos para

recrear o volver a ingresar los datos perdidos, y el costo del tiempo de

inactividad. Por ejemplo, si una empresa decide que puede tolerar una pérdida

de datos de dos horas, esto significa que necesitan recuperar todos los datos

que se registraron antes de ese período de tiempo en caso de una interrupción.

Estos dos conceptos son fundamentales para desarrollar un plan de respaldo efectivo,

ya que ayudan a determinar cuánto tiempo puede llevar restaurar los sistemas y cuánta

pérdida de datos es aceptable para la empresa.

https://learn.mongodb.com/learn/course/self-managed-backup-recovery/lesson-1-

backup-plans-on-a-mongodb-server/learn

Tipos de Backup

1- mongodump

* Propósito: Se utiliza para realizar copias de seguridad de bases de datos

MongoDB.
* Funcionalidad: mongodump realiza una copia de seguridad completa de una

48
 base de datos MongoDB, incluidos todos sus documentos y metadatos, y la
almacena en un formato de volcado binario BSON. Esta herramienta puede ser
útil para realizar copias de seguridad regulares de los datos de tu base de datos
MongoDB, lo que te permite recuperar los datos en caso de pérdida o
corrupción. A continuación se muestra una descripción de los archivos que
mongodump puede crear:
Archivos BSON: mongodump crea archivos BSON que contienen los datos de
la base de datos y las colecciones que se están respaldando. Estos archivos
tienen la extensión .bson. Por ejemplo, mongodump puede crear archivos
como purchase orders.bson.
Archivos de metadatos: mongodump también crea archivos de metadatos
que contienen información sobre las colecciones y los índices que se están
respaldando. Estos archivos tienen la extensión .metadata.json. Por ejemplo,
mongodump puede crear archivos como purchase orders.metadata.json.
Es importante tener en cuenta que mongodump no crea archivos JSON
directamente. En su lugar, utiliza archivos BSON para respaldar los datos de la
base de datos.

* Sintaxis: mongodump <options> <connection-string>

* Opciones:

-h, --host: Especifica el host y el puerto del servidor de MongoDB (separados por
: ).

-d, --db: Especifica la base de datos que se desea hacer copia de seguridad.

-c, --collection: Especifica una colección dentro de la base de datos para hacer
copia de seguridad.

-u, --username y -p, --password: Especifica el nombre de usuario y contraseña

para autenticarse en el servidor de MongoDB.

-o, --out: Especifica la ubicación del directorio donde se guardará la copia de

seguridad.

--gzip: Comprime la salida utilizando gzip.

--archive: Escribe la salida en un archivo en lugar de un directorio.

--oplog: Crea un archivo llamado "oplog.bson" como parte de la producción que

contiene entradas de registro de operaciones que ocurren durante el proceso.

49
2- mongorestore

* Propósito: Se utiliza para restaurar bases de datos MongoDB desde las copias
de seguridad creadas por mongodump.
* Funcionalidad: mongorestore toma los archivos de volcado binario BSON o de
intercambio de datos MongoDB (JSON) creados por mongodump y los restaura
en una base de datos MongoDB. Esta herramienta es útil para recuperar los
datos de una copia de seguridad después de una pérdida de datos o corrupción
en una base de datos MongoDB.A continuación se muestra una descripción de
los archivos que mongorestore puede leer:
Archivos BSON: mongorestore puede restaurar archivos BSON generados por
mongodump. Estos archivos contienen los datos de la base de datos y las
colecciones que se están restaurando. Por ejemplo, mongorestore puede
restaurar archivos como purchaseorders.bson.
Archivos de metadatos: mongorestore también puede leer archivos de
metadatos generados por mongodump. Estos archivos contienen información
sobre las colecciones y los índices que se están restaurando. Por ejemplo,
mongorestore puede leer archivos como purchaseorders.metadata.json.
Es importante tener en cuenta que mongorestore no crea archivos JSON
directamente. En su lugar, utiliza archivos BSON para restaurar los datos en la base
de datos.

* Sintaxis: mongorestore <options> <connection-string> <directory or file to

restore>
* Advertencia: Es importante que exista compatibilidad entre las versiones del
archivo a restaurar y el cluster para no perder información.
* Opciones:

-h, --host, -d, --db, -u, --username, -p, --password, -c, --collection, -o,- -out, –
gzip : Las mismas opciones que en mongodump, pero para la operación de
restauración .

–nsInclude: Esta opción te permite restaurar solo las colecciones especificadas.

Puedes proporcionar un nombre de colección o un patrón de expresión regular
para incluir sólo las colecciones que coincidan con el patrón.

–nsExclude: Por el contrario, esta opción te permite excluir las colecciones

especificadas durante la restauración. También se puede usar un patrón de
expresión regular.

–noIndexRestore: Con esta opción se evita que se restauren los índices.

50
 –writeConcern: Nos permite establecer la preocupación de escritura, que por
defecto es ‘majority’.

–archive: Permite cargar archivos con extensión ‘archive’. Son archivos que
contienen múltiples volcados BSON comprimidos, lo que puede ser útil para
transferir o almacenar grandes volúmenes de datos de forma eficiente.

–oplogReplay: Esta opción te permite aplicar los oplog (registros de

operaciones) de la base de datos de origen durante el proceso de restauración.
Esto es útil si estás restaurando una base de datos de un punto en el tiempo
específico y deseas aplicar los cambios de la réplica secundaria para mantener
la consistencia de los datos con el clúster original

--drop: Elimina primero todas las colecciones de la base de datos de destino

antes de restaurar. Los documentos restaurados se les asigna un nuevo ‘_id’.

–nsFrom: Esta opción te permite especificar el namespace de origen de los

datos durante el proceso de restauración. El namespace de origen es el nombre
completo de la colección en la base de datos de la copia de seguridad. Puedes
utilizar esta opción para restaurar los datos de una copia de seguridad en una
base de datos con un nombre de colección diferente al original.

–nsTo: Por el contrario, esta opción te permite especificar el namespace de

destino de los datos durante el proceso de restauración. El namespace de
destino es el nombre completo de la colección en la base de datos de destino
donde se restaurarán los datos. Puedes utilizar esta opción para restaurar los
datos de una copia de seguridad en una colección con un nombre diferente en la
base de datos de destino.

3. Snapshot

Propósito: Un Snapshot en MongoDB es una copia completa de los datos en un punto

específico en el tiempo. Los snapshots son útiles para realizar copias de seguridad y
recuperación de desastres. Proporcionan una vista coherente y aislada de los datos en
un momento determinado, lo que permite restaurar los datos a ese estado en caso de
pérdida o corrupción.

Funcionalidad: El Snapshot en MongoDB se puede lograr utilizando diferentes

herramientas dependiendo del sistema operativo y las necesidades. Algunas de las
herramientas comunes para crear snapshots son Logical Volume Manager para Linux,
MongoDB Ops Manager y MongoDB Atlas. Los proveedores de servicios en la nube
también tienen sus propias herramientas.

51
Antes de crear un snapshot, es importante tener en cuenta algunos factores. Primero,

se debe bloquear la base de datos utilizando el comando fsyncLock. Esto asegura

que todas las operaciones de escritura pendientes se guarden en disco y bloquea la

instancia de MongoDB para evitar escrituras adicionales. Además, se recomienda aislar

la implementación de MongoDB para evitar que el volumen de origen contenga otros

datos que no sean de MongoDB.

Después de crear el snapshot, se deben considerar los métodos para extraer los datos

del snapshot para su almacenamiento fuera de línea. Dos métodos comunes son el

archivo de volumen de snapshot y el archivo del sistema de archivos. El archivo de

volumen de snapshot es una copia completa del volumen de origen, incluidos los

cambios que ocurrieron durante la creación del snapshot. Esto se puede lograr

utilizando la utilidad dd en Linux. El archivo del sistema de archivos implica montar el

volumen de snapshot y utilizar herramientas del sistema de archivos, como tar, para

archivar los archivos de datos reales.

Sintaxis: La sintaxis específica para crear un snapshot en MongoDB depende de la

herramienta utilizada para crear el snapshot. Por ejemplo, si estás utilizando MongoDB
Ops Manager, puedes crear un snapshot utilizando la interfaz de usuario o la API de
Ops Manager.

Paso a paso (usando dd)

Bloquea la base de datos utilizando el comando fsyncLock en la shell de

MongoDB:

db.fsyncLock() // Dentro de mongoshell

El siguiente código muestra cómo crear un volumen de instantáneas. El volumen

de instantánea tiene un tamaño máximo de 100 megabytes y está nombrado
como mdb-snapshot y respaldado por el volumen del almacén de datos de
MongoDB.

52
 exit // Para salir de Mongoshell

sudo lvcreate --size 100M --snapshot --name mdb-

snapshot /dev/vg0/mdb;

Desbloquea la base de datos utilizando el comando fsyncUnlock en la shell de

MongoDB:

db.fsyncUnlock()

El siguiente código realiza una copia completa del volumen de la instantánea,

transmite los datos a la gzip utilidad para su compresión y finalmente redirige
la salida al archivo comprimido.

exit // Para salir de Mongoshell

sudo dd status=progress if=/dev/vg0/mdb-snapshot | gzip

> mdb-snapshot.gz

Restaurar la instantánea archivada

El siguiente código muestra cómo restaurar la instantánea archivada. Primero,

cree un nuevo volumen lógico llamado :mdb-new

sudo lvcreate --size 1G --name mdb-new vg0;

A continuación, extraiga la instantánea y escríbala en el nuevo volumen lógico:

gzip -d -c mdb-snapshot.gz | sudo dd status=progress

of=/dev/vg0/mdb-new

Luego, detenga el servicio MongoDB antes de montarlo en el directorio fuente:

sudo systemctl stop -l mongod; sudo systemctl status -l

mongod;

Elimine cualquier archivo de datos MongoDB existente. Esto tiene fines de

demostración para mostrar cómo se restaura toda la implementación.

sudo rm -r /var/lib/mongodb/*

53
 A continuación, desmonte la implementación de MongoDB para poder montar el
volumen lógico recién restaurado en su lugar.

sudo umount /var/lib/mongodb

Monte el volumen lógico restaurado en el directorio de la base de datos

MongoDB:

sudo mount /dev/vg0/mdb-new /var/lib/mongodb

Finalmente, inicie el servicio MongoDB y conéctese a la implementación. Ejecute

show dbs para confirmar que las bases de datos han sido restauradas.

He aquí un ejemplo:

sudo systemctl start -l mongod; sudo systemctl status -

l mongod;

mongosh

show dbs

Webinar aggregations and indexes

Acceso a los videos de masterclass antiguas:

https://sites.google.com/mongodb.com/certification-program-spain/calendario-de-clases-en-vivo

libro sobre Aggregation: https://www.practical-mongodb-aggregations.com/

Capturas:

54
55
el $lookup corresponde a un LEFT OUTER JOIN y el $unionWith corresponder a un UNIONJOIN.

Con $set se añade campos de forma temporal que solo existe en mi consulta o se añaden en la
colección? En tiempo de consulta, pero se puede persistir con $merge o $out.

56
ANEXOS:
Información detallada Mecanismos de Seguridad:

RBAC→ role based access control.

Control de Acceso Basado en Roles (Role-Based Access Control): Permite a los

administradores otorgar y restringir permisos a nivel de colección para los usuarios. Con la

definición y asignación de roles adecuados, esta solución evita la divulgación accidental de

datos y el acceso no autorizado.

SCRAM →autenticación mediante una encryptedKey . Predeterminado por mongo.

SCRAM (Salted Challenge Response Authentication Mechanism) es el mecanismo de

autenticación predeterminado en MongoDB. SCRAM se basa en el estándar IETF RFC 5802 y

se utiliza para autenticar usuarios con contraseñas. MongoDB admite dos mecanismos

SCRAM: SCRAM-SHA-1 y SCRAM-SHA-256. SCRAM-SHA-1 utiliza la función de hash SHA-1,

mientras que SCRAM-SHA-256 utiliza la función de hash SHA-256.

Kerberos: es un protocolo de autenticación estándar de la industria utilizado en sistemas

cliente/servidor. En el contexto de MongoDB, Kerberos permite la autenticación de clientes

de MongoDB ante las instancias mongod y mongos. Kerberos aprovecha la infraestructura

y los procesos de autenticación existentes. MongoDB Enterprise solo admite la

implementación de Kerberos de MIT.

LDAP significa Lightweight Directory Access Protocol. Es un protocolo utilizado para

acceder y mantener servicios de información de directorio distribuido a través de una red

IP. En el contexto de MongoDB, LDAP se utiliza para fines de autenticación y autorización.

La autorización LDAP en MongoDB admite varios métodos de autenticación, incluida la

autenticación de proxy LDAP, la autenticación de Kerberos y x.509.

POSIBLES PREGUNTAS EN LA CERTIFICACIÓN

57
66 preguntas. El exámen dura 90min. Los fallos no restan pero debemos sacar un 80%.

> Al venir de Javascript hay que tener en cuenta las reglas de JS y las palabras reservadas técnicamente en

minusculas todo.

- Importante los índices parciales

- tienes x consulta, ¿cuáles índices cubren esta consulta? Y viceversa

- Pregunta: Tengo esta query, cual es el mejor Índice (ESR)

- aggregate pipeline

- Caen muchas preguntas del journaling

- Lo que se debe memorizar es la parte que se hace con comandos
- Mongodump junto con snapshot y mongoexport
- NO cae Sharding en la certificación Preparar muy bien para la certificación
replicación????????????
- en aggregation $set no aparece directamente en la certificación, es un alias de $addFields
- “cual de estas tecnologías no se puede implementar en mongodb” por poner un ejemplo
- Data modeling y transacciones no entra¿?¿? En DBA
- Flexibilidad
- Escalabilidad
- Página 13:
- 100T
- 16 MB
-
- Patrón de diseño: 2 ó 3 preguntas.
- Replicar: Alta dsiponibilidad.
- como se asigna un role a todas las colecciones o todas las bd. Se hace con un string vacío(“”)
- dada una consulta verificar si usa o no un índice y que etapas recorre.
- en aggregation $set no aparece directamente en la certificación, es un alias de $addFields
- “cual de estas tecnologías no se puede implementar en mongodb” por poner un ejemplo
- Data modeling y transacciones no entra¿?¿? En DBA
- en el examen no entran las time series collections

APUNTES CAROLINA INICIO EN MONGO + APUNTES EN CLASE:

58
Mongo es de tipo documental.
La unidad básica es un documento.
Desnormalización: poner los datos de la forma más reducida posible.
El formato básico es un JSON.
La clave es un string y el valor el dato que queramos
La forma de guardar los datos de forma persistente es BSON ya que pesa menos.
Agility: dentro de una misma colección puedo tener documentos con formato distinto

Mongo tiene drivers para los lenguajes más utilizados.

El schema matter: puede ser rígido como en sql o no, se puede decidir.
No hay por qué decidir en la implementación de la BD el tipo de datos que se van a guardar. El tipo de
datos se almacenará según venga.

Wired Tiger es la librería que usa mongo para guardar los datos tanto en caché como en disco
persistente.
Trabaja sobre caché para acelerar las consultas.
El grabado de datos es atómico. Las operaciones de escritura en cualquier documento tienen que
reescribir todo, no vale rellenarlo a medias. Además, se bloquean las escrituras múltiples para asegurar
la persistencia y la concurrencia de los datos.
Todo se guarda en memoria en forma de árbol binario.
Los ficheros que están en la caché de wiredtiger están descomprimidos.

Journaling and checkpoint se aseguran de gestionar la memoria. Cada 60 seg se persiste la memoria
caché en el disco. (son ficheros independientes)

Journalist: se encarga de guardar lo que estoy gestionando en tiempo real en memoria caché. Cada 60
segundos lo que estás trabajando pasa a ser persistente gracias al checkpoint.

Recovery= last checkpoint + apply journal

Valor de la cache por defecto: (Ram-1Gb) /2

Cuando no indicas la cadena de conexión no incluye la bd crea una por defecto que es TEST y es virtual

59
LOS ARGUMENTOS SIEMPRE SON JSON

Show collections
Use nombre_db
Find(): muestra la colección
InsertOne({clave:valor})
InsertMany({clave:valor},{},{},…..) el guardado no es atómico, solo por cada elemento.
Find({clave:valor}) Busca el objeto
PROYECCIÓN: Find({clave:valor}, {_id:1, name:1, spend:1}) 🡪 solo devuelve el id, name y spend del filtro
(o todos a 1 o todos a 0, sino da error. Solo el _id se puede se puede poner a 0 o 1 indistintamente)
Basch o algo así es la cantidad de documentos que devuelve el servidor.

.limit()🡪 pone limite de registros

.skip()🡪muestra a partir de
SE USAN AMBOS PARA PAGINAR

Operadores:
$or🡪 para el or hay que declararlo al principio de los argumentos y las opciones dentro de un array. No
se puede usar con $text
Db.coleccion.find({$or[{clave:valor},{clave2:valor2}]})

$in🡪 db.coleccion.find({clave: {$in [{valor1},{valor2}]})

$nin🡪 NOT IN
$eq 🡪 equal
$ne 🡪NotEqual
$cond{if}{then}{else} 🡪 condicional.
$inc 🡪 incrementa el valor del campo en la cantidad indicada en el argumento.

Arrays:
En los arrays matchea aunque no pongas el array entero en la consulta.

$all 🡪 solo matchea si los elementos que están en la consulta están todos. No importa el orden.

$size🡪 devuelve el tamaño del array. Como el .length()

60
$elemMatch🡪

.Sort({}) 🡪 (1º sort, 2º limit, 3º skip) 🡪 sort(argumento1: -1 ó 1, decreciente o creciente )

Rnd(40) 🡪 random entre 1 y 40

INSERT
$set 🡪 para indicar el argumento a modificar en el insert
$unset🡪 hace desaparecer un campo del documento.
Hay que indicar el argumento true, -1 o “” para que borre el campo
$inc🡪 Incremento, suma y almacena (con número negativo resta)
$mul 🡪 Multiplicación y almacena (con número negativo divide)
$max//$min

replaceOne() apenas se usa porque gasta muchos recursos, reemplaza el documento completo. Es como
un delete() y un insert(). Lo pisa todo menos el _id.

Write Concerns – a cuantos nodos tengo que escribir para confirmar la escritura correcta.

Al escribir en la bd se recibe una confirmación que se lanza cuando se ha confirmado la escritura

Pérdida silenciosa de datos (silently lost)- esto se produce cuando el write concern está a 1 y solo se
confirma cuando se escribe en el primario. Se cambia el parámetro a Majority para que solo se confirme
si se ha escrito en la mayoría de los nodos. De esta manera se evita que se pierda la información al
realizar el ROLLBACK después de la caída de uno de los nodos.

W:0 – no confirmation
W:1 – confirmar cuando se escribe en el primario.
W:Majority – Confirmar al escribir en la mayoría de los nodos.
J:1 – Se puede poner en cualquiera de las anteriores para saltarse la etapa de checkpoint y escribir
directamente en disco, saltando la caché.

61
 ARRAYS:
$size devuelve el tamaño de un array.

$elemMatch 🡪 se usa para hacer queries en arrays dentro de arrays.

Cuando se quieren ordenar arrays dentro de una colleccion estos se ordenan por el valor de la primera
posición del array.
Los arrays dentro de arrays tienen consultas muy lentas ya que hay que recorrer todo el array. Hay que
modificar el diseño del documento para modificar el array embebido por un documento embebido que
contenga ese array.

Querying on Array Elements in MongoDB

Review the following code, which demonstrates how to query array elements in MongoDB.

Find Documents with an Array That Contains a Specified Value

In the following example, "InvestmentFund" is not enclosed in square brackets, so MongoDB

returns all documents within the

products

array that contain the specified value.

db.accounts.find({ products: "InvestmentFund"})

Find a Document by Using the

$elemMatch

Operator

Use the

$elemMatch

62
operator to find all documents that contain the specified subdocument. For example:

db.sales.find({
items: {
$elemMatch: { name: "laptop", price: { $gt: 800 }, quantity:
{ $gte: 1 } },
},
})

SEGURIDAD de las bases de datos:

Authentication:
Contraseña
Certificado de seguridad
biometría

scram-SHA🡪 username and password

x509
LDAP 🡪 directorio active
Kerberos 🡪
MONGODB-AWS 🡪 (solo atlas) autenticación de Amazon

Cada tipo de usuario tiene un nivel distinto de permisos. No deben compartir la forma de autenticarse.

OPSManager 🡪 para tu servidor propio. Los usuarios solo se pueden gestionar desde atlas.
OPSManager simple installation 🡪 video `para instalar el servidor

El permiso predefinido es diferente en atlas y en mongosh

Los usuarios de las bases de datos en ATLAS solo pueden dar de alta users desde atlas, no desde la
consola.

ATLAS es el gestor de la base de datos en la nube.

COMPASS es el cliente que realiza las consultas.

63
64
ENCRIPTACIÓN : (estudiar bien)

ON THE WIRE(NETWORK)
MongoDB admite TLS/SSL (Seguridad de la capa de transporte/Capa de sockets seguros)
para cifrar todo el tráfico de red de MongoDB. TLS/SSL garantiza que el tráfico de red
MongoDB solo sea legible por el cliente previsto.

En atlas es obligatorio. Usa TLS

RequireTLS, preferTLS, allowTLS, disabled

x.509 es el certificado para confirmar la conexión segura

AT REST (DISK)
El cifrado a nivel de disco en MongoDB se refiere al cifrado de datos en reposo en el disco.
Esta característica permite a MongoDB cifrar los archivos de datos almacenados en el
servidor de la base de datos, asegurando que solo las partes con la clave de descifrado
puedan decodificar y leer los datos. El cifrado a nivel de disco proporciona una capa
adicional de seguridad para proteger los datos confidenciales incluso si el medio de
almacenamiento físico está comprometido.

En ATLAS es obligatorio
Se puede duplicar dificultad añadiendo un encriptado doble a la clave del hash.

Encriptación física. Aunque roben el disco no lo pueden leer

IN USE(Client)
Se define en el documento que campos están encriptados para guardarlo en BSON.
Solo se puede desencriptar con la clave y el algoritmo de desencriptación. No solo con user-password.
El cifrado de nivel de campo del lado del cliente (CSFLE) es una característica que le permite
cifrar datos en su aplicación antes de enviarlos a través de la red a MongoDB. Con CSFLE
habilitado, ningún producto MongoDB tiene acceso a sus datos sin cifrar.

65
66
Auditing

Normalmente se auditan las operaciones de administración y las fallidas ya que consume muchos
recursos.
Se audita todo lo que hace una persona, lo que viene de programadores y la administración de la base
de datos.

INTERNAL AUTHENTICATION
Todas las conexiones internas del replicaset se gestionan mediante certificados SCRAM-SHA o x.509

No hay posibilidad de SQLInjection porque no parsea a string las consultas.

.explain() sin argumentos solo devuelve una estimación.

.explain(“ExecutionStats”) te muestra información sobre la consulta que se realiza. No sobre el resultado
de la query
Por defecto está en modo “queryplanner”
También podemos usar “allplanexecution”

Queryplanner es una propiedad de los objetos en mongo.

Dentro del documento que devuelve explain podemos acceder a la información con notación punto y
bajar los niveles.
Db.collection.find().explain().queryplanner.stage devolvería un string con el nombre de la fase usada en
la consulta. “Fetch”, “coolscan”.

Nº de retornados, total examined y total keys tienen que ser lo más parecidos para que la base de datos
esté bien indexados.
El parámetro COLLSCAN(etapa de la consulta) indica que la query ha tenido que revisar toda la colección
por lo que se necesita un índice.-SOLO SE HA EJECUTADO ESTA ETAPA. ES LENTA Y OCUPA MUCHA RAM.

FECH e IXSCAN: indican que se ha mirado en un índice en la etapa IXSCAN y el fetch solo muestra lo que
indica el índice.

67
En el índice se indica el campo que va a ser el criterio de ordenación y más tarde 1 o -1 para indicar el
orden ascendente o descendente.
getIndexes()🡪 indica una lista de ínndices de la collection

.hint(nombre Index)🡪 obliga a usar un índice en concreto

Un índice solo puede hacerse cargo de la consulta si el comienzo del índice se encuentra en la sintaxis.
(prefijo). El prefijo puede aparecer en el .short() y también utilizará el índice.

Revisar el ratio entre el número de resultados y las claves examinadas. Tiene que estar lo más cerca
posible a 1 para que la query esté optimizada y no necesite revisar documentos que no son los correctos.

Si un mismo documento necesita varios index por que tiene varias consultas?
O se duplica la base de datos o se generan varios index. Depende del caso de uso.

MONITORIZACIÓN:

Compass, Atlas o OPSManager

Db.currentOp() – output 🡪 retorna el estado de la base de datos en tiempo real.

Db.killOp(idOp) 🡪 mata el proceso.-

Oplog es la colección de datos en la que se guardan los logs de las operaciones.

./mongostat –uri conexión a ATLAS

mongoTop 🡪 indica que colecciónes están consumiendo más recursos

Query Targeting es la media de optimización de la base de datos.

La terminal muestra las últimas 1024 entradas de Logs. En Atlas se puede acceder a los últimos meses.

68
Si una query tarda más de 100 milisegundos se da de alta un log para que aparezcan. Se puede
configurar y modificar
Existen tanto de gestión de la base como del funcionamiento interno.

Db.setProfilingLevel({1, slows:20})
Se usa para modificar la forma en que se tratan las gestiones lentas.
0 no aparece ninguna.
1 depende del tiempo, slows: milisegundos.
2 todas

CAUSAS DE LENTITUD EN LA BD.

- Falta caché (muchos índices o el peso de uno supera la memoria)
-Lentitud con el checkpoint (se ve en el ratio de operaciones y el pico de uso de recursos)
- Bloqueo de procesos. Locking.
-Uso excesivo de CPU:
-Autenticación constante. Es de las funciones más costosas.
-Arrays demasiado largos (+- 200)
-Ejecutar código en la base de datos.
-Ordenación sin índices (short).
-Falta de memoria caché por que el índice pesa más que la RAM. Necesario incrementar los
recursos. serverStatus() devuelve el estado del servidor.
-Conflictos de escritura: Conlleva modificar el esquema de la base de datos para que dos
procesos no intenten escribir en el mismo documento.

-USO EXCESIVO DE CPU 🡪 Demasiados inicios de sesión por no mantenerla activa.

69
INDEXES
Los índices aceleran las queries. Reduce el uso de recursos.
El índice es una copia de parte del documento en otro espacio de memoria.
El _id lleva un índice implícito generado por el servidor de mongo que es _id_.
Primero las queryes y después los índices.
Se almacenan como árbol binario.

La indexación la decide el desarrollador.

Todas las queries de lectura y update estarían soportadas por al menos un índice siempre que sea
posible.

SORT 🡪 es la etapa que más consume. Incluso puede generar un fallo.

ESR🡪 equality, short, Range para ordenar los índices y hacer las queries lo más eficientes posible.
Si tengo varios criterios de igualdad, todos al principio, Varios de ordenación, en el medio, y los de
rango, todos al final.

Es esperado si tengo criterios de ordenación y de rango en la misma query que el ratio no va a ser igual a
1. Con varios de rango, tampoco.
La ordenación del índice y la query tienen que ir todos en la misma dirección.
Query short({a:1, b:1}) 🡪 en el índice tienen que ir los dos argumentos a 1 o los dos a -1.

Query short({a:1, b:-1}) 🡪 en el índice tienen que ir uno a 1 y otro a -1.

Tienen que ir igual

Más de 15 índices en una misma colección puede hacer que la app pete

Existen bases de datos orientadas a escritura y otras a lectura.

Las de escritura no se recomiendan más de 3-4 índices.

Allowdiskused()🡪 ayuda a burlar el límite de 100 Mb en memoria para una consulta que lo necesite. La
primera clave del índice tiene que encontrarse dentro de la query para que esta use el índice.

70
Las queries se ordenan por prioridad, sobre todo dependiendo de las veces que se ejecutan. Las más
ejecutadas deben estar optimizadas, con un buen índice y las que tienen menos prioridad sacrificarlas y
adaptarlas al sistema para que se realicen sin entorpecer el normal funcionamiento de la BD.

El campo collation sirve para especificar la fuerza que tendrá la consulta, el número de coincidencias
erróneas que puede aceptar.

Índices WILDCARD:
Generan un índice sobre todas las propiedades del documento. Comodín, se usa únicamente cuando no
se sabe qué campos se esperan o si estos puedan cambiar.
Se usa el operador $** en el parámetro de la clave.

db.collection.createIndex(“$**”:1) para todas las claves del documento.

db.collection.createIndex(“field.$**”:1) para un documento embebido.

Índices PARTIAL:
Se utiliza para aplicar un filtro al índice. ($gt,&lt, $eq, etc…)
Se usa el elemento partialFilterExpression: {state:”CA” | state:{$lt…}} para indicar que use el
índice solo con el state “CA”o el state less than o la expresión que se indique.

db.restaurants.createIndex(
{ cuisine: 1, name: 1 },
{ partialFilterExpression: { rating: { $gt: 5 } } }
)

Si en la consulta no se incluye la clave del índice parcial (rating) no usa el índice ya que no devolvería
todos los resultados.

db.restaurants.find(
{ cuisine: Italian})
no usa el índice por que no mostraría los restaurantes italianos menores a rating:5

Índices SPARSE:
Si queremos hacer un find en una clave concreta pero esta no se encuentra en todos los documentos
este mostrará los que no lo tengan al final de la lista. Este índice se usa solo en los documentos en los

71
que exista el campo indexado ignorando los documentos que no lo contengan. Si el campo está a null, si
que lo tiene en consideración, el campo si está creado.

Es una manera de disminuir la carga de la consulta. Todos los índices pueden ser SPARSE.
db.collection.createIndex({Field:1}, {sparse:true})

2D, 2Dsphere, geoGaystack, Wild card va por defecto.

TIME SERIES COLLECTIONS:

se utilizan para mejorar la eficiencia de grandes volúmenes de datos que se necesita ordenar en el
tiempo. (ojear los apuntes de Ricardo)

No se puede crear una colección de series temporales como colección limitada

(Capped Collection).

72
Índices de cluster:
??????????????

Índices GeoSpatial:
se usa sobre documentos que representan un objeto con types: y coordinates:
se declara indicando “2dSphere” o “2d” en el argumento de ordenación al crear el índice.

createIndex({field:”2dSphere”})

Índice Multikey:
se crean al usar un documento que contiene un array como clave del índice.

TTL 🡪 TIME TO LIVE

Es un índice que va borrando los documentos

Cada minuto se ejecuta una query que verifica que no hay documentos que hayan cumplido el tiempo
de vida. Esto no es productivo ya que se puede ejecutar un script con menos frecuencia que se encargue
de esta función.
Db.coleccion.createIndex({“create_date: 1”}, {expireAfterSecond: 60})

Rolling Index.
- Crear índices en modo Rolling se usa para que el nodo primario no esté generando el índice a la vez que
atiende consultas. De esta manera no se satura la máquina. Hay que tener en cuenta el tiempo del Oplog
para no perder los datos mientras un nodo está desconectado.
OpsManager, Atlass y compass lo hacen implícito. Sino, hay que configurarlo completo. Esto reduce el
downtime de la aplicación.

73
REPLICATION
Para sincronizar el replicaSet utiliza el algoritmo RAFT

Utiliza una instancia de mongod

Los 3 nodos son exactamente iguales. Solo cambian los roles. No pueden tener distintos tamaños.
Uno es primario otro secundario y el resto no-voting

El primario es el único que admite escritura y es este el que lo envía a los secundarios que están
escuchando. Existe un pequeño delay entre el primario y el resto. Las lecturas por defecto van al nodo
primario pero se puede modificar en el cliente.

Entre los nodos, al hacer las solicitudes de escritura se incluye la solicitud a Oplog.rs. Esta incluye el
tiempo de la última actualización para saber hasta dónde hay que escribir la réplica.

Mongo tiene un servicio 24/7 y compromiso de respuesta en menos de 4 horas si lo tienes contratado.

Para que el replicaSet funcione correctamente se necesita tener levantados al menos la mayoría de los
nodos. Si se cae alguno, la otra mayoría se reestructura para no sufrir. Si el que se cae es el primario los
demás hacen la selección del nuevo primario. Durante esta selección, al no tener primario y ser este el
que recoge las operaciones de escritura, estas se ponen en cola. Si el que se cae es uno de los
secundarios, a través del Oplog.rs, se le indica al primario donde se cayó y poder recuperar la
información. De aquí que sea tan importante almacenar al menos 24 horas de Opslog.rs. Si se pasa el
tiempo y no se puede recuperar a través del Log hay que replicar todo el nodo desde el primario ya que
no se puede recuperar la info. Todo esto a través de InitialSync()para que no se bloqueen y te quedes sin
nodo primario es recomendable tener siempre nodos impares.

RAFT también se utiliza para elegir al nuevo nodo primario.

Se puede asignar prioridad a los nodos.

Write Concerns – a cuantos nodos tengo que escribir para confirmar la escritura correcta.

Al escribir en la bd se recibe una confirmación que se lanza cuando se ha confirmado la escritura

Pérdida silenciosa de datos (silently lost)- esto se produce cuando el write concern está a 1 y solo se
confirma cuando se escribe en el primario. Se cambia el parámetro a Majority para que solo se confirme

74
si se ha escrito en la mayoría de los nodos. De esta manera se evita que se pierda la información al
realizar el ROLLBACK después de la caída de uno de los nodos.

W:0 – no confirmation
W:1 – confirmar cuando se escribe en el primario.
W:Majority – Confirmar al escribir en la mayoría de los nodos.
J:1 – Se puede poner en cualquiera de las anteriores para saltarse la etapa de checkpoint y escribir
directamente en disco, saltando la caché.

READ CONCERNS – cuanto tiene que replicarse el dato para poder leerlo.
Read preferences, se incluyen en la cadena de conexión para elegir el nodo en el que leer los datos.
Se suele usar para las queries de análisis.

Arbiter- nodo que forma parte del replicaSet pero no copia datos. No tiene datos. Hay que bajar el
writeconcerns a 0 porque sino si se cae una máquina se bloquean las operaciones de escritura al no
confirmarse la escritura.

75
Sharding
utiliza una instancia mongos
Es un mecanismo para paralelizar la base de datos. Particiona la base de datos en varios replicaset. Esta
partición puede ser vertical u horizontal.

Vertical- Pongo una máquina más grande

Limitación – no existe más potencia en hardware. Puede llegar a ser más caro.
Horizontal – Pongo varias máquinas y reparto los datos. Varios replicaset en paralelo. Mantengo
trabajando en paralelo varias máquinas (más pequeñas y por tanto más baratas).

O se tiene replicaset o shard. Se puede mudar de replicaset a shard pero no volver atrás.

Es aconsejable cuando se crea un proyecto tener en cuenta la posibilidad de necesitar sharding en el

futuro y cómo se implementaría. El mínimo de máquinas para montar un sharding es de 11 máquinas.

Una máquina mongos actúa como enrutador entre los drivers de la aplicación, el servidor de
configuración (Replicaset de metadatos con las direcciones de memoria) y los servidores de shard. Se
aconseja que el MongoS tenga una alta RAM para poder atender las solicitudes. MongoS copia los
metadatos en caché y los va actualizando solo cuando se edita. Así se ahorran recursos.

Cuándo se usa el sharding:

Cuando faltan recursos físicos.
Cuando la BD pesa más de 4Tb.

Cuándo no:
Cuando no se alcancen ni se tenga previsión de alcanzar los límites.

shardPrimary- primario de cada shard (de cada replicaset).

VS
PrimaryShard – si solo quiero particionar parte de los datos y no todas las colecciones. Las que no están
particionadas se almacenan en el PrimaryShard. A partir de MongoDB 6 se mejora el reparto de
colecciones sin particionar para no sobrecargar el shard que tiene tanto sus colecciones completas como
la parte de las particiones.

76
No solo se particiona por la falta de recursos relacionados con el peso de la BD sino también por la carga
de operaciones. Ej: si tengo una consulta de inserción con 1000 documentos se puede repartir la carga
aunque siempre es mejor enviar las consultas a la misma colección en el mismo shard ya que sino el
mongo S tiene que comportarse como un enrutador y puede ralentizar la consulta.

Existe una herramienta encargada de balancear los shard con el criterio de que pesen igual cada uno de
ellos. Ese movimiento se hace en bloques de 128Mb. Puede modificarse se puede configurar en manual
y automático. Calcula la cantidad de datos en cada replicaset o shard y balancea la ecuación de reparto.
1.-Detecto que el shard se está llenando (384 Mb) . 2.-Se copia un bloque de 128 Mb en el segundo
shard y 3.-cuando cambia el índice en los metadatos del configserver, 4.-se borra el primer bloque de
128Mb.
No es aconsejable usarlo. Consume recursos. Mejor usarlo lo menos posible y por la noche.

El criterio de partición se indica en el servidor de config. Aquí indicamos donde se encuentran los datos.
Si no se indica en la query, el servidor de MongoS lo manda a todos los shard. (query en broadcast o
skatergater o algo así)

Buen uso:
-La mayoría de las operaciones van a un único shard.

El criterio de partición
–tiene que estar incluido en la mayoría de los documentos.
-Tener una alta cardinalidad.
-Suele ser compuesta. Aconsejable incluir fecha.
-la suma de los datos que coinciden con la misma clave de shard no superen los 128Mb.

Para declarar ,la clave de shard tiene que haber un index configurado previamente con los mismos
valores.
No se recomiendan claves crecientes o decrecientes como fechas, ya que sino todas las inserciones van a
ir al mismo shard.

77
BackUPs

RPO- tiempo de la última copia.

RTO- tiempo de recuperación.

MongoDump-
Solo se pueden hacer snapshot completos.
Mientras que empieza el snapshot se pierde el control de qué datos se pierden y cuáles no. Oplog –
Incluye una pausa en un secundario para que no se pierda la consistencia de los datos mientras se realiza
el snapshot.

MongoRestore-

FileSystem-
Directamente hago una copia de los datos. O bien de la máquina virtual o bien la carpeta de los datos.
Es el más rápido ya que la copia es física. Necesario hacer backup completo de todos los datos.

Cloud Manager-OpsManager-
Solo se comunican con agentes. De manera que no haya comunicación directa entre ellos.
Deploy
Monitor
Backup
Scale
Built and supported by mongo.

Ops permite hacer backups incrementales. Permite un control más exacto y no solo un snapshot. La
única base de datos que hay que actualizar manualmente, aunque no requiere de mucho
mantenimiento es la que soporta OpsManager.

78
Snapshot:
hay que bloquear la bd para escritura(fsynclock), realizar el snapshot y volver a activar la
bd(fsyncUnlock).

Se usa LVM para realizar el snapshot en Linux.

lvcreate()

/var/lib/Mongodb
/dev

ZERO-DOWNTIME
Mi base de datos siempre está disponible. Mi aplicación no se puede parar.

Solo hay downtime en el caso que modifique la seguridad y añada el protocolo TLS.

Rolling Index.
- Crear índices en modo Rolling se usa para que el nodo primario no esté generando el índice a la vez que
atiende consultas. De esta manera no se satura la máquina. Hay que tener en cuenta el tiempo del Oplog
para no perder los datos mientras un nodo está desconectado.
OpsManager, Atlass y compass lo hacen implícito. Sino, hay que configurarlo completo. Esto reduce el
downtime de la aplicación.

MongoD- Servidor de mongodb. Si comunica el ops o cloud con el mongoD: automatización. Al contrario
es Monitorización.

Preparar muy bien para la certificación el sharing y replicación-

wiretigercachesizeGb el advanced Options restringe la cantidad de caché que se usa por cada nodo.

Siempre que se crea un agente hay que configurar y activar la monitorización en servers.
Si estamos en local los tres replicaset no pueden estar en la misma carpeta. Es necesario una para cada
uno.

79
ACTUALIZAR MONGODB

db.version() → muestra la versión actual.

db.adminCommand( { getParameter: 1, featureCompatibilityVersion: 1 } ).featureCompatibilityVersion ->

muestra las características de compatibilidad.

Ambas no pueden distanciarse más de 1 versión.

Ej: Si el servidor de mongo está ejecutando la versión 5.0.12, puede tener una FCV de 5.0 o 4.4
En el caso de una v6, sería FCV 6.0 o 5.0
Si tenemos un servidor de mongo en versión 6.0.15 con FCV 5.0, NO podemos subir la versión de mongo
a 7.0.X hasta que subamos su FCV a 6.0

rs.status().members.forEach(x) => {prinJson({ })→ rs representa los nodos del replicaset.

80
MÉTRICAS:
Scan and Orders: Aparecen los colScan y las ordenaciones en memoria.

La seguridad para que un proceso evite el OMKiller y no pete la máquina ni el SO mate el proceso se
configura la memoria RAM x/2-1Gb

La replicación de los nodos es en tiempo real mientras que cada uno tiene sus procesos independientes
para el journalist y el checkpoint.

EXAMEN: Salen proyecciones de consultas. Y también agregaciones pero muy sencillas.

Lookup: Es la manera de declarar join en mongo.

Collation: se encarga de desactivar el CASESENSITIVE y las tildes de un campo para búsquedas menos
exhaustivas como en buscadores. Necesita estar respaldado por un índice.

En lookup el match es aconsejable ponerlo al principio para limitar el número de documentos.

Al poner el $ delante del nombre de una variable indica que queremos el valor de esa propiedad.

El argumento displaybatchsize especifica el número de resultados a mostrar por el cursor.

El fichero de configuración en Windows es .cfg

--eval “consulta” 🡪 devuelve una consulta sin necesidad de registrarse en Shell.

Mongosh.Conf para Linux y Unix; mongosh.cfg para Windows. Luego se usa get y set para cambiar los
valores. .Reset

Db.getSiblingDB(nombreDB) 🡪 Devuelve un objeto de bd para poder trabajar sobre ella.

.mongosh.js 🡪 es un fichero oculto que se encuentra en la carpeta del usuario y podemos incluir
métodos y funciones para utilizar en nuestra terminal. Es un fichero oculto para protegerlo de ataques
de código malicioso, se ejecuta directamente en la consola.

La API fs (fileSistem) 🡪 está integrado en mongosh para leer y escribir ficheros. Da acceso a ficheros
Input, Output.

81
 wtiteFileSync()
.stringify() 🡪 pasa de JSON a String mediante la clase EJSON().
EJSON.Parse() 🡪 pasa un fichero de string a JSON.

Require() 🡪

ReplaceOne(identificador, documento de sustitución, opciones)

Si utilizas el _id para el filtro, el nuevo documento heredará este id.

Opciones:
Absert 🡪 (si no encuentra el original, igualmente guarda la información).(hay que tener cuidado con las
duplicidades y controlarlas con un índice que lo respalde, que sea UNIQUE.

writeConcern() 🡪 se usa para gestionar las transacciones y la atomicidad de estas configurando la

confirmación de escritura.

Collation() 🡪 reglas para letras y acentos con strings.

Hint() 🡪 para indicar el índice que nos interesa usar. Puedes indicar el hint tanto por el nombre como por
la descripción.

82