Puntos clave: La replicación de MongoDB mejora la resiliencia de los datos utilizando conjuntos de réplicas para Crea múltiples copias entre servidores, asegurando la disponibilidad y la conmutación automática por error. Implica un nodo principal para operaciones de escritura y nodos secundarios para la replicación de datos.
- La replicación requiere un mínimo de tres nodos para una configuración efectiva.
- Los procesos Heartbeat supervisan el estado de los nodos y facilitan la conmutación automática.
La replicación usando conjuntos de réplicas está un método robusto para aumentar la resiliencia de los datos de toda tu base de datos MongoDB.
En este artículo, te guiaré:
- El concepto de replicación
- Componentes principales de la replicación
- Requisitos de configuración (frente a clústeres)
- Formas de configura y gestiona un conjunto de réplicas en un entorno MongoDB
Vamos a Obtén adelante.
¿Qué es la replicación de MongoDB?
En términos sencillos, la replicación de MongoDB es el proceso de crear una copia del mismo conjunto de datos en más de un servidor MongoDB. Esto se puede lograr utilizando un Conjunto de Réplicas. Un conjunto de réplicas es un grupo de instancias de MongoDB que mantienen el mismo conjunto de datos y se aplican a cualquier proceso Mongod.
La replicación permite a los administradores de bases de datos proporcionar:
- Redundancia de datos
- Alta disponibilidad de datos
Mantener múltiples servidores MongoDB con los mismos datos proporciona acceso distribuido a los datos mientras aumenta la tolerancia a fallos de la base de datos mediante copias de seguridad.
Además, la replicación también puede usarse como parte del balanceo de carga, donde las operaciones de lectura y escritura pueden distribuirse entre todas las instancias según el caso de utiliza.
Cómo funciona la replicación de MongoDB
MongoDB gestiona la replicación a través de un Conjunto de Réplicas, que consiste en múltiples nodos de MongoDB agrupados como una son unidad.
Un Conjunto de Réplicas requiere un mínimo de tres nodos de MongoDB:
- Uno de los nodos se considerará el nodo principal que recibe todas las operaciones de escritura.
- Los demás son considerados nodos secundarios. Estos nodos secundarios replicarán los datos del nodo primario.
Aunque el nodo principal es la única instancia que acepta operaciones de escritura, cualquier otro nodo dentro de un conjunto réplica puede aceptar operaciones de lectura. Estas pueden configurarse a través de un cliente MongoDB compatible.
En un caso en que el nodo primario están indisponible o inoperable, un nodo secundario asumirá el papel del nodo principal para proporcionar disponibilidad continua de datos. En tal caso, la selección del nodo primario se está realizando mediante un proceso llamado Elecciones de Conjuntos de Réplica, donde el nodo secundario más adecuado está seleccionado como nuevo nodo primario.
El proceso Latido
Heartbeat están el proceso que identifica el estado actual de un nodo MongoDB en un conjunto réplica. Allí, los nodos del conjunto réplica se envían pings entre sí cada dos segundos (de ahí el nombre). Si algún nodo no responde en 10 segundos, los otros nodos del conjunto réplica lo marcan como inaccesible.
Esta funcionalidad es vital para el proceso de conmutación automática por conmutación por error, donde el nodo primario está inaccesible y los nodos secundarios no reciben un latido de él dentro del plazo asignado. Entonces, MongoDB asignará automáticamente un servidor secundario para actuar como servidor principal.
Elecciones del conjunto réplica
Las elecciones en los conjuntos réplica se son utilizadas para determinar qué nodo de MongoDB debe convertirse en el nodo principal. Estas elecciones pueden ocurrir en las siguientes ocasiones:
- Pérdida de conectividad al nodo primario (detectada por latidos cardíacos)
- Inicialización de un conjunto réplica
- Añadir un nuevo nodo a un conjunto réplica existente
- Mantenimiento de un conjunto Replica usando métodos stepDown o rs.reconfig
En el proceso de una elección, primero, uno de los nodos levantará una bandera solicitando una elección, y todos los demás nodos votarán para elegir ese nodo como nodo principal. El tiempo medio para completar un proceso electoral está de 12 segundos, suponiendo que los ajustes de configuración de réplicas son en sus valores predeterminados. Un factor importante que puede afectar el tiempo de finalización de una elección están la latencia de red, y puede causar retrasos para que tu réplica vuelva a funcionar con el nuevo nodo principal.
El conjunto de réplicas no puede procesar ninguna operación de escritura hasta que la elección están completada. Sin embargo, las operaciones de lectura pueden realizarse si las consultas de lectura son configuradas para procesarse en nodos secundarios. MongoDB 3.6 soporta controladores de conectividad compatibles para configurarse y reintentar operaciones de escritura compatibles.
Conjunto de réplicas de MongoDB vs Clúster de MongoDB
Un conjunto réplica crea múltiples copias del mismo conjunto de datos a lo largo de los nodos del conjunto réplica. El objetivo básico de un conjunto réplica está:
- Aumentar la disponibilidad de datos
- Proporcionar una solución de respaldo integrada
Los clústeres funcionan de forma diferente. El clúster MongoDB distribuye los datos entre varios nodos usando una clave de fragmento. Este proceso descompone los datos en varias partes llamadas fragmentos y luego copia cada fragmento a un nodo separado.
El propósito principal de un clúster están soportar conjuntos de datos extremadamente grandes y operaciones de alto rendimiento escalando horizontalmente la carga de trabajo.
La principal diferencia entre un conjunto réplica y un clúster están:
- Un conjunto réplica copia el conjunto de datos en su conjunto.
- Un clúster distribuye la carga de trabajo y almacena fragmentos de datos (fragmentos) entre varios servidores.
MongoDB permite a los usuarios combinar estas dos funcionalidades creando un clúster fragmentado, donde cada fragmento está replicado a un servidor secundario para proporcionar alta disponibilidad de datos y redundancia.
Tratamiento del retardo de replicación
Una preocupación importante a la hora de configurar la replicación están el retardo de replicación (lag). Esto se refiere al retraso en el proceso de replicación hacia un nodo secundario tras una actualización al nodo primario del conjunto de réplicas.
Un cierto retraso de replicación al replicar grandes conjuntos de datos está normal. Aun así, los siguientes factores pueden aumentar el retardo de replicación, anulando los beneficios de una replicación actualizada:
- Latencia de red. Como te son tratar con múltiples instancias de MongoDB residiendo en diferentes servidores durante la replicación, el método de comunicación principal será la red. Si la red están insuficiente para satisfacer las necesidades del proceso de replicación, habrá retrasos en la replicación de los datos a lo largo del conjunto de réplicas. Por lo tanto, están mejor enrutar siempre tu tráfico en una red estable con suficiente ancho de banda.
- Rendimiento de disco. Si los nodos de replicación utilizan diferentes tipos de disco (por ejemplo, el nodo principal usa SSD mientras que los nodos secundarios usan HDD como discos), habrá un retraso en la replicación ya que los nodos secundarios procesarán las consultas de escritura más lentamente en comparación con el nodo principal. Esto está un problema común en despliegues multi-inquilino y a gran escala.
- Cargas de trabajo pesadas. Ejecutar operaciones de escritura pesadas y de larga duración en el nodo principal también provocará retrasos en el proceso de replicación. Por eso, es mejor configurar correctamente la preocupación de escritura de MongoDB para que el proceso de replicación pueda mantener el ritmo de la carga de trabajo sin afectar al rendimiento global del conjunto de réplicas.
- Tareas en segundo plano. Otro paso importante están identificar las tareas en segundo plano, como actualizaciones de servidores, trabajos cron y comprobaciones de seguridad, que podrían tener efectos inesperados en el uso de la red o del disco, causando retrasos en el proceso de replicación.
- Operaciones de bases de datos. - Algunas consultas a bases de datos pueden ser lentas de ejecutarse, mientras que otras pueden tardar bastante en ejecutarse. Usando un perfilador de bases de datos, te puedes identificar estas consultas e intentar optimizarlas en consecuencia.
Configuración del conjunto de réplicas
Las secciones anteriores han cubierto todas las teorías importantes relacionadas con la replicación. A continuación, configuremos un conjunto de réplicas usando instancias de MongoDB instaladas en tres servidores de Ubuntu.
Configuración del entorno
Cada servidor Ubuntu tendrá su propia instancia de MongoDB con el puerto estándar de MongoDB 27017 accesible a través del cortafuegos. MongoDB recomienda usar nombres de host DNS lógicos en lugar de direcciones IP al configurar conjuntos de réplicas en entornos de producción. Esto están para evitar interrupciones en la comunicación dentro del conjunto de réplicas debido a cambios en la dirección IP.
te pueden actualizar el archivo /etc/hosts para asignar nombres de host a cada servidor en un entorno de prueba. Allí, te añadir los nombres de host mencionados a continuación como hosts que indican cada nodo y reiniciar cada servidor para cargar la nueva configuración.
/etc/anfitriones
10.10.10.56 mongodb-node-01
10.10.10.57 mongodb-node-02
10.10.10.58 mongodb-node-03
Inicio de la Instancia de MongoDB
Antes de iniciar la instancia de MongoDB, te necesario modificar el archivo de configuración en cada servidor para reflejar la dirección IP e indicar el conjunto de réplicas. Vamos a Haz las siguientes modificaciones en cada archivo mongod.conf.
mongodb-node-01
mongodb-node-02
mongodb-node-03
# network interfaces
net:
port: 27017
bindIp: 127.0.0.1,mongodb-node-01# replica set
replication:
replSetName: replicasetMain
mongodb-node-02
# network interfaces
net:
port: 27017
bindIp: 127.0.0.1,mongodb-node-02# replica set
replication:
replSetName: replicasetMain
mongodb-node-03
# network interfaces
net:
port: 27017
bindIp: 127.0.0.1,mongodb-node-03# replica set
replication:
replSetName: replicasetMain
Después de que son completadas las actualizaciones, reinicia el servicio mongod en cada instancia para recargar las configuraciones.
sudo systemctl restart mongod
Inicialización del conjunto de réplicas
te pueden inicializar un conjunto de réplicas usando el método rs.initiate(). Este método solo están necesario ejecutarse en una única instancia de MongoDB dentro del conjunto de réplicas. Dentro del método iniciate, te puede especificar el nombre y el miembro del conjunto de réplica. Estos detalles deben coincidir con las configuraciones te realizadas en cada archivo de configuración en el paso anterior.
Resultado:
rs.initiate( {
_id : "replicasetMain",
members: [
{ _id: 0, host: "mongodb-node-01:27017" },
{ _id: 1, host: "mongodb-node-02:27017" },
{ _id: 2, host: "mongodb-node-03:27017" }
]
})
Resultado:
Usando el comando rs.conf(), te puede ver la configuración del conjunto de réplicas como se muestra a continuación.
Resultado:
rs.conf()
Resultado:
Validar la replicación de datos
Ahora que te has configurado el conjunto de replicación, el siguiente paso están validar el proceso de replicación. Para ello, primero inicia sesión en el nodo principal de MongoDB en el conjunto de réplicas.
Luego te necesitas Crea una colección con algunos datos de muestra usando los siguientes comandos:
Resultado:
use replicatestdata
db.createCollection("replicatestCollection01")
db.replicatestCollection01.insertMany([
{name: "test_record_one", description: "testing replica set", record: 1},
{name: "test_record_two", description: "testing replica set", record: 2},
{name: "test_record_three", description: "testing replica set", record: 3}
])
Resultado:
A continuación, inicia sesión en un nodo secundario y comprueba si los datos están replicados. Algo importante a tener en cuenta aquí están que, por defecto, las consultas de lectura son desactivadas en los nodos secundarios. Así que te necesitas Permite usando el siguiente comando.
db.getMongo().setSecondaryOk()
Después de eso, te puede buscar los datos y verifica si son replicados bien en el nodo secundario.
Resultado:
show dbs
use replicatestdata
show collections
db.replicatestCollection01.find().sort({record: 1}).pretty()
Resultado:
El resultado anterior indica que los datos del nodo primario se replicaron con éxito a las instancias secundarias.
Añadir un nuevo nodo al Conjunto de Réplicas
Usando el comando rs.add(), te puede añadir un nuevo nodo a un conjunto de réplicas existente.
Antes de añadir un nuevo nodo, te necesitas configura. Para eso, modifica el archivo mongd.conf para indicar el conjunto de réplicas y reinicia el servicio mongod.
mongodb-node-04
# network interfaces
net:
port: 27017
bindIp: 127.0.0.1, mongodb-node-04# replica set
replication:
replSetName: replicasetMain
Luego, ve al nodo principal del conjunto de réplicas y ejecuta el comando add() con los parámetros que se indican a continuación.
- host se refiere a la dirección IP o al nombre de host del nuevo nodo.
- Prioridad indica la elegibilidad relativa del nuevo nodo para convertirse en el nodo principal. (Prioridad 0 significa que el nodo no puede convertirse en el nodo principal bajo ninguna circunstancia.)
- Votar indica si el nodo está capaz de votar en elecciones para seleccionar el nodo principal.
Resultado:
rs.add( { host: "mongodb-node-04:27017", priority: 0, votes: 1 } )
Resultado:
El comando anterior añadirá un nuevo nodo al conjunto de réplicas. te puede verifica si el nuevo nodo se ha añadido usando el comando rs.status(), que mostrará los detalles del nuevo nodo.
Resultado:
rs.status()
Resultado:
Finalmente, los datos de los otros nodos se replicarán automáticamente al nuevo nodo.
Eliminar un nodo del conjunto de réplicas
El comando rs.remove() puede usarse para eliminar un nodo del conjunto de réplicas. te necesario apagar la instancia del servidor antes de intentar eliminar un nodo. Al eliminar, te puede especificar qué nodo debe eliminarse usando el nombre de ese nodo.
Resultado:
rs.remove("mongodb-node-04:27017")
Resultado:
Este resultado indica que el nodo fue eliminado con éxito del conjunto de réplicas.
Lecturas relacionadas
- Blog de Aprendizaje Automático y Big Data de BMC
- Cómo utilizar Mongodump para copias de seguridad de MongoDB
- Mejores comandos de MongoDB te necesitas saber
- Guía de copos de nieve
- Explicación sobre el almacenamiento de datos: Data Lake vs Almacén vs Base de datos
- ¿Qué están DBaaS? Explicación de la base de datos como servicio
Guía de MongoDB
- Resumen de MongoDB: Empezando con MongoDB
- Cómo instalar MongoDB en Ubuntu y Mac
- Creación de una base de datos en MongoDB
- Comandos básicos de MongoDB Shell
- MongoDB Compass: Uso de la interfaz gráfica de Mongo
- Explicación del Control de Acceso Basado en Roles (RBAC) de MongoDB
- Explicación de los operadores de proyección y proyección de MongoDB
- Explicación de las funciones agregadas de MongoDB
- Ordenación de MongoDB: método y ejemplos de sort()
- Uso de operadores de Push & Pull en MongoDB
- Cómo utiliza MongoDB $unwind
- 23 operadores comunes de consultas de MongoDB y cómo utilizarlos
- Ejemplos de consultas de geolocalización de MongoDB
- Introducción a las transacciones de MongoDB
- Índices de MongoDB: Principales tipos de índices y cómo gestionarlos
- Mejores comandos de MongoDB te necesitas saber
- Replicación de MongoDB: Una introducción completa
- Cómo configurar un clúster de MongoDB
- Fragmentos de MongoDB: Conceptos, Ejemplos y Tutoriales
- MongoDB Atlas: Configuración y uso de MongoDB gestionado
- Cómo ejecutar MongoDB como contenedor Docker
- Uso, gestión y requisitos de memoria de MongoDB
- Cómo utilizar Mongodump para copias de seguridad de MongoDB
- Ejemplos de Mongorestore para restaurar copias de seguridad de MongoDB
- Cómo utilizar PyMongo
- Cómo utilizar Mongoose para MongoDB y NodeJS
- Chuletas de MongoDB
- MongoDB vs Cassandra: Comparación de bases de datos NoSQL
- PostgreSQL vs MongoDB: Comparando bases de datos
- MySQL vs MongoDB: Comparando bases de datos
- Certificaciones MongoDB: Una introducción
Estas publicaciones son mías y no representan necesariamente la posición, estrategias u opinión de BMC.