Realización de operaciones de recuperación ante desastres | Amazon Neptune

Una base de datos global de Neptune proporciona capacidades de conmutación por error más completas que un clúster de base de datos de Neptune independiente. Al utilizar una base de datos global, puede planificar y recuperarse de desastres con bastante rapidez. La recuperación ante desastres generalmente se evalúa mediante la evaluación del objetivo de tiempo de recuperación (RTO) y del objetivo de punto de recuperación (): RPO

• Objetivo de tiempo de recuperación (RTO): es la rapidez con la que un sistema vuelve a funcionar después de un desastre. En otras palabras, mide el tiempo de inactividadRTO. Para una base de datos global de Neptune, RTO puede ser del orden de minutos.

• Objetivo del punto de recuperación (RPO): cantidad de tiempo durante el cual se pierden los datos. En el caso de una base de datos global de Neptune, normalmente RPO se mide en segundos (consulteEjecución de la conmutación por error planificada administrada para bases de datos globales de Neptune).

Para una base de datos global de Neptune, hay dos enfoques diferentes para la conmutación por error:

• Detach-and-promote (recuperación manual no planificada): para recuperarse de una interrupción imprevista o para realizar pruebas de recuperación ante desastres (pruebas de DR), realice una operación interregional detach-and-promote en uno de los clústeres de bases de datos secundarios de la base de datos global. RTOPara este proceso manual, el proceso depende de la rapidez con la que pueda realizar las tareas enumeradas en. Desconexión y promoción Por lo general, RPO es un número de segundos, pero depende del retraso en la replicación del almacenamiento en la red en el momento del error.

• Conmutación por error planificada administrada: este enfoque está diseñado para el mantenimiento operativo y otros procedimientos operativos planificados, como la reubicación del clúster de base de datos principal de la base de datos global en una de las regiones secundarias. Como este proceso sincroniza los clústeres de bases de datos secundarios con los principales antes de realizar cualquier otro cambio, RPO es prácticamente 0 (es decir, no se pierden datos). Consulte Ejecución de la conmutación por error planificada administrada para bases de datos globales de Neptune.

Detach-and-promote una base de datos global de Neptune en caso de una interrupción imprevista

En la muy poco frecuente situación en la que la base de datos global de Neptuno sufre una interrupción inesperada en su nodo principal Región de AWS, el clúster de base de datos Neptune principal y su nodo de escritura dejan de estar disponibles y la replicación entre el clúster principal y los secundarios cesa. Para minimizar tanto el tiempo de inactividad (RTO) como la pérdida de datos () resultantes, realice rápidamente una operación RPO detach-and-promote interregional para reconstruir la base de datos global.

sugerencia

Es buena idea entender este proceso antes de usarlo y tener un plan para proceder rápidamente ante el primer indicio de que se produzca un problema en toda la región.

• Utiliza Amazon CloudWatch con regularidad para realizar un seguimiento de los tiempos de retraso de los clústeres secundarios, de modo que puedas identificar la región secundaria con el menor tiempo de retraso en caso de que necesites realizar una conmutación por error.

• Asegúrese de probar el plan para verificar que sus procedimientos sean completos y precisos.

• Utilice un entorno simulado para asegurarse de que el personal esté capacitado y preparado para realizar una conmutación por error de recuperación de desastres rápidamente en caso de que sea necesaria.

Para conmutar por error a un clúster secundario después de una interrupción no planificada en la región principal

1. Deje de realizar consultas de mutación y otras operaciones de escritura en el clúster de base de datos principal.

2. Identifique un clúster de base de datos en un clúster secundario Región de AWS para usarlo como el nuevo clúster de base de datos principal de la base de datos global. Si la base de datos global tiene dos o varias Regiones de AWS secundarias, elija el clúster secundario que tenga el menor tiempo de retraso.

3. Desconecte el clúster de base de datos secundario que haya elegido de la base de datos global de Neptune.

   La eliminación de un clúster de base de datos secundario de una base de datos global detiene inmediatamente la replicación de datos del principal al secundario y la promueve a un clúster de base de datos independiente con capacidades completas de lectura/escritura. El resto de clústeres secundarios de la base de datos global seguirán estando disponibles y podrán aceptar llamadas de lectura de la aplicación.

   Antes de volver a crear la base de datos global de Neptune, también tendrá que desconectar los demás clústeres secundarios para evitar incoherencias de datos entre los clústeres (consulte Eliminación de un clúster).

4. Vuelva a configurar la aplicación para enviar todas las operaciones de escritura al clúster de base de datos de Neptune independiente que ha elegido para convertirse en el nuevo clúster principal con su nuevo punto de conexión. Si ha aceptado los nombres predeterminados al crear la base de datos global de Neptune, puede cambiar el punto de conexión. Para ello, elimine -ro de la cadena del punto de conexión del clúster en la aplicación.

   Por ejemplo, el punto de conexión del clúster secundario my-global.cluster-ro-aaaaaabbbbbb.us-west-1.neptune.amazonaws.com se convierte en my-global.cluster-aaaaaabbbbbb.us-west-1.neptune.amazonaws.com cuando ese clúster se desconecta de la base de datos global.

   Este clúster de base de datos de Neptune se convierte en el clúster principal de una nueva base de datos global de Neptune cuando, en el siguiente paso, comienza a añadirle regiones.

