Uso de bases de datos globales de Amazon Aurora

Las bases de datos globales de Amazon Aurora abarcan múltiples Regiones de AWS, lo que permite lecturas globales de baja latencia y proporcionan una recuperación rápida de cualquier interrupción que pueda afectar a toda una Región de AWS. Una base de datos global de Aurora tiene un clúster de base de datos principal en una región y hasta cinco clústeres de base de datos secundarios en diferentes regiones.

Temas

• Información general sobre las bases de datos globales de Amazon Aurora
• Ventajas de las bases de datos globales de Amazon Aurora
• Disponibilidad en regiones y versiones
• Limitaciones de las bases de datos globales de Amazon Aurora
• Introducción a bases de datos globales de Amazon Aurora
• Administración de una base de datos global de Amazon Aurora
• Conexión a una base de datos global de Amazon Aurora
• Uso del reenvío de escritura en una base de datos Amazon Aurora global
• Uso de la transición o la conmutación por error en una base de datos global de Amazon Aurora
• Monitoreo de una base de datos global de Amazon Aurora
• Uso de las bases de datos globales de Amazon Aurora con otros servicios de AWS
• Actualización de una base de datos global de Amazon Aurora

Información general sobre las bases de datos globales de Amazon Aurora

Por medio de una base de datos global de Amazon Aurora, puede ejecutar sus aplicaciones distribuidas globalmente a través de una única base de datos de Aurora que abarca múltiples Regiones de AWS.

Una base de datos global de Aurora consta de una Región de AWS principal donde se escriben sus datos, y hasta cinco Regiones de AWS secundarias de solo lectura. Emita operaciones de escritura directamente en el clúster de base de datos principal en la Región de AWS principal. Aurora replica los datos en las Regiones de AWS secundarias mediante una infraestructura dedicada, con una latencia normalmente inferior a un segundo.

En el siguiente diagrama, puede encontrar un ejemplo de base de datos global de Aurora que abarca dos Regiones de AWS.

Puede escalar el clúster secundario independientemente añadiendo una o varias Aurora instancias de base de datos (instancias de base de datos de Aurora de solo lectura) para servir a cargas de trabajo de solo lectura.

Solo el clúster primario realiza operaciones de escritura. Los clientes que realizan operaciones de escritura se conectan al punto de enlace del clúster de base de datos del clúster primario. Como se muestra en el diagrama, la base de datos global de Aurora utiliza el volumen de almacenamiento de clúster y no el motor de base de datos para la reproducción. Para obtener más información, consulte Información general del almacenamiento de Amazon Aurora.

Las bases de datos globales de Aurora están diseñadas para aplicaciones con una huella mundial. Los clústeres de base de datos secundarios de solo lectura (Regiones de AWS) le permiten admitir operaciones de lectura más cercanas a los usuarios de la aplicación. Con la característica del reenvío de escritura, también puede configurar una base de datos global de Aurora para que los clústeres secundarios envíen datos al principal. Para obtener más información, consulte Uso del reenvío de escritura en una base de datos Amazon Aurora global.

Una base de datos global de Aurora admite dos operaciones diferentes para cambiar la región del clúster de base de datos principal, según el caso: transición de base de datos global y conmutación por error de base de datos global.

• En el caso de procedimientos operativos planificados, como la rotación regional, utilice la transición de base de datos global (antes denominada “conmutación por error planificada administrada”). Con esta característica, puede reubicar el clúster principal de una base de datos global de Aurora en buen estado a una de sus regiones secundarias sin necesidad de perder datos. Para obtener más información, consulte Ejecución de transiciones para bases de datos globales de Amazon Aurora.

• Para recuperar la base de datos global de Aurora después de una interrupción en la región principal, utilice la conmutación por error de base de datos global. Con este característica, realiza la conmutación por error del clúster de base de datos principal a otra región (conmutación por error entre regiones). Para obtener más información, consulte Ejecución de la conmutación por error administrada para bases de datos globales de Aurora.

Ventajas de las bases de datos globales de Amazon Aurora

Mediante el uso de bases de datos globales de Aurora, puede obtener las siguientes ventajas:

• Lecturas globales con latencia local: si tiene oficinas en todo el mundo, puede utilizar una base de datos global de Aurora para mantener actualizadas sus principales fuentes de información en la Región de AWS principal. Las oficinas en sus otras regiones pueden acceder a la información en su propia región, con latencia local.

• Clústeres de base de datos secundarios y escalables de Aurora: puede escalar los clústeres secundarios; para ello, agregue más instancias de solo lectura (réplicas de Aurora) a una Región de AWS secundaria. El clúster secundario es de solo lectura, por lo que puede admitir hasta 16 instancias de réplica de Aurora de solo lectura en lugar del límite habitual de 15 para un solo clúster de Aurora.

• Replicación rápida de clústeres de base de datos Aurora primarios a secundarios – La replicación realizada por una base de datos Aurora global tiene poco impacto en el performance en el clúster de base de datos principal. Los recursos de las instancias de bases de datos están totalmente dedicados a servir a las cargas de trabajo de lectura y escritura de la aplicación.

• Recuperación de interrupciones en toda la región: los clústeres secundarios le permiten hacer que una base de datos global de Aurora esté disponible en una Región de AWS principal nueva más rápido (RTO más bajo) y con menos pérdida de datos (RPO más bajo) que las soluciones de replicación tradicionales.

Disponibilidad en regiones y versiones

La disponibilidad y el soporte de la característica varía según las versiones específicas de cada motor de base de datos de Aurora y entre Regiones de AWS. Para obtener más información acerca de la versión y la disponibilidad de las regiones con Aurora y bases de datos globales, consulte Bases de datos globales de Aurora.

