Uso de la transición o la conmutación por error en la base de datos global de Amazon Aurora

La característica de base de datos global de Aurora proporciona más protección de continuidad empresarial y recuperación ante desastres (BCDR) que la alta disponibilidad estándar proporcionada por un clúster de bases de datos de Aurora en una sola Región de AWS. Al utilizar una base de datos global de Aurora, puede planificar y recuperarse más rápido de desastres regionales o interrupciones totales del nivel de servicio inusuales y no previstos.

Puede consultar las siguientes directrices y procedimientos para planificar, probar e implementar su estrategia de BCDR mediante la característica de base de datos global de Aurora.

Planificación de la continuidad empresarial y la recuperación ante desastres

Para planificar su estrategia de continuidad empresarial y recuperación ante desastres, resulta útil comprender la siguiente terminología del sector y su relación con las características de la base de datos global de Aurora.

La recuperación de desastres suele obedecer a los dos objetivos empresariales siguientes:

Realizar una transición o una conmutación por error con la base de datos global de Aurora implica promocionar un clúster de base de datos secundario al clúster de base de datos principal. El término “interrupción regional” se utiliza a menudo para describir una variedad de situaciones de error. El peor de los casos podría ser una interrupción generalizada provocada por un evento catastrófico que afecte a cientos de kilómetros cuadrados. Sin embargo, la mayoría de las interrupciones están mucho más localizadas y afectan solo a un pequeño subconjunto de los servicios en la nube o los sistemas de los clientes. Tenga en cuenta el alcance total de la interrupción para asegurarse de que la conmutación por error entre regiones sea la solución apropiada y elegir el método de conmutación por error adecuado para la situación. La decisión de utilizar el enfoque de transición o conmutación por error depende de la situación de interrupción concreta:

Ejecución de transiciones para bases de datos globales de Amazon Aurora

Al utilizar las transiciones, puede cambiar la región del clúster principal de forma rutinaria. Este enfoque está destinado a situaciones controladas, como el mantenimiento operativo y otros procedimientos operativos planificados.

Existen tres casos de uso frecuentes en los que se utilizan las transiciones.

Durante una transición, Aurora convierte el clúster de la región secundaria elegida en el clúster principal. El mecanismo de transición mantiene la topología de replicación existente de la base de datos global: sigue teniendo el mismo número de clústeres de Aurora en las mismas regiones. Antes de que Aurora inicie el proceso de transición, espera a que todos los clústeres de regiones secundarias estén completamente sincronizados con el clúster de la región principal. El clúster de base de datos en la región principal se convierte en solo de lectura. El clúster secundario elegido promociona uno de sus nodos de solo de lectura al estado de escritor completo, lo que permite que el clúster secundario 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 principal continúa las operaciones para la base de datos global de Aurora 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 nuevas funciones.

Para optimizar la disponibilidad de las aplicaciones, se recomienda hacer lo siguiente antes de utilizar esta característica:

Si utiliza el punto de conexión del escritor de la base de datos global de Aurora, no es necesario cambiar la configuración de conexión en su aplicación. Compruebe que los cambios de DNS se hayan propagado y que pueda conectarse y realizar operaciones de escritura en el nuevo clúster principal. A continuación, podrá reanudar el funcionamiento completo de la aplicación.

Suponga que las conexiones de su aplicación utilizan el punto de conexión del clúster principal anterior, en lugar del punto de conexión del escritor global. En ese caso, asegúrese de cambiar la configuración de conexión de la aplicación para utilizar el punto de conexión del clúster del nuevo clúster principal. Si aceptó los nombres proporcionados al crear la base de datos global de Aurora, puede cambiar el punto de enlace quitando -ro de la cadena del punto de enlace del clúster promocionado en la aplicación. Por ejemplo, el punto de enlace del clúster secundario my-global.cluster-ro-aaaaaabbbbbb.us-west-1.rds.amazonaws.com se convierte en my-global.cluster-aaaaaabbbbbb.us-west-1.rds.amazonaws.com cuando ese clúster se promueve a principal.

