sql >> Base de Datos >  >> NoSQL >> MongoDB

¿Cómo garantizar que sus clústeres de MongoDB puedan sobrevivir a las interrupciones de Amazon AWS?

Si aloja su clúster de MongoDB en la región EE. UU. Este de Amazon AWS, el último mes ha sido bastante interesante:dos interrupciones en cuatro semanas han puesto a prueba la preparación operativa de su nube implementaciones. Mientras escribo esta publicación de blog, la región de Sao Paulo también está experimentando problemas de conectividad. Un sorprendente número de bases de datos de producción no sobrevivió a la interrupción de AWS. Tuvimos la oportunidad de hablar con varios clientes de MongoDB en AWS para comprender cómo la interrupción afectó sus implementaciones. Realicé una encuesta rápida a las personas afectadas y estas son las cuatro razones principales por las que los equipos experimentaron tiempo de inactividad:

  1. Ejecutar una instancia independiente frente a un conjunto de réplicas

    Si está ejecutando un servidor MongoDB de producción, realmente no hay excusa para ejecutar una instancia independiente frente a un conjunto de réplicas. Cree un conjunto de réplicas para que pueda tener una secundaria para la conmutación por error en caso de falla principal.

  2. No distribuir réplicas entre zonas de disponibilidad

    Asegúrese de distribuir sus réplicas en diferentes zonas de disponibilidad en una región. De esta forma, si falla un solo AZ, como sucedió dos veces este mes, los servidores restantes tomarán el control y tendrá un clúster en funcionamiento. Si su región tiene solo dos AZ, coloque su árbitro en una región diferente. Sin embargo, esto no lo ayudará si toda la región se cae. Si desea sobrevivir a la falla de toda la región de AWS, deberá distribuir su conjunto de réplicas en diferentes regiones.

  3. No distribuir sus front-end o servidores de aplicaciones entre zonas de disponibilidad

    Asegúrese de distribuir sus interfaces en diferentes zonas de disponibilidad. No tiene sentido tener su base de datos en funcionamiento si su front-end no funciona. Si tiene problemas de costos, puede mantener un front-end actualizado "detenido" en cada AZ que puede activar en caso de necesidad. Otra opción es tener frontales de menor tamaño.

  4. Conéctese al conjunto de réplicas frente a un solo servidor en su cadena de conexión

    Asegúrese de conectarse al conjunto de réplicas en lugar de a un solo servidor. La sintaxis es diferente para diferentes controladores, pero consulte la documentación de su controlador para asegurarse de que está utilizando la sintaxis correcta para conectarse al conjunto de réplicas en lugar de a un solo servidor. De esta manera, si hay una conmutación por error, el controlador MongoDB hará lo correcto y se conectará al nuevo primario.

En ScaleGrid, automatizamos todos los aspectos operativos de su implementación para que pueda concentrarse en su aplicación y no preocuparse por las operaciones. Cuando crea un conjunto de réplicas de MongoDB con ScaleGrid, distribuimos automáticamente las réplicas entre las zonas de disponibilidad. Debido a esta distribución, todos nuestros clientes han podido navegar de forma segura por el problema del tiempo de inactividad de AWS. Si está interesado en una lectura más detallada sobre los aspectos operativos de MongoDB, puede leer mi publicación de blog detallada anterior:10 preguntas para hacer y responder al alojar MongoDB en AWS