Es fundamental que las empresas planifiquen la recuperación ante desastres. Recomendamos encarecidamente elaborar un plan integral de recuperación ante desastres (DR) que incluya elementos como:
Su objetivo de punto de recuperación designado (RPO)
Su objetivo de tiempo de recuperación designado (RTO)
Procesos automatizados que facilitan la alineación con estos objetivos
Utilice las recomendaciones de esta página para prepararse y responder ante desastres.
Para obtener más información sobre las configuraciones proactivas de alta disponibilidad que pueden ayudar con la recuperación ante desastres, consulte Recomendaciones para Atlas Alta Disponibilidad.
Funciones para Atlas Disaster Recovery
Para obtener más información sobre las características de Atlas que admiten la recuperación ante desastres, consulte las siguientes páginas en el Centro de arquitectura de Atlas:
Recomendaciones para la recuperación ante desastres de Atlas
Utilice las siguientes recomendaciones de recuperación ante desastres para crear una Plan de recuperación ante desastres para su organización. Estas recomendaciones proporcionan información sobre los pasos a seguir en caso de desastre.
Es imperativo que pruebes regularmente los planes en esta sección (idealmente cada trimestre, pero al menos cada semestre). Realizar pruebas frecuentes ayuda al equipo de gestión de base de datos Empresarial (EDM) a estar preparado para responder ante desastres, además de ayudar a mantener actualizadas las instrucciones.
Algunas pruebas de recuperación ante desastres podrían requerir acciones que los usuarios de EDM no pueden realizar. En estos casos, abra un caso de soporte para realizar interrupciones artificiales al menos una semana antes de la fecha prevista para la prueba.
El siguiente diagrama compara diferentes escenarios de recuperación ante desastres y configuraciones de implementación. La tabla muestra las ventajas relativas del Objetivo de Tiempo de Recuperación (RTO) y el Objetivo de Punto de Recuperación (RPO) frente a la complejidad y el coste de la implementación para cada configuración. Tenga en cuenta que la selección de conjuntos de réplicas (conmutación por error automática) no produce pérdida de datos, mientras que la recuperación a partir de copias de seguridad podría implicar cierta pérdida de datos, dependiendo de la frecuencia de las copias de seguridad. Un "fallo del plano de control" se refiere a problemas con la infraestructura de administración de Atlas, no con los nodos de datos.
Figura 1. Complejidad de la configuración de recuperación ante desastres y compensaciones RTO/RPO.
Cada proveedor de nube en el que puede implementar clústeres Atlas proporciona redundancia de datos predeterminada que ayuda a mitigar cualquier interrupción:
AWS almacena objetos en varios dispositivos en un mínimo de tres Zonas de Disponibilidad en una Región de AWS.
Microsoft Azure utiliza almacenamiento redundante local (LRS) que replica sus datos tres veces dentro de un único centro de datos en la región seleccionada.
Google Cloud distribuye tus datos a través de múltiples zonas en la región de copia de seguridad.
Para mejorar tu recuperación ante desastres, puedes configurar Atlas para crear copias automáticas de tus snapshots y oplogs en otras regiones. Esto garantiza que, incluso si la región primaria experimenta una Interrupción del servicio, el clúster pueda restaurar usando copias de snapshots almacenadas en otras regiones.
Atlas optimiza la velocidad de restauración seleccionando la opción más eficiente según la disponibilidad regional, utilizando instantáneas copiadas si se restaura a una región donde existen dichas copias. Además, si la instantánea original es inaccesible debido a una interrupción regional, Atlas restaurará utilizando la copia de instantánea más cercana disponible, lo que minimiza el tiempo de inactividad y mejora la resiliencia de la recuperación. Para obtener más información, consulte Exportar instantánea de copia de seguridad en la nube.
Las implementaciones multirregionales y multinube ofrecen capacidades mejoradas de recuperación ante desastres al distribuir los nodos de su clúster entre diferentes ubicaciones geográficas o proveedores de nube. Esta distribución garantiza que, si una región o un proveedor de nube sufre una interrupción, su aplicación pueda seguir funcionando utilizando nodos en ubicaciones no afectadas.
Al configurar implementaciones multi-región o multi-nube, asegúrese de que su estrategia de respaldo tenga en cuenta la naturaleza distribuida de su implementación, incluido el establecimiento de períodos de retención de respaldo adecuados según sus requisitos de recuperación específicos.
Todas las recomendaciones del paradigma de implementación
Las siguientes recomendaciones se aplican a todos los paradigmas de implementación.
Esta sección cubre los siguientes procedimientos de recuperación ante desastres:
Interrupción de un solo nodo
Si un solo nodo en su conjunto de réplicas falla debido a una interrupción regional parcial, su implementación debería seguir estando disponible, suponiendo que haya seguido las mejores prácticas. Si está leyendo desde secundarios, podría experimentar un rendimiento degradado o posibles interrupciones del servicio en el evento de que un secundario falle, debido a la mayor carga en el clúster que queda sub-provisionado.
Puede probar una interrupción del nodo principal en Atlas mediante la función Probar conmutación por error principal de la interfaz de usuario de Atlas o el punto final de la API de administración de Atlas de Probar conmutación por error.
Interrupción regional
En caso de una interrupción regional, los clústeres multirregionales realizarán automáticamente una elección e identificarán un nuevo nodo principal si es necesario. Este cambio de topología se comunicará automáticamente a la aplicación, lo que le permitirá tomar las medidas correctivas necesarias. Para mantener la disponibilidad de la aplicación en caso de una interrupción regional, esta también debe implementarse con una topología multirregional. Este requisito se extiende a cualquier servicio de terceros con el que se integre la aplicación. Para obtener más información, consulte el Paradigma de Implementación Multirregional.
Si una interrupción en una sola región o en varias regiones degrada el estado de su clúster, siga estos pasos:
Determinar qué regiones es poco probable que se vean afectadas por la interrupción actual
Dependiendo de la causa de la interrupción, es posible que próximamente otras regiones también experimenten interrupciones no programadas. Por ejemplo, si las interrupciones se debieron a un desastre natural en la costa este de Estados Unidos, debería evitar estas regiones por si surgen problemas adicionales.
Añade nodos a las regiones que identificaste
Agregue la cantidad necesaria de nodos para un estado normal en todas las regiones que probablemente no se vean afectadas por la causa de la interrupción.
Para reconfigurar un conjunto de réplicas durante una interrupción agregando regiones o nodos, consulte Reconfigurar un conjunto de réplicas durante una interrupción regional.
Puede probar una interrupción en una región en Atlas mediante la función Simular interrupción de la interfaz de usuario de Atlas o el punto final de la API de administración de Atlas Iniciar una simulación de interrupción.
Interrupción del proveedor de la nube
Con clústeres multinube, puede seleccionar nodos seleccionables entre proveedores de nube para mantener una alta disponibilidad. Si el proveedor donde está implementado su nodo principal deja de estar disponible, Atlas selecciona automáticamente nuevos nodos principales para garantizar la continuidad del funcionamiento. Por ejemplo, puede crear nodos seleccionables en AWS, Google Cloud y Microsoft Azure para garantizar que, si un proveedor de nube sufre una interrupción, un nodo seleccionable de otro proveedor pueda asumir automáticamente el control como nodo principal de su clúster. Para obtener más información, consulte Paradigma de Implementación Multinube.
La mayoría de los clústeres Atlas multirregionales se recuperan automáticamente de una interrupción en una sola región. Para obtener más información, consulte la sección Alta disponibilidad y la página Implementación multirregional. En caso de que las interrupciones regionales hayan afectado a la mayoría de los nodos, debe determinar cuántos nodos más necesita agregar para que la mayoría de los nodos funcionen correctamente.
En el caso altamente improbable de que un proveedor de nube completo no esté disponible, siga estos pasos para volver a poner en línea su implementación:
Identifique el proveedor de nube alternativo en el que desea implementar su nuevo clúster
Para obtener una lista de proveedores de nube e información,consulte Proveedores de nube.
Si almacena copias de seguridad en varios proveedores de nube, como una interrupción del proveedor de nube implica que todas las copias de seguridad almacenadas en el proveedor de nube principal no estarán necesariamente disponibles, busque la instantánea disponible más reciente tomada del clúster antes de que comenzara la interrupción.
Para saber cómo ver sus instantáneas de respaldo, consulte Ver10instantáneas de respaldo M +.
Restaurar la instantánea más reciente del paso anterior en el nuevo clúster
Para saber cómo restaurar su instantánea,consulte Restaurar su clúster.
Cambie cualquier aplicación que se conecte al clúster antiguo al clúster recién creado
Para encontrar la nueva cadena de conexión,consulte Conectarse mediante bibliotecas de cliente. Revise la pila de aplicaciones, ya que probablemente necesite volver a implementarla en el nuevo proveedor de nube.
Interrupción de Atlas
En el improbable caso de que el plano de control de Atlas y la interfaz de usuario de Atlas no estén disponibles, su clúster seguirá disponible y accesible. Para obtener más información, consulte Confiabilidad de la plataforma. Abra un ticket de soporte prioritario para investigar esto con más detalle.
Problemas de capacidad de recursos
Los problemas de capacidad de los recursos computacionales (como espacio en disco, RAM o CPU) pueden deberse a una planificación deficiente o a un tráfico inesperado de la base de datos. Este comportamiento podría no ser consecuencia de un desastre.
Si un recurso computacional alcanza la cantidad máxima asignada y provoca un desastre, siga estos pasos:
Identifique qué recurso computacional está maximizado mediante el Panel de rendimiento en tiempo real o las métricas Atlas
Para ver la utilización de sus recursos en la interfaz de usuario de Atlas, consulte Supervisar el rendimiento en tiempo real.
Para ver las métricas con la API de administración de Atlas, consulte Supervisión y registros.
Asignar los recursos necesarios
Tenga en cuenta que Atlas realizará este cambio de manera progresiva, por lo que no debería tener un impacto importante en sus aplicaciones.
Para saber cómo asignar más recursos,consulte Editar un clúster.
Falla de recursos
Importante
Esta es una solución temporal diseñada para reducir el tiempo de inactividad general del sistema. Una vez resuelto el problema subyacente, fusione los datos del clúster recién creado con el clúster original y redirija todas las aplicaciones a este.
Si un recurso computacional falla y provoca que su clúster no esté disponible, siga estos pasos:
Restaura la copia de seguridad más reciente en el clúster recién creado
Para saber cómo restaurar su instantánea,consulte Restaurar su clúster.
Eliminación de datos de producción
Los datos de producción podrían eliminarse accidentalmente debido a un error humano o a un fallo en la aplicación basada en la base de datos. Si el clúster se eliminara accidentalmente, Atlas podría conservar el volumen temporalmente.
Si se ha eliminado el contenido de una colección o base de datos, siga estos pasos para restaurar sus datos:
Crea una copia del estado actual de la colección o base de datos, si contiene algún dato
Puede utilizar mongoexport para crear una copia.
Restaurar sus datos
Si la eliminación ocurrió dentro de las últimas 72 horas y configuró una copia de seguridad continua, utilice la restauración de punto en el tiempo (PIT) para restaurar desde el punto en el tiempo justo antes de que ocurriera la eliminación.
Si la eliminación no ocurrió en las últimas 72 horas, restaure en el clúster la copia de seguridad más reciente anterior a la eliminación.
Para obtener más información, consulte Restaurar su clúster.
Si creó una copia de sus datos, importe los nuevos datos que exportó
Puede utilizar mongoimport con el modo upsert para importar sus datos y asegurarse de que cualquier dato que se haya modificado o agregado se refleje correctamente en la colección o base de datos.
Falla del controlador
Si un controlador falla, siga estos pasos:
Identifique la versión del controlador adecuada para resolver el problema
Si usa un controlador desactualizado, verifique si actualizar a una versión más reciente soluciona el problema. La mayoría de los problemas de los controladores se solucionan en las versiones más recientes.
Si recientemente actualizó su controlador y sospecha que la nueva versión introdujo el problema, considere volver a la versión funcional anterior.
Evaluar si se requieren otros cambios para pasar a la versión del controlador de destino
Esto podría incluir cambios en el código de la aplicación o en las consultas. Por ejemplo, podría haber cambios importantes si se cambia de una versión principal a otra, o nuevas funciones disponibles si se actualiza.
Corrupción de datos
Importante
Esta es una solución temporal diseñada para reducir el tiempo de inactividad general del sistema. Una vez resuelto el problema subyacente, fusione los datos del clúster recién creado con el clúster original y redirija todas las aplicaciones a este.
Si sus datos subyacentes se corrompen, siga estos pasos:
Restaura la copia de seguridad más reciente en el clúster recién creado
Para saber cómo restaurar su instantánea,consulte Restaurar su clúster.