5. Agregue un Región de AWS al clúster de base de datos. Al hacerlo, comienza el proceso de reproducción de clúster principal a secundario. Consulte Añadir regiones de bases de datos globales secundarias a una región principal en Amazon Neptune .

6. Agregue más Regiones de AWS según sea necesario para recrear la topología necesaria para respaldar su aplicación.

Asegúrese de que las escrituras de la aplicación se envíen al clúster de base de datos de Neptune correcto antes, durante y después de realizar estos cambios. De este modo, se evitan incoherencias con respecto a los datos entre los clústeres de la base de datos global de Neptune (problemas del tipo cerebro dividido).

Ejecución de la conmutación por error planificada administrada para bases de datos globales de Neptune

La conmutación por error planificada gestionada le permite reubicar el clúster principal de su base de datos global de Neptune en un lugar diferente Región de AWS cuando lo desee. Algunas organizaciones querrán rotar periódicamente las ubicaciones de sus clústeres principales.

nota

La conmutación por error planificada administrada está diseñada para utilizarse en una base de datos global de Neptune en buen estado. Para recuperarse de una interrupción no planificada o para realizar pruebas de recuperación de desastres (DR), siga el proceso de desconectar y promover.

Durante una conmutación por error planificada administrada, el clúster principal se conmuta por error a la región secundaria que elija mientras se mantiene la topología de replicación existente de la base de datos global. Antes de que comience el proceso de conmutación por error planificada administrada, la base de datos global sincroniza todos los clústeres secundarios con su clúster principal. Después de asegurarse de que todos los clústeres están sincronizados, comienza la conmutación por error administrada. El clúster de base de datos de la región principal se convierte en solo de lectura, y el clúster secundario elegido promueve una de sus instancias de solo lectura al estado de escritor completo, lo que permite que el clúster asuma el rol de clúster principal. Dado que todos los clústeres secundarios se sincronizaron con el principal al principio del proceso, el nuevo clúster principal continúa las operaciones para la base de datos global sin perder ningún dato. La base de datos no estará disponible durante un breve periodo, mientras los clústeres principales y secundarios seleccionados asumen nuevos roles.

Para optimizar la disponibilidad de las aplicaciones, realice la conmutación por error durante los horarios menos concurridos, en un momento en que las escrituras en el clúster principal de base de datos sean mínimas. Asimismo, siga estos pasos antes de iniciar la conmutación por error:

• Desconecte las aplicaciones siempre que sea posible para reducir las escrituras en el clúster principal.

• Compruebe los tiempos de retraso de todos los clústeres de base de datos secundarios de Neptune en la base de datos global y elija el secundario con el menor tiempo de retraso total para que se convierta en el principal. Usa Amazon CloudWatch para ver la NeptuneGlobalDBProgressLag métrica de todos los secundarios. Esta métrica le indica qué tan lejos (en milisegundos) está un clúster secundario con respecto al clúster principal de base de datos. Su valor es directamente proporcional al tiempo que tardará Neptune en completar la conmutación por error. Dicho de otro modo, cuanto mayor sea el valor de retraso, más extensa será la interrupción por conmutación por error, así que elija el clúster secundario con el menor retraso. Para obtener más información, consulte Métricas de Neptune CloudWatch .

Durante una conmutación por error planificada administrada, el clúster de base de datos secundario elegido se promueve a su nuevo rol de clúster principal, pero no hereda la configuración completa del clúster principal de base de datos. Una falta de coincidencia en la configuración puede provocar problemas de rendimiento, incompatibilidades de carga de trabajo y otros comportamientos anómalos. Para evitar estos problemas, solucione los siguientes tipos de diferencias de configuración entre los clústeres de bases de datos globales antes de la conmutación por error:

• Configurar los parámetros del nuevo clúster principal para que coincidan con el principal actual.

• Configurar alarmas, opciones y herramientas de monitorización: configure el clúster de base de datos que será el nuevo clúster principal con la misma capacidad de registro, alarmas, etc. que tiene el principal actual.

• Configure las integraciones con otros AWS servicios: si su base de datos global de Neptune se integra AWS con servicios AWS Identity and Access Management como IAM (), Amazon S3 AWS Lambda o, asegúrese de que estén configurados según sea necesario para integrarse con el nuevo clúster de base de datos principal.

Cuando finalice el proceso de conmutación por error y el clúster de base de datos promovido esté preparado para gestionar las operaciones de escritura en la base de datos global, asegúrese de cambiar las aplicaciones para que utilicen el nuevo punto de conexión del nuevo clúster principal.

Utilizándolo AWS CLI para iniciar una conmutación por error planificada y gestionada

Utilice el failover-global-clusterCLIcomando (que envuelve el FailoverGlobalClusterAPI) para realizar una conmutación por error de su base de datos global de Neptune:

aws neptune failover-global-cluster \
  --region (the region where the primary cluster is located) \
  --global-cluster-identifier (global database ID) \
  --target-db-cluster-identifier (the ARN of the secondary DB cluster to promote)

nota

No failover-global-cluster API está disponible en la vista previa. Formará parte de la versión de GA.