Uso de tablas externas con la base de datos global de Aurora

La base de datos global de Aurora admite la ejecución de consultas de análisis con una configuración por región. En esta sección, se describe cómo configurar las consultas de análisis en todas las regiones, qué recursos se replican automáticamente y cómo planificar los escenarios de recuperación ante desastres.

Uso de aurora_analytics con una base de datos global

Una tabla externa es una definición de tabla de PostgreSQL que apunta a los datos de Apache Iceberg o Parquet en Amazon S3, Tablas de Amazon S3 o AWS Glue Data Catalog. No se copia ningún dato en Aurora. Solo lo siguiente se replica del clúster de base de datos principal a cada clúster de base de datos secundario:

• La instalación de la extensión de aurora_analytics

• Definiciones de tabla externa (DDL)

Lo siguiente no se replica y debe aprovisionarse de forma independiente en cada región que contenga un clúster de base de datos secundario:

• La asociación del rol de IAM al clúster de base de datos

• La política de IAM que otorga acceso a Amazon S3, AWS Glue o Tablas de Amazon S3

• Redes de VPC (puntos de conexión o NAT) utilizadas para llegar a esos servicios

Configuración de una base de datos global

Paso 1: creación de la política y el rol de IAM en cada región

La asociación de roles de IAM no se replica entre los clústeres de base de datos principales y secundarios. Debe crear y adjuntar un rol de IAM con el nombre de la función AuroraAnalytics en cada región que contenga un clúster de base de datos principal o secundario.

1. Cree una política de IAM que conceda acceso de lectura a los datos. Los permisos necesarios dependen del formato de los datos. Para obtener más información, consulte Referencia de políticas de IAM.

2. Cree un rol de IAM de confianza para rds.amazonaws.com y asóciele la política.

3. Asocie el rol al clúster de base de datos de esa región:

   aws rds add-role-to-db-cluster \
     --db-cluster-identifier <cluster-in-this-region> \
     --role-arn arn:aws:iam::<account-id>:role/AuroraAnalyticsRole \
     --feature-name AuroraAnalytics

4. Espere hasta que el estado del rol aparezca como Activo.

nota

Inmediatamente después de asociar un rol (o después de que se inicie o se promueva una instancia), las consultas realizadas en tablas externas pueden devolver brevemente el error: credential to access AWS service is unavailable. Espere a que el estado del rol sea Activo antes de ejecutar consultas en tablas externas.

Paso 2: configuración de redes en cada región

La configuración de VPC tampoco se replica. En la VPC de cada clúster de base de datos (principal y secundario), proporcione una ruta de red a los servicios necesarios para que el clúster de base de datos pueda acceder a los datos de la tabla externa para resolver las consultas. Asegúrese de que la configuración de red del clúster secundario permita acceder a la región de la tabla externa.

Puntos de conexión de VPC necesarios para cada región

Servicio	Tipo de punto de conexión	Obligatorio para
Amazon S3 (com.amazonaws.<region>.s3)	Puerta de enlace	Acceso a todos los datos de Amazon S3 y Tablas de Amazon S3
AWS Glue (com.amazonaws.<region>.glue)	Interfaz	Acceso de AWS Glue Data Catalog (tablas de Iceberg)
AWS STS (com.amazonaws.<region>.sts)	Interfaz	Recuperación de credenciales de rol de IAM

Para los puntos de conexión de interfaz de AWS Glue y AWS STS, habilite el DNS privado y permita el TCP 443 entrante desde el CIDR de la VPC.

Paso 3: instalación de la extensión en el principal

Conéctese a la instancia de base de datos del escritor en el clúster de base de datos principal e instale la extensión en cada base de datos en la que desee crear tablas externas:

CREATE EXTENSION aurora_analytics;

La extensión se replica automáticamente en cada clúster de base de datos secundario.

Paso 4: creación de tablas externas en el principal

En la instancia de base de datos del escritor del clúster de base de datos principal, cree tablas externas que apunten a los datos:

-- Parquet via S3 URI
CREATE FOREIGN TABLE ft_orders ()
SERVER aurora_analytics_server
OPTIONS (location 's3://my-bucket/orders/',
         format 'parquet', region 'us-east-1');

-- Iceberg via Glue ARN
CREATE FOREIGN TABLE ft_transactions ()
SERVER aurora_analytics_server
OPTIONS (location 'arn:aws:glue:us-east-1:123456789012:table/mydb/transactions',
         format 'iceberg');

Aurora replica el DDL en cada clúster de base de datos secundario, donde las tablas externas están disponibles para su consulta.

Paso 5: verificación en el secundario

Conéctese a un clúster de base de datos secundario y confirme la replicación y el acceso de lectura:

SELECT extname, extversion FROM pg_extension WHERE extname = 'aurora_analytics';
SELECT count(*) FROM ft_orders;

Fijación por regiones de tablas externas

Al crear una tabla externa, la location y la Region de los datos se almacenan en la definición de la tabla y se replican en todos los clústeres de bases de datos de la base de datos global. Todos los clústeres de bases de datos se leen desde la misma ubicación.

Esto implica:

• Cada clúster de base de datos secundario lee los datos de una tabla externa de la región especificada en la definición de la tabla.

• Si esa región es diferente de la región secundaria, las lecturas son entre regiones, lo que agrega los costos de transferencia de datos y la latencia.

• El rol de IAM y la red de contactos de cada secundario permiten llegar a la región de la tabla externa.

nota

Los puntos de acceso multirregionales (MRAP) de Amazon S3 no se admiten como ubicación de tabla externa. Aurora PostgreSQL solo acepta URI de s3://, ARN de tabla de AWS Glue y ARN de Tablas de Amazon S3 en la opción location. Los ARN de MRAP y los nombres de host de MRAP no son válidos para la opción location.

