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
Evita implementar más de un árbitro en un set de réplicas. Consulta Preocupaciones con múltiples árbitros.
Agregar un árbitro a un set de réplicas existente:
Por lo general, si hay dos o menos miembros que contengan datos en el set de réplicas, es posible que primero debas configurar el nivel de confirmación de escritura a nivel de clúster para el set de réplicas.
Consulte el nivel de confirmación de escritura para todo el clúster para obtener más información sobre por qué podría necesitar establecer el nivel de confirmación de escritura para todo el clúster.
No necesitas cambiar el nivel de confirmación de escritura a nivel de clúster antes de iniciar un nuevo set de réplicas con un árbitro.
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.
Si tienes una aplicación de lectura intensiva, considera la posibilidad de utilizar Mongosync para replicar los datos en otro clúster para su lectura.
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
Para las implementaciones de producción, recomendamos desplegar el servidor de configuración y los Sets de réplicas de fragmentos en al menos tres centros de datos. Esta configuración proporciona alta disponibilidad en caso de que un solo centro de datos falle.
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
Utiliza conjuntos de etiquetas del set de réplicas para dirigir las operaciones de lectura a nodos específicos o para personalizar el nivel de confirmación de escritura (write concern) y solicitar reconocimiento de nodos 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.