MongoDB — popular sistema de base de datos orientado a documentos que no requiere desarrollar y crear esquemas de base de datos.
Ampliamente utilizado en el desarrollo de aplicaciones web y también para cualquier tipo de software donde NoSQL es más efectivo y útil que la base de datos relacional.
El único servidor de base de datos suele ser suficiente para el desarrollo de una aplicación o para probarla.
Se recomienda antes de comenzar a usar una aplicación en un entorno de producción para pensar en los posibles riesgos: ¿qué puede pasar si los datos se almacenan en el único servidor de base de datos?
Si los datos no son críticos (p. ej., para fines de caché), una aplicación seguirá funcionando sin estos datos, el tiempo necesario para restaurar la base de datos (en caso de falla) es aceptable; entonces, el único servidor es suficiente.
De lo contrario, si los datos se consideran críticos, su pérdida o inaccesibilidad afecta a una aplicación (por lo tanto, un servicio que su clireciben) — en este caso, la recomendación es utilizar un clúster para el almacenamiento de datos.
MongoDB permite construir dos tipos de clúster:
- Conjunto de réplicas: un grupo de servidores que almacenan los mismos datos, la accesibilidad de los datos se garantiza mediante la replicación.
- Clúster fragmentado: distribuir partes de los datos entre varios servidores significa escalado horizontal.
A continuación se muestra el proceso de configuración de un clúster de conjunto de réplicas.
Conjunto de réplicas: roles de servidores.
El clúster de MongoDB requiere tres servidores (nodos) como mínimo (o un número impar):
- Servidor primario: maneja todas las solicitudes de lectura/escritura. Todas las operaciones que modifican los datos se almacenan en una colección especial denominada "oplog" (registro de operaciones); las entradas de esta colección se utilizan para realizar la replicación.
- Servidor secundario (mínimo dos servidores): replica la recopilación de registros de operación y aplica cambios a los datos almacenados. Este proceso garantiza que los datos sean idénticos en todos los servidores.
Esquema común:
Conjunto de réplicas: configuración.
Detalles de los servidores utilizados:
- Servidor primario: nombre — servidor1, IP 10.20.30.10
- Servidor secundario: nombre — server2, IP 10.20.30.20
- Servidor secundario: nombre — server3, IP 10.20.30.30
Reemplace los nombres y las direcciones IP con los suyos.
Pasos para todos los servidores antes de continuar:
- Instale MongoDB.
- Configurar firewall si está en uso para permitir paquetes de entrada/salida en el puerto 27017.
- Establecer resolución de nombres de servidores: si no DNS servidor está en uso, entonces podría hacerse agregando entradas al archivo /etc/hosts como esta:
10.20.30.10 server1.domain.local server1
10.20.30.20 server2.domain.local server2
10.20.30.30 server3.domain.local server3Nota importante: ¡Todos los comandos de configuración a continuación deben contener solo nombres de servidores! A partir de la versión 5.0, no está permitido usar direcciones IP: MongoDB verifica la configuración y no se iniciará si hay direcciones IP.
Pasos para la configuración del clúster:
1. Inicie MongoDB en todos los servidores:
mongod --replSet “rs0” –bind_ip localhost,server_name“rs0”: nombre de la réplica (elija otro nombre si es necesario)
server_name — nombre de un servidor en el que se inicia MongoDB.
2. En el servidor principal, inicie el shell de MongoDB llamado "mongo" (usando su credencial en lugar del nombre de usuario y la contraseña):
mongo -u username -p password3. Inicialice la replicación y agregue todos los servidores al clúster:
rs.initiate( {
_id: “rs0”,
members: [
{ _id: 0, host: “server1.domain.local:27017” },
{ _id: 1, host: “server2.domain.local:27017” },
{ _id: 2, host: “server3.domain.local:27017” },
]
})Este paso debe realizarse solo en el servidor principal, no es necesario repetirlo en el secundario.
4. Verifique la configuración de replicación con el comando "rs.conf ()": la salida de este comando muestra parametros de cada servidor. Para el servidor primario debería verse así:
{
"_id" : "rs0",
"version" : 1,
"protocolVersion" : NumberLong(1),
"members" : [
{
"_id" : 0,
"host" : "server1. domain.local:27017",
"arbiterOnly" : false,
"buildIndexes" : true,
"hidden" : false,
"priority" : 1,
"tags" : {
},
"slaveDelay" : NumberLong(0),
"votes" : 1
},5. Se puede notar que cada servidor tiene una prioridad predeterminada: 1: la cadena "prioridad: 1".
El valor de prioridad se utiliza en la elección: el valor más bajo significa la posibilidad más alta de convertirse en un nuevo servidor principal.
Se podría definir previamente qué servidor secundario exactamente se elegirá como nuevo servidor principal mediante estos comandos:
conf = rs.conf()
conf[‘members’][0].priority = 1
conf[‘members’][1].priority = 2
conf[‘members’][2].priority = 3
rs.reconfig(conf)Por tanto,
- server1 siempre es primario.
- server2 será el nuevo primario si server1 es inaccesible.
- server3 seguirá siendo el único y principal servidor en el clúster si tanto server1 como server2 son inaccesibles.
6. Verifique el estado de la replicación con el comando “rs.status()”. La presencia de todos los servidores debe verificarse en la salida, así como su estado (la cadena "stateStr").
Ejemplo para el servidor principal:
"members" : [
{
"_id" : 0,
"name" : "server1:27017",
"health" : 1,
"state" : 1,
"stateStr" : "PRIMARY",
"uptime" : 87986,
"optime" : {
"ts" : Timestamp(1526936047, 1),
"t" : NumberLong(1)
},
"optimeDate" : ISODate("2023-03-29T12:54:07Z"),
"electionTime" : Timestamp(1526848104, 1),
"electionDate" : ISODate("2018-03-29T12:28:24Z"),
"configVersion" : 3,
"self" : true
},El valor de "stateStr" es "PRIMARIO", significa que el servidor1 es de hecho el principal.
Para el servidor secundario2:
{
"_id" : 0,
"name" : "server2:27017",
"health" : 1,
"state" : 2,
"stateStr" : "SECONDARY",
"uptime" : 97453,
"optime" : {
"ts" : Timestamp(1526936047, 1),
"t" : NumberLong(1)
},
"optimeDate" : ISODate("2023-03-29T12:54:07Z"),
"electionTime" : Timestamp(1526848104, 1),
"electionDate" : ISODate("2018-03-29T12:28:24Z"),
"configVersion" : 3,
"self" : true
},"stateStr" es "SECUNDARIO", significa que server2 es parte del clúster y secundario como se esperaba. Una salida similar debería ser para server3.
De manera predeterminada, los servidores verifican el estado (salud) entre sí cada 10 segundos (el período de tiempo se puede cambiar).
Como se señaló anteriormente, si no se puede acceder al servidor principal, se inicia el proceso de elección.
De acuerdo con los valores de prioridad, el servidor 2 se convertirá en un nuevo primario; se puede ver en la salida "rs.status ()": "stateStr" cambiará de "SECUNDARIO" a "PRIMARIO".
Para server1, "stateStr" será "no accesible/en buen estado" al mismo tiempo.
Una vez que el servidor 1 vuelve a estar disponible en el clúster, los datos se replican desde el servidor 2 y después de que se inicia esa nueva elección, el servidor 1 se convierte en el principal debido a su prioridad.
El clúster configurado también permite realizar el mantenimiento en cualquier servidor sin impacto en una aplicación porque los datos son accesibles desde otro servidor.
Conclusión
Estos pasos son suficientes para configurar un clúster básico de "conjunto de réplicas".
Se podría usar una configuración más compleja, incluida la combination de ambos tipos de grupos.
Los ejemplos de este tipo de configuraciones se discutirán en los siguientes artículos.