Si utiliza RDS Poxy, asegúrese de redirigir las operaciones de escritura de la aplicación al punto de conexión de lectura o escritura correspondiente del proxy asociado al nuevo clúster principal. Este punto de conexión proxy puede ser el punto de conexión predeterminado o un punto de conexión de lectura o escritura personalizado. Para obtener más información, consulte Cómo funcionan los puntos de conexión de RDS Proxy con las bases de datos globales.

Puede realizar una transición de la base de datos global de Aurora mediante la AWS Management Console, la AWS CLI o la API de RDS.

Para realizar la transición en la base de datos global de Aurora

1. Inicie sesión en la AWS Management Console y abra la consola de Amazon RDS en https://console.aws.amazon.com/rds/.

2. Elija Bases de datos y busque la base de datos global de Aurora que tiene intención de someter al proceso de transición.

3. Elija Transición o conmutación por error de base de datos global en el menú Acciones.

   

4. Elija Transición.

   

5. Para Nuevo clúster principal, elija un clúster activo en una de sus Regiones de AWS secundarias para que sea el nuevo clúster principal.

6. Elija Confirmar.

Cuando finalice la transición, podrá ver los clústeres de base de datos de Aurora y su estado actual en la lista Bases de datos, como se muestra en la siguiente imagen.

Para realizar la transición en una base de datos global de Aurora

Utilice el comando de la CLI switchover-global-cluster para realizar una transición en la base de datos global de Aurora. Con el comando, pase valores para los siguientes parámetros.

• --region: especifique la Región de AWS donde se ejecuta el clúster de base de datos principal de la base de datos global de Aurora.

• --global-cluster-identifier – Especifique el nombre de la base de datos global de Aurora.

• --target-db-cluster-identifier – Especifique el nombre de recurso de Amazon (ARN) del clúster de base de datos de Auroraque desea promover para que sea el principal de la base de datos global de Aurora.

Para Linux, macOS o Unix:

aws rds --region region_of_primary \
   switchover-global-cluster --global-cluster-identifier global_database_id \
  --target-db-cluster-identifier arn_of_secondary_to_promote

Para Windows:

aws rds --region region_of_primary ^
   switchover-global-cluster --global-cluster-identifier global_database_id ^
  --target-db-cluster-identifier arn_of_secondary_to_promote

Para realizar una transición de la base de datos global de Aurora, ejecute la operación de la API SwitchoverGlobalCluster.

Recuperación de una base de datos global Amazon Aurora de una interrupción no planificada

En raras ocasiones, su base de datos global de Aurora puede experimentar una interrupción inesperada en su Región de AWS principal. Si esto sucede, el clúster principal de base de datos de Aurora y su nodo de escritor no estarán disponibles, y cesará la replicación entre el clúster principal y el secundario. Para minimizar el tiempo de inactividad (RTO) y la pérdida de datos (RPO), puede trabajar rápidamente para realizar una conmutación por error entre regiones.

La base de datos global de Aurora tiene dos métodos de conmutación por error que puede usar en una situación de recuperación ante desastres:

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

Este enfoque tiene por objeto garantizar la continuidad empresarial en caso de que se produzca un verdadero desastre regional o una interrupción total del nivel de servicio.

Durante una conmutación por error administrada, el clúster secundario de la región secundaria elegida se convierte en el nuevo clúster principal. El clúster secundario elegido promueve uno de sus nodos de solo de lectura al estado de escritor completo. Este paso permite que el clúster asuma el rol de clúster principal. La base de datos no estará disponible durante un breve periodo, mientras el clúster asume su nuevo rol. Tan pronto como la región principal antigua esté en buen estado y vuelva a estar disponible, Aurora la volverá a agregar automáticamente al clúster global como región secundaria. De este modo, se mantiene la topología de replicación existente de la base de datos global de Aurora.

