Actualización de una base de datos global de Amazon Aurora

La actualización de una base de datos global de Aurora sigue los mismos procedimientos que la actualización de clústeres de base de datos de Aurora. Sin embargo, estas son algunas diferencias importantes a tener en cuenta antes de comenzar el proceso.

Se recomienda actualizar los clústeres de base de datos principal y secundaria a la misma versión. Solo puede realizar una conmutación por error administrada de la base de datos entre regiones en una base de datos global de Aurora si los clústeres de base de datos principal y secundario tienen las mismas versiones principal, secundaria y de nivel de revisión del motor. Sin embargo, los niveles de revisión pueden ser diferentes en función de la versión secundaria del motor. Para obtener más información, consulte Compatibilidad de los niveles de parche para la transición o conmutación por error administrada entre regiones.

Actualizaciones de la versión principal

Cuando realice una actualización de versión principal de una base de datos global de Amazon Aurora, actualiza el clúster de la base de datos global en lugar de los clústeres individuales que contiene.

Para obtener información sobre cómo actualizar una base de datos global de Aurora PostgreSQL a una versión principal superior, consulte Actualizaciones importantes para bases de datos globales.

nota

Con una base de datos global de Aurora basada en Aurora PostgreSQL, no se puede realizar una actualización de versión importante del motor de base de datos de Aurora si la característica Objetivo de punto de recuperación (RPO) está habilitada. Para obtener información sobre la característica RPO, consulte Administración de RPO para bases de datos globales basadas en Aurora PostgreSQL–.

Para obtener información sobre cómo actualizar una base de datos global de Aurora PostgreSQL a una versión principal superior, consulte Actualizaciones mayores en el lugar para bases de datos globales.

nota

Con una base de datos global de Aurora basada en Aurora MySQL, no se puede realizar una actualización local desde la versión 2 a la versión 3 de Aurora MySQL si el parámetro lower_case_table_names está activado.

Para realizar una actualización de la versión principal a Aurora MySQL versión 3 con lower_case_table_names, utilice el siguiente proceso:

1. Elimine todas las regiones secundarias del clúster global. Siga los pasos de Eliminación de un clúster de una base de datos global de Amazon Aurora.

2. Actualice la versión del motor de la región principal a Aurora MySQL versión 3. Siga los pasos de Pasos para realizar una actualización local.

3. Añada regiones secundarias al clúster global. Siga los pasos de Incorporación de una Región de AWS a una base de datos global de Amazon Aurora.

También puede utilizar el método de restauración de instantáneas en su lugar. Para obtener más información, consulte Restauración de una instantánea de clúster de base de datos.

Actualizaciones de la versión secundaria

Para una actualización menor en una base de datos global de Aurora, actualice todos los clústeres secundarios antes de actualizar el clúster principal.

Para obtener información sobre cómo actualizar una base de datos global de Aurora PostgreSQL a una versión secundaria superior, consulte Cómo realizar actualizaciones de versión secundarias y aplicar revisiones. Para obtener información sobre cómo actualizar una base de datos global de Aurora MySQL a una versión secundaria superior, consulte Actualización de Aurora MySQL mediante la modificación de la versión del motor.

Antes de realizar la actualización, tenga en cuenta lo siguiente:

• La actualización de la versión secundaria de un clúster secundario no afecta en modo alguno a la disponibilidad ni al uso del clúster principal.

• Un clúster secundario debe tener al menos una instancia de base de datos para realizar una actualización menor.

• Si actualiza una base de datos global de Aurora MySQL a la versión 2.11.*, debe actualizar los clústeres de base de datos principales y secundarios a esa misma versión exactamente, incluido el nivel de revisión.

• Para poder realizar la transición o la conmutación por error administrada entre regiones, debe actualizar sus clústeres de bases de datos principal y secundario exactamente a la misma versión, incluido el nivel de parche, en función de la versión del motor. Para obtener más información, consulte Compatibilidad de los niveles de parche para la transición o conmutación por error administrada entre regiones.

Compatibilidad de los niveles de parche para la transición o conmutación por error administrada entre regiones

Si actualiza su base de datos global Aurora a una de las siguientes versiones secundarias del motor, podrá realizar una transición o conmutación por error administrada entre regiones aunque los niveles de parche de los clústeres de base de datos principal y secundario no coincidan. Para las versiones secundarias del motor anteriores a las de esta lista, debe actualizar los clústeres de base de datos principal y secundario a los mismos niveles de versión principal, secundaria y de parche para realizar una transición o conmutación por error administrada entre regiones. Asegúrese de revisar la información de la versión y las notas de la siguiente tabla.

nota

Para las conmutaciones por error entre regiones manuales, puede realizar el proceso de conmutación por error siempre que el clúster de base de datos secundario de destino ejecute la misma versión principal y secundaria del motor que el clúster de base de datos principal. En este caso, no es necesario que los niveles de revisión coincidan.

Motor de base de datos	Versiones secundarias del motor	Notas
Aurora MySQL	No hay versiones secundarias	En todas las versiones secundarias, solo puede realizar una transición o conmutación por error administrada entre regiones si los niveles de parche de los clústeres de base de datos principal y secundario coinciden.
Aurora PostgreSQL	Versión 14.5 o versión secundaria posterior Versión 13.8 o versión secundaria posterior Versión 12.12 o versión secundaria posterior Versión 11.17 o versión secundaria posterior	En las versiones secundarias del motor enumeradas en la columna anterior, puede realizar una transición o conmutación por error administrada entre regiones desde un clúster de base de datos principal con un nivel de parche a un clúster de base de datos secundario que tenga un nivel de parche diferente. En las versiones secundarias anteriores a esas, solo puede realizar una transición o conmutación por error administrada entre regiones si los niveles de parche de los clústeres de base de datos principal y secundario coinciden.