La arquitectura de una El conjunto de réplicas afecta su capacidad y funcionalidad. Este documento proporciona estrategias para la implementación de conjuntos de réplicas y describe arquitecturas comunes.
La implementación estándar del set de réplicas para un sistema de producción es un set de réplicas de tres nodos. Estos conjuntos proporcionan redundancia y tolerancia a fallos. Evita la complejidad cuando sea posible, pero deja que los requisitos de tu aplicación determinen la arquitectura.
Nota
Fuera de una actualización continua, todos mongodLos miembros de un conjunto de réplicas deben usar la misma versión principal de MongoDB.
Strategies
Determina el número de nodos
Agrega nodos en un set de réplicas según estas estrategias.
Número máximo de nodos con derecho a voto
Un set de réplicas puede tener hasta 50 nodos, pero solo 7 nodos con derecho a voto. Si el set de réplicas ya tiene 7 nodos con derecho a voto, los nodos adicionales deben ser nodos sin derecho a voto.
Implementa un número impar de nodos
Asegúrate de que el set de réplicas tenga un número impar de nodos con derecho a voto. Un set de réplicas puede tener hasta 7 nodos con derecho a voto. Si tienes un número par de nodos con derecho a voto, implementa otro nodo con derecho a voto con datos o, si las restricciones lo prohíben, un árbitro.
Un árbitro no almacena una copia de los datos y requiere menos recursos. Como resultado, puedes ejecutar un árbitro en un servidor de aplicaciones u otro recurso compartido. Sin copia de los datos, es posible colocar un árbitro en entornos en los que no colocarías a otros nodos del set de réplicas. Consulta tus políticas de seguridad.
Advertencia
No implemente más de un árbitro por conjunto de réplicas.
Véase también: Preocupaciones sobre la existencia de múltiples árbitros
Considera la tolerancia a los fallos
La tolerancia a fallos de un set de réplicas es el número de nodos que pueden dejar de estar disponibles y que aún queden suficientes nodos en el set para elegir un primario. En otras palabras, es la diferencia entre el número de nodos en el set y la majority de nodos con derecho a voto necesaria para elegir un primario. Sin un primario, un set de réplicas no puede aceptar operaciones de escritura. La tolerancia a fallos es un efecto del tamaño del set de réplicas, pero la relación no es directa. Consulta la siguiente tabla:
Número de nodos | Mayoría necesaria para elegir un nuevo primario | Tolerancia a los fallos |
|---|---|---|
3 | 2 | 1 |
4 | 3 | 1 |
5 | 3 | 2 |
6 | 4 | 2 |
Si se agrega un nodo al set de réplicas no siempre se aumenta la tolerancia a los errores. Sin embargo, en estos casos, otros nodos pueden admitir funciones específicas, como copias de seguridad o reportes.
rs.status() devuelve majorityVoteCount para el set de réplicas.
Utiliza miembros ocultos y atrasados para funciones dedicadas
Agrega miembros ocultos o atrasados para admitir funciones dedicadas, como copia de seguridad o reportes.
Aplicaciones de lectura intensiva
Un set de réplicas está diseñado para ofrecer alta disponibilidad y redundancia. En la mayoría de los casos, los nodos secundarios operan con cargas similares a las del primario. No debes dirigir las lecturas a los secundarios.
Para obtener más información sobre los modos de lectura secundarios, consulta: secondary y secondaryPreferred.
Agrega capacidad antes de la demanda
Los nodos existentes de un set de réplicas deben tener capacidad de sobra para admitir la adición de un nuevo nodo. Agrega siempre nuevos nodos antes de que la demanda actual sature la capacidad del set.
Distribuye los nodos geográficamente
Para proteger tus datos en caso de una falla en el centro de datos, mantén al menos un nodo en un centro de datos alternativo. Si es posible, utiliza un número impar de centros de datos y elige una distribución de nodos que maximice la probabilidad de que, incluso con la pérdida de un centro de datos, los nodos restantes del set de réplicas puedan formar una mayoría o, como mínimo, proporcionen una copia de tus datos.
Nota
Distribuir los miembros del conjunto de réplicas entre dos centros de datos ofrece ventajas con respecto a un solo centro de datos. En una distribución entre dos centros de datos,
Si uno de los centros de datos falla, los datos siguen estando disponibles para lectura, a diferencia de una distribución de un solo centro de datos.
Si el centro de datos con una minoría de miembros deja de funcionar, el conjunto de réplicas aún puede realizar operaciones de escritura y de lectura.
Sin embargo, si el centro de datos con la mayoría de los miembros deja de funcionar, el conjunto de réplicas pasa a ser de solo lectura.
Si es posible, distribuya los miembros en al menos tres centros de datos. Para los conjuntos de réplicas de servidores de configuración (CSRS), la mejor práctica es distribuirlos en tres centros (o más, según el número de miembros). Si el costo del tercer centro de datos es prohibitivo, una posibilidad de distribución es distribuir equitativamente los miembros que contienen datos entre los dos centros y almacenar el miembro restante en la nube si la política de su empresa lo permite.
Para asegurarte de que los nodos de tu centro de datos principal sean elegidos como primarios antes que los nodos del centro de datos alternativo, establece la members[n].priority de los nodos del centro de datos alternativo para que sea menor que la de los nodos del centro de datos primario.
Para obtener más información, consulta Sets de réplicas distribuidos en dos o más centros de datos.
Dirige operaciones con conjuntos de etiquetas
Utilice conjuntos de etiquetas de conjunto de réplicas para orientar las operaciones de lectura a miembros específicos o para personalizar la preocupación de escritura para solicitar reconocimiento de miembros específicos.
Usa el registro en la bitácora para protegerte de los cortes de energía
MongoDB permite registrar en la bitácora por defecto. El registro en la bitácora protege contra la pérdida de datos si se producen interrupciones del servicio, como cortes de energía y reinicios inesperados.
Nombres de host
Importante
Para evitar actualizaciones de configuración debido a cambios en las direcciones IP, utilice nombres de host DNS en lugar de direcciones IP. Es particularmente importante usar un nombre de host DNS en lugar de una dirección IP al configurar miembros de set de réplicas o miembros de clústeres particionados.
Utiliza nombres de host en lugar de direcciones IP para configurar clústeres en un horizonte de red dividido. A partir de MongoDB 5.0, los nodos que solo están configurados con una dirección IP no pasan la validación de inicio y no se inician.
Nomenclatura del set de réplicas
Si la aplicación se conecta a más de un set de réplicas, cada set debe tener un nombre distinto. Algunos drivers agrupan las conexiones del set de réplicas por nombre del set de réplicas.
Patrones de implementación
En los siguientes documentos, se describen patrones comunes de implementación de sets de réplicas. Otros patrones son posibles y eficaces en función de los requisitos de la aplicación. Si es necesario, combina funcionalidades de cada arquitectura en tu propia implementación:
- Tres sets de réplicas de nodos
- Los sets de réplicas de tres nodos proporcionan la arquitectura mínima recomendada para un set de réplicas.
- Sets de réplicas distribuidos en dos o más centros de datos
- Los conjuntos distribuidos geográficamente incluyen nodos en varias ubicaciones para proteger contra fallas específicas de las instalaciones, como interrupciones del servicio.