La conmutación por error administrada no espera a que los datos se sincronicen entre la región secundaria elegida y la región principal actual. Como la base de datos global de Aurora replica los datos de forma asíncrona, es posible que no todas las transacciones se repliquen en la región AWS secundaria elegida antes de que se promocione para aceptar todas las capacidades de lectura/escritura.

Para garantizar que los datos estén en un estado uniforme, Aurora crea un nuevo volumen de almacenamiento para la antigua región principal una vez que se recupera. Antes de crear el nuevo volumen de almacenamiento en la región AWS, Aurora intenta tomar una instantánea del volumen de almacenamiento anterior en el punto en que se produjo el error. De esta forma, puede restaurar la instantánea y recuperar cualquiera de los datos que se hayan perdido de esta. Si esta operación se realiza correctamente, Aurora coloca la instantánea con el nombre rds:unplanned-global-failover-name-of-old-primary-DB-cluster-timestamp en la sección de instantáneas de la AWS Management Console. También puede usar el comando describe-db-cluster-snapshots de la AWS CLI o la operación de la API DescribeDBClusterSnapshots para ver los detalles de la instantánea.

Al iniciar una conmutación por error administrada, Aurora también intenta detener el tráfico de escritura a través de la capa de almacenamiento Aurora, de alta disponibilidad. A este mecanismo lo denominamos “delimitación de escritura”. Si el proceso se realiza correctamente, Aurora emite un evento de RDS que le notifica que las escrituras se han detenido. En el improbable caso de que se produzcan varios fallos en las zonas de disponibilidad en una región, es posible que el proceso de escritura no se lleve a cabo a tiempo. En ese caso, Aurora emite un evento de RDS que le informa de que se ha agotado el tiempo de espera del proceso para detener las escrituras. Si se puede acceder al clúster principal anterior en la red, Aurora registra estos eventos allí. De lo contrario, Aurora registra los eventos en el nuevo clúster principal. Para obtener más información acerca de estos eventos, consulte Eventos de clúster de bases de datos. Dado que limitar la escritura es el mejor intento, es posible que las escrituras se acepten momentáneamente en la antigua región principal, lo que provocaría problemas de cerebro dividido.

Le recomendamos que realice las siguientes tareas antes de realizar una conmutación por error con la base de datos global de Aurora. Si lo hace, se minimiza la posibilidad de que se produzcan problemas de cerebro dividido o de que se recuperen datos no replicados de la instantánea del clúster principal anterior.

Durante una conmutación por error administrada, el clúster secundario de base de datos elegido se promueve a su nuevo rol de clúster principal. Sin embargo, no hereda las diversas opciones de configuración 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, recomendamos que se resuelvan las diferencias entre los clústeres de bases de datos globales de Aurora para lo siguiente:

Por lo general, el clúster secundario elegido asume el rol principal en cuestión de minutos. En cuanto la instancia de base de datos del escritor de la nueva región principal esté disponible, podrá conectar sus aplicaciones a ella y reanudar sus cargas de trabajo. Una vez que Aurora promueve el nuevo clúster principal, reconstruye automáticamente todos los clústeres regionales secundarios adicionales.

Como las bases de datos globales de Aurora utilizan la replicación asíncrona, el retraso de la replicación en cada región secundaria puede variar. Aurora reconstruye estas regiones secundarias para que tengan exactamente los mismos datos de un momento dado que el nuevo clúster de región principal. La duración de la tarea de reconstrucción completa puede tardar entre unos minutos y varias horas, según el tamaño del volumen de almacenamiento y la distancia entre las regiones. Cuando los clústeres de la región secundaria terminen de reconstruirse a partir de la nueva región principal, estarán disponibles para el acceso de lectura.

Tan pronto como se promocione y esté disponible el nuevo escritor principal, el clúster de la nueva región principal podrá gestionar las operaciones de lectura y escritura de la base de datos global de Aurora.

Si utiliza el punto de conexión global, no es necesario cambiar la configuración de conexión en su aplicación. Compruebe que los cambios de DNS se hayan propagado y que pueda conectarse y realizar operaciones de escritura en el nuevo clúster principal. A continuación, podrá reanudar el funcionamiento completo de la aplicación.

