%3A%203%20r%C3%A9plicas%20frente%20a%202%20r%C3%A9plicas%20%2B%20Arbiter.png)
Tenemos una base de datos Mongo bastante grande ejecutándose en AWS. Actualmente, estamos ejecutando un conjunto de réplicas con 3 instancias. Cada instancia tiene 5 TB de almacenamiento EBS adjunto. Esto equivale a más de $1000/mes por instancia. Además de esto, tenemos un entorno de producción y de preparación (próximamente habrá un tercer entorno de "desarrollo"). Además, estos costos pueden dispararse en el futuro cuando pasemos a un entorno fragmentado.
La pregunta es ¿qué tan necesarias son 3 réplicas en un entorno de AWS?
Ok ok ok, ya sé que la respuesta es "depende". Lo que estoy buscando es algún consejo sobre cómo sopesar mejor las compensaciones. Por ejemplo...
Teniendo en cuenta que cada volumen de EBS ya tiene triple redundancia incorporada y que es bastante sencillo restaurar desde una copia de seguridad, ¿cómo mido la tolerancia a fallas adicional de 2 frente a 3 réplicas?
¿Existen consideraciones adicionales además de la redundancia al considerar las compensaciones?
¿Alguien tiene experiencia (buena o mala) ejecutando solo 2 réplicas + un árbitro?
Respuesta1
- Teniendo en cuenta que cada volumen de EBS ya tiene triple redundancia incorporada y que es bastante sencillo restaurar desde una copia de seguridad, ¿cómo mido la tolerancia a fallas adicional de 2 frente a 3 réplicas?
En lo que respecta a MongoDB, las consideraciones clave con solo dos miembros que contienen datos en un conjunto de réplicas de tres nodos son que si uno de esos miembros que contienen datos no está disponible por algún motivo (mantenimiento planificado o falla no planificada):
- ya no tiene replicación activa (solo queda un miembro portador de datos)
- su implementación ya no puede reconocer problemas de escritura superiores a
w:1(por ejemplo:w:majorityow:2)
Esta configuración tiene alta disponibilidad en términos de mantenimiento/elección de un miembro principal en caso de que falle un solo miembro, pero el árbitro compromete la redundancia de datos si uno de los miembros portadores de datos no está disponible. Suponiendo que tenga un tiempo razonable para restaurar sus copias de seguridad de EBS (y confíe en la redundancia de EBS), este puede ser un compromiso aceptable para su caso de uso.
- ¿Existen consideraciones adicionales además de la redundancia al considerar las compensaciones?
Si su código usa MongoDBescribe preocupacionessuperior al valor predeterminado ( w:1), querrá agregar unwtimeoutvalor. Si no especifica la wtimeoutopción y el nivel de preocupación de escritura es inalcanzable, las operaciones de escritura se bloquearán indefinidamente.
Las garantías de AWS sobre infraestructura redundante generalmente solo se extienden a fallas en múltiples zonas de disponibilidad, por lo que para maximizar la disponibilidad también debe implementar los miembros del conjunto de réplicas en diferentes zonas de disponibilidad.
- ¿Alguien tiene experiencia (buena o mala) ejecutando solo 2 réplicas + un árbitro?
Definitivamente he visto malos resultados en los que los usuarios no tuvieron en cuenta los puntos anteriores (particularmente teniendo en cuenta las preocupaciones de escritura y los tiempos de espera). Si planifica (y prueba) teniendo en cuenta esas advertencias, debería poder aterrizar en el lado de la buena experiencia.
Además de esto, tenemos un entorno de producción y de preparación (próximamente habrá un tercer entorno de "desarrollo")
Definitivamente existe un argumento para tener entornos de desarrollo y preparación similares a los de producción, pero un ahorro de costos típico sería implementar entornos de especificaciones más bajas para el desarrollo con menos conmutación por error que la producción. Para la preparación, es posible que desee implementar entornos con especificaciones más bajas pero tener una configuración similar para poder probar escenarios de conmutación por error realistas. Si está realizando pruebas de rendimiento o de carga en entornos de prueba, deben contar con las mismas especificaciones que en producción.