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, puede realizar una actualización local desde la versión 2 a la versión 3 de Aurora MySQL si establece el parámetro lower_case_table_names en predeterminado y reinicia la base de datos global.
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:
-
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.
-
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.
-
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 exactamente la misma versión, incluido el nivel de parche.
-
Si actualiza una base de datos global de Aurora PostgreSQL, debe actualizar los clústeres de base de datos principales y secundarios a esa misma versión exactamente y el nivel de parche. Para actualizar el nivel de parche, aplique todas las acciones de mantenimiento pendientes en el clúster secundario.
Para poder realizar la transición o la conmutación por error administrada entre regiones, puede que tenga que actualizar sus clústeres de bases de datos principal y secundario exactamente a la misma versión, incluido el nivel de parche. Este requisito se aplica a Aurora MySQL y a algunas versiones de Aurora PostgreSQL. Para obtener una lista de las versiones que permiten transiciones y conmutaciones por error entre clústeres que ejecutan diferentes niveles de parche, 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 su base de datos global de Aurora se ejecuta en 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, los clústeres de base de datos principal y secundario se deben ejecutar en 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 cuando planifique las actualizaciones de su clúster principal, de los clústeres secundarios o de ambos.
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.
Si las versiones del motor requieren niveles de parches idénticos, puede realizar la conmutación por error manualmente por medio de los pasos que se indican en Ejecución de la conmutación por error manual para bases de datos globales de Aurora.
| Motor de base de datos | Versiones secundarias del motor | Notas |
|---|---|---|
Aurora MySQL |
No hay versiones secundarias |
Ninguna de las versiones de Aurora MySQL permiten 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 son distintos. |
Aurora PostgreSQL |
|
En las versiones 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. |