Si no utiliza el punto de conexión global, asegúrese de cambiar el punto de conexión de la aplicación para que utilice el punto de conexión del clúster para el clúster de base de datos principal recién promocionado. Si aceptó los nombres proporcionados al crear la base de datos global de Aurora, puede cambiar el punto de enlace quitando -ro de la cadena del punto de enlace del clúster promocionado en la aplicación.

Por ejemplo, el punto de enlace del clúster secundario my-global.cluster-ro-aaaaaabbbbbb.us-west-1.rds.amazonaws.com se convierte en my-global.cluster-aaaaaabbbbbb.us-west-1.rds.amazonaws.com cuando ese clúster se promueve a principal.

Si utiliza RDS Poxy, asegúrese de redirigir las operaciones de escritura de la aplicación al punto de conexión de lectura o escritura correspondiente del proxy asociado al nuevo clúster principal. Este punto de conexión proxy puede ser el punto de conexión predeterminado o un punto de conexión de lectura o escritura personalizado. Para obtener más información, consulte Cómo funcionan los puntos de conexión de RDS Proxy con las bases de datos globales.

Para restaurar la topología original del clúster de base de datos global, Aurora monitoriza la disponibilidad de la antigua región principal. Tan pronto como la región esté en buen estado y vuelva a estar disponible, Aurora la volverá a agregarla automáticamente al clúster global como región secundaria. Antes de crear el nuevo volumen de almacenamiento en la antigua región principal, Aurora intenta tomar una instantánea del volumen de almacenamiento anterior en el punto en que se produjo el error. Lo hace para que pueda usarla para recuperar cualquiera de los datos perdidos. Si esta operación se realiza correctamente, Aurora crea una instantánea con el nombre rds:unplanned-global-failover-name-of-old-primary-DB-cluster-timestamp. Puede encontrar esta instantánea en la sección Instantáneas de la AWS Management Console. También puede ver esta instantánea en la información devuelta por la operación de la API DescribeDBClusterSnapshots.

Una vez restaurada la topología original, puede conmutar por recuperación la base de datos global a la región principal original realizando una operación de transición cuando sea más conveniente para su empresa y su carga de trabajo. Para ello, siga los pasos que se indican en Ejecución de transiciones para bases de datos globales de Amazon Aurora.

Puede realizar una conmutación por error con la base de datos global de Aurora mediante la AWS Management Console, la AWS CLI o la API de RDS.

Para realizar la conmutación por error administrada en la base de datos global de Aurora

1. Inicie sesión en la AWS Management Console y abra la consola de Amazon RDS en https://console.aws.amazon.com/rds/.

2. Seleccione Bases de datos y busque la base de datos global de Aurora en la que desea llevar a cabo la conmutación por error.

3. Elija Transición o conmutación por error de base de datos global en el menú Acciones.

   

4. Elija Conmutación por error (permitir la pérdida de datos).

   

5. Para Nuevo clúster principal, elija un clúster activo en una de sus Regiones de AWS secundarias para que sea el nuevo clúster principal.

6. Introduzca confirm y, a continuación, elija Confirmar.

Cuando finalice la conmutación por error, podrá ver los clústeres de base de datos de Aurora y su estado actual en la lista Bases de datos, como se muestra en la siguiente imagen.

Para realizar la conmutación por error administrada en una base de datos global de Aurora

Utilice el comando de la CLI failover-global-cluster para realizar una conmutación por error con la base de datos global de Aurora. Con el comando, pase valores para los siguientes parámetros.

• --region: especifique la Región de AWS donde se ejecuta el clúster secundario de la base de datos que desea que sea el nuevo clúster principal de la base de datos global de Aurora.

• --global-cluster-identifier – Especifique el nombre de la base de datos global de Aurora.

• --target-db-cluster-identifier: especifique el nombre de recurso de Amazon (ARN) del clúster de la base de datos de Aurora que desea promover para que sea el clúster principal de la base de datos global de Aurora.