Limitaciones de las bases de datos globales de Amazon Aurora

Las limitaciones siguientes se aplican actualmente a las bases de datos globales de Aurora:

• Las bases de datos globales de Aurora están disponibles solo en ciertas Regiones de AWS y para versiones específicas de Aurora MySQL y Aurora PostgreSQL. Para obtener más información, consulte Bases de datos globales de Aurora.

• Las bases de datos globales de Aurora tienen requisitos de configuración concretos para las clases de instancias de base de datos compatibles de Aurora, la cantidad máxima de Regiones de AWS, etc. Para obtener más información, consulte Requisitos de configuración de una base de datos Amazon Aurora global.

• Para Aurora MySQL con compatibilidad con MySQL 5.7, las transiciones de bases de datos globales de Aurora requieren la versión 2.09.1 o una superior.

• Solo puede realizar una transición o conmutación por error administrada 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 parche del motor. Sin embargo, los niveles de revisión pueden ser diferentes si las versiones secundarias del motor son una de las siguientes.

  Motor de base de datos	Versiones secundarias del motor
  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

  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.

• Las bases de datos globales Aurora actualmente no admiten las siguientes características Aurora:

  • Aurora Serverless v1

  • Búsqueda de datos anteriores en Aurora.

• Para conocer las limitaciones del uso de la característica RDS Proxy con bases de datos globales, consulte Limitaciones de RDS Proxy con bases de datos globales.

• La actualización automática de versiones secundarias no se aplica a clústeres de Aurora MySQL y Aurora PostgreSQL que formen parte de una base de datos global de Aurora MySQL. Tenga en cuenta que puede especificar esta configuración para una instancia de base de datos que forme parte de un clúster de base de datos global, pero la configuración no tendrá ningún efecto.

• Las bases de datos globales Aurora actualmente no admiten Aurora Auto Scaling para clústeres de bases de datos secundarios.

• Para utilizar las secuencias de actividades de base de datos en las bases de datos globales de Aurora que ejecutan Aurora MySQL 5.7, la versión del motor debe ser la 2.08 o superior. Para obtener información acerca de las secuencias de actividades de la base de datos, consulte Supervisión de Amazon Aurora con flujos de actividad de la base de datos.

• Las limitaciones siguientes se aplican actualmente a la actualización de las bases de datos globales de Aurora:

  • No puede aplicar un grupo de parámetros personalizado al clúster de base de datos global mientras realiza una actualización importante de la versión de esa base de datos global de Aurora. Se crean grupos de parámetros personalizados en cada región del clúster global y se aplican manualmente a los clústeres regionales después de la actualización.

  • 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 obtener más información sobre los métodos que puede utilizar, consulte Actualizaciones de la versión principal.

  • 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–.

  • Con una base de datos global Aurora basada en Aurora MySQL, no se puede realizar una actualización de versión secundaria desde la versión 3.01 o 3.02 a la versión 3.03 o una posterior mediante el proceso estándar. Para obtener más información sobre el proceso que se debe usar, consulte Actualización de Aurora MySQL mediante la modificación de la versión del motor.

  Para obtener información sobre cómo actualizar una base de datos global de Aurora, consulte Actualización de una base de datos global de Amazon Aurora.

• No puede detener o iniciar los clústeres de Aurora base de datos en la base de datos Aurora global individualmente. Para obtener más información, consulte Detención e inicio de un clúster de bases de datos de Amazon Aurora.

• Las réplicas de Aurora conectadas al clúster de base de datos de Aurora secundario pueden reiniciarse en determinadas circunstancias. Si la instancia de base de datos de escritura de la Región de AWS principal se reinicia o se conmuta por error, las réplicas de Aurora también se reinician en las regiones secundarias. El clúster secundario no estará disponible hasta que todas las réplicas vuelvan a estar sincronizadas con la instancia de escritura del clúster de base de datos principal. El comportamiento del clúster principal cuando se reinicia o se produce una conmutación por error es el mismo que en un clúster de base de datos único y no global. Para obtener más información, consulte Replicación con Amazon Aurora.

  Asegúrese de comprender los impactos en la base de datos global de Aurora antes de realizar cambios en el clúster de base de datos principal. Para obtener más información, consulte Recuperación de una base de datos global Amazon Aurora de una interrupción no planificada.

• Actualmente, las bases de datos globales de Aurora no admiten el estado inaccessible-encryption-credentials-recoverable en el que Amazon Aurora pierde el acceso a la clave AWS KMS del clúster de base de datos. En estos casos, el clúster de base de datos cifrado entra en el estado inaccessible-encryption-credentials de terminal. Para obtener más información sobre estos estados, consulte Ver el estado del clúster de base de datos.

• Los clústeres de base de datos basados en Aurora PostgreSQL que se ejecutan en una base de datos global de Aurora tienen las siguientes limitaciones:

  • La administración de caché de clúster no es compatible con los clústeres de base de datos Aurora PostgreSQL que forman parte de bases de datos globales de Aurora.

  • Si el clúster de base de datos principal de la base de datos global de Aurora se basa en una réplica de una instancia de PostgreSQL Amazon RDS, no puede crear un clúster secundario. No intente crear un secundario a partir de ese clúster mediante AWS Management Console, la AWS CLI, o la operación CreateDBCluster API. Los intentos para hacerlo se agotan y no se crea el clúster secundario.

Se recomienda crear clústeres de base de datos secundarios para las bases de datos Aurora globales utilizando la misma versión del motor de base de datos Aurora que el primario. Para obtener más información, consulte Creación de una base de datos global de Amazon Aurora.