Guía general sobre la preparación para la recuperación ante desastres

Complete la configuración por región en los pasos 1 y 2 para el clúster de base de datos secundario y, a continuación, decida cómo accederá el clúster de base de datos a los datos de la tabla externa:

• Acepte lecturas entre regiones: este enfoque solo es adecuado para escenarios de conmutación planificados en los que la región original esté en buen estado.

• Prepare previamente una copia regional local: utilice la replicación entre regiones de Amazon S3 para que las consultas de análisis puedan leerse localmente incluso si la región original no está disponible. Prepare las instrucciones ALTER FOREIGN TABLE ... OPTIONS (SET ...) para actualizar las ubicaciones de las tablas externas para que apunten a la copia regional local.

nota

La caché de lectura del disco no se conserva ni se transfiere cuando se produce una conmutación o una conmutación por error. Las primeras consultas después del evento leen datos de Amazon S3 y se ejecutan con una latencia más alta hasta que la memoria caché se active.

Gestión de la conmutación y la conmutación por error

Durante una conmutación o conmutación por error de la base de datos global de Aurora, las consultas de tablas externas tienen una dependencia adicional más allá de las conexiones de clientes de bases de datos estándar: deben llegar a Amazon S3, AWS Glue y AWS STS en la región nombrada por cada tabla externa.

Conmutación de base de datos global

Los clústeres de base de datos principales y secundarios están en buen estado en el momento de la conmutación. Una vez que el nuevo clúster de base de datos principal esté disponible, las consultas se seguirán leyendo desde la región nombrada en cada tabla externa. Si esa región es diferente de la región de escritor nueva, las lecturas son entre regiones e incurren en costos de transferencia de datos y latencia. Para evitar la latencia de lectura entre regiones, ejecute las instrucciones ALTER FOREIGN TABLE ... OPTIONS (SET ...) preparadas para redirigir las tablas externas a una copia regional local.

Reanudación de las operaciones después de una conmutación

1. Permita que los clientes se vuelvan a conectar al punto de conexión del escritor del nuevo clúster de base de datos principal.

2. Espere hasta que el estado del rol de IAM sea Activo. Ejecute una consulta de prueba en una tabla externa (por ejemplo, SELECT count(*) FROM ft_orders) con una lógica de reintento para confirmar que las consultas de análisis están operativas.

3. Si utiliza una copia regional local, ejecute las instrucciones ALTER preparadas en el nuevo clúster de base de datos principal para actualizar las ubicaciones de las tablas externas:

   ALTER FOREIGN TABLE ft_orders OPTIONS (SET location 's3://dr-region-bucket/orders/', SET region 'us-west-2');
   ALTER FOREIGN TABLE ft_transactions OPTIONS (SET location 'arn:aws:glue:us-west-2:123456789012:table/mydb/transactions');

nota

ALTER FOREIGN TABLE ... OPTIONS (SET ...) es un cambio exclusivo de los metadatos del catálogo. Se completa de forma inmediata sin movimiento de datos. Se necesita un bloqueo de ACCESS EXCLUSIVE breve en esa única tabla externa. Por lo tanto, queda bloqueada por cualquier consulta interna en la misma tabla.

Conmutación por error de base de datos global

Es posible que la región original esté dañada o sea inalcanzable. Si una tabla externa nombra la región dañada, las consultas realizadas en ella experimentan una latencia alta o producen errores de tiempo de espera hasta que esa región se recupere o se redirija la tabla externa a los datos de una región en buen estado. Si ha preparado previamente una copia regional local, ejecute las instrucciones ALTER FOREIGN TABLE ... OPTIONS (SET region ...) preparadas para apuntar las tablas externas a la copia regional local.

Vuelta a la región principal original

Cuando la región principal original pasa a estar disponible, Aurora vuelve a agregarla automáticamente a la base de datos global como un clúster de base de datos secundario. Todos los cambios de ALTER FOREIGN TABLE realizados durante la conmutación o la conmutación por error se replican en ella mediante la replicación global. Para restaurar la región principal original, realice una conmutación. Una vez finalizada la conmutación, determine si desea revertir las ubicaciones de las tablas externas para que apunten a los datos de la región principal restaurada.

Mensajes de error en una base de datos global

Tras una conmutación o una conmutación por error, las consultas en la nueva región principal pueden producir un error con los mismos errores de asociación de roles de IAM, permisos de IAM y redes que afectan a cualquier región que ejecute un clúster de base de datos secundario. Estos errores y sus soluciones están cubiertos en conmutación y conmutación por error de la base de datos global en Supervisión y solución de problemas. Los requisitos previos deben cumplirse en cada región secundaria, ya que la asociación de roles de IAM, la política de IAM y las redes de VPC no se replican.

• La location y la region de una tabla externa son una definición replicada única que no se anula por región. Ambos clústeres no pueden contener regiones diferentes para la misma tabla.

• Los puntos de acceso multirregionales de Amazon S3 y los ARN de puntos de acceso de Amazon S3 no se admiten como ubicaciones de tablas externas.

• Los puntos de conexión de la puerta de enlace de VPC son regionales y no pueden llegar a Amazon S3 de otra región. Una ruta de red entre regiones requiere NAT/salida de Internet o puerta de enlace de tránsito.

• Tras una conmutación, al actualizar la ubicación de una tabla externa a la región del nuevo clúster de base de datos principal, el clúster de base de datos principal anterior leerá entre regiones en su lugar.

• La tabla externa DDL y la extensión se replican solo después de asociar el secundario y sincronizarlo. Instale la extensión aurora_analytics y cree tablas externas en el principal después de conectar el secundario para que se propaguen.