• --allow-data-loss: indique explícitamente que es una operación de conmutación por error en lugar de una operación de transición. Una operación de conmutación por error puede tener como resultado la pérdida de algunos datos si los componentes de replicación asincrónica no han completado el envío de todos los datos replicados a la región secundaria.

Para Linux, macOS o Unix:

aws rds --region region_of_selected_secondary \
   failover-global-cluster --global-cluster-identifier global_database_id \
   --target-db-cluster-identifier arn_of_secondary_to_promote \
   --allow-data-loss

Para Windows:

aws rds --region region_of_selected_secondary ^
   failover-global-cluster --global-cluster-identifier global_database_id ^
   --target-db-cluster-identifier arn_of_secondary_to_promote ^
   --allow-data-loss

Para realizar una conmutación por error con la base de datos global de Aurora, ejecute la operación de API FailoverGlobalCluster.

Ejecución de la conmutación por error manual para bases de datos globales de Aurora

En algunos casos, es posible que no pueda utilizar el proceso de conmutación por error administrada. Un ejemplo es si los clústeres de bases de datos principal y secundario no ejecutan versiones de motor compatibles. En este caso, puede seguir este proceso manual para realizar una conmutación por error en la región secundaria de destino.

Asegúrese de que las escrituras de la aplicación se envíen al clúster de base de datos de Aurora 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 Aurora (problemas del tipo cerebro dividido).

Si realizó una reconfiguración en respuesta a una interrupción en una Región de AWS, puede volver a hacer que la Región de AWS sea de nuevo la región principal después de que se resuelva la interrupción. Para ello, añada la antigua Región de AWS a la nueva base de datos global y, a continuación, utilice el proceso de transición para cambiar su rol. La base de datos global de Aurora debe utilizar una versión de Aurora PostgreSQL o Aurora MySQL que admita la transiciones. Para obtener más información, consulte Ejecución de transiciones para bases de datos globales de Amazon Aurora.

Administración de RPO para bases de datos globales basadas en Aurora PostgreSQL–

Con una base de datos global basada en Aurora PostgreSQL, puede administrar el objetivo de punto de recuperación (RPO) de la base de datos global de Aurora mediante el parámetro rds.global_db_rpo. El RPO representa la cantidad máxima de datos que se pueden perder en caso de interrupción.

Cuando establece un RPO para la base de datos global basada en Aurora PostgreSQL–, Aurora monitorea el tiempo de retraso de RPO de todos los clústeres secundarios para asegurarse de que al menos un clúster secundario permanezca dentro de la ventana de RPO de destino. El tiempo de retraso de RPO es otra métrica basada en tiempo.

El objetivo de punto de recuperación (RPO) se utiliza cuando la base de datos reanuda las operaciones en una nueva Región de AWS después de una conmutación por error. Aurora evalúa los tiempos de retraso de RPO y RPO para confirmar (o bloquear) transacciones en el clúster principal de la siguiente manera:

En otras palabras, si todos los clústeres secundarios están detrás del RPO fijado, Aurora detiene las transacciones en el clúster principal hasta que al menos uno de los clústeres secundarios se recupere. Las transacciones en pausa se reanudan y confirman tan pronto como el tiempo de retraso de al menos un clúster secundario de base de datos sea menor que el RPO. El resultado es que ninguna transacción se puede confirmar hasta que se cumpla el RPO.

El parámetro rds.global_db_rpo es dinámico. Si decide que no quiere que todas las transacciones de escritura se detengan hasta que el retraso disminuya lo suficiente, puede restablecerlo rápidamente. En este caso, Aurora reconoce e implementa el cambio tras un breve retraso.

Si establece este parámetro como se describe a continuación, también puede supervisar las métricas que genera. Puede hacerlo mediante psql u otra herramienta para consultar el clúster principal de la base de datos global de Aurora y obtener información detallada sobre las operaciones de la base de datos global basada en Aurora PostgreSQL–. Para saber cómo hacerlo, consulte Supervisión de bases de datos globales basadas en Aurora PostgreSQL.

Establecimiento del objetivo de punto de recuperación

El parámetro de rds.global_db_rpo controla la configuración de RPO para una base de datos PostgreSQL. Este parámetro es compatible con Aurora PostgreSQL. Valores válidos para el rango de rds.global_db_rpo de 20 segundos a 2 147 483 647 segundos (68 años). Elija un valor realista para satisfacer las necesidades de su negocio y su caso de uso. Por ejemplo, es posible que desee permitir hasta 10 minutos para su RPO, en cuyo caso establece el valor en 600.

Puede establecer este valor para la base de datos global basada en Aurora PostgreSQL–mediante la AWS Management Console, la AWS CLI o la API de RDS.

aws rds modify-db-cluster-parameter-group \
    --db-cluster-parameter-group-name my_custom_global_parameter_group \
    --parameters "ParameterName=rds.global_db_rpo,ParameterValue=600,ApplyMethod=immediate"

aws rds modify-db-cluster-parameter-group ^
    --db-cluster-parameter-group-name my_custom_global_parameter_group ^
    --parameters "ParameterName=rds.global_db_rpo,ParameterValue=600,ApplyMethod=immediate"

Visualización del objetivo de punto de recuperación

El objetivo de punto de recuperación (RPO) de una base de datos global se almacena en el parámetro rds.global_db_rpo para cada clúster de base de datos. Puede conectarse al punto de enlace del clúster secundario que desea ver y utilizar psql para consultar la instancia de este valor.

db-name=>show rds.global_db_rpo;

Si no se establece este parámetro, la consulta devuelve lo siguiente:

rds.global_db_rpo
-------------------
 -1
(1 row)

La siguiente respuesta es de un clúster secundario de base de datos que tiene una configuración de RPO de 1 minuto.

rds.global_db_rpo
-------------------
 60
(1 row)

También puede utilizar la CLI para obtener valores para averiguar si rds.global_db_rpo está activo en cualquiera de los clústeres de base de datos de Aurora mediante el uso de la CLI para obtener los valores de todos los parámetros user del clúster.

Para Linux, macOS o Unix:

aws rds describe-db-cluster-parameters \
 --db-cluster-parameter-group-name lab-test-apg-global \
 --source user

Para Windows:

aws rds describe-db-cluster-parameters ^
 --db-cluster-parameter-group-name lab-test-apg-global *
 --source user

El comando devuelve un resultado similar al siguiente para todos los parámetros user que no son default-engine o parámetros de clúster de base de datos de system.

{
    "Parameters": [
        {
            "ParameterName": "rds.global_db_rpo",
            "ParameterValue": "60",
            "Description": "(s) Recovery point objective threshold, in seconds, that blocks user commits when it is violated.",
            "Source": "user",
            "ApplyType": "dynamic",
            "DataType": "integer",
            "AllowedValues": "20-2147483647",
            "IsModifiable": true,
            "ApplyMethod": "immediate",
            "SupportedEngineModes": [
                "provisioned"
            ]
        }
    ]
}

Para obtener más información sobre la visualización de parámetros del grupo de parámetros de clúster, consulte Visualización de los valores de parámetros de un grupo de parámetros de clúster de base de datos en Amazon Aurora.

Desactivación del objetivo de punto de recuperación

Para desactivar el RPO, restablezca el parámetro rds.global_db_rpo. Puede restablecer los parámetros mediante la AWS Management Console, la AWS CLI o la API RDS.

aws rds reset-db-cluster-parameter-group \
    --db-cluster-parameter-group-name global_db_cluster_parameter_group \
    --parameters "ParameterName=rds.global_db_rpo,ApplyMethod=immediate"

aws rds reset-db-cluster-parameter-group ^
    --db-cluster-parameter-group-name global_db_cluster_parameter_group ^
    --parameters "ParameterName=rds.global_db_rpo,ApplyMethod=immediate"