Integraciones sin ETL de Aurora

Le ayudan a obtener información holística a partir de numerosos orígenes de datos.

Eliminan la necesidad de crear y mantener canalizaciones de datos complejas que realicen operaciones de extracción, transformación y carga (ETL). Las integraciones sin ETL eliminan los inconvenientes derivados de la creación y administración de canalizaciones, ya que las aprovisionan y administran por usted.

Reducen la carga operativa y los costos para que pueda centrarse en mejorar sus aplicaciones.

Le permite aprovechar las capacidades de análisis y ML de destino para obtener información a partir de datos transaccionales y de otro tipo, a fin de responder de manera eficaz a eventos críticos y urgentes.

El clúster de base de datos de origen debe estar en la misma región que el destino.

No puede cambiar el nombre de un clúster de base de datos ni ninguna de sus instancias si ya tiene integraciones.

No se pueden crear varias integraciones entre las mismas bases de datos de origen y de destino.

No puede eliminar un clúster de base de datos que ya tenga integraciones. Primero debes eliminar todas las integraciones asociadas.

Si detiene el clúster de base de datos de origen, es posible que las últimas transacciones no se repliquen en el destino hasta que reanude el clúster.

Si el clúster es el origen de una implementación azul/verde, los entornos azul y verde no pueden tener integraciones sin ETL existentes durante la transición. Primero debe eliminar la integración, realizar la transición y, a continuación, volver a crear la integración.

Un clúster de base de datos debe contener al menos una instancia de base de datos para ser el origen de una integración.

No puede crear una integración para un clúster de base de datos de origen que sea un clon entre cuentas, como los que se comparten mediante AWS Resource Access Manager (AWS RAM).

Si el clúster de origen es el clúster de base de datos primario de una base de datos global de Aurora y se cambia por error a uno de sus clústeres secundarios, la integración queda inactiva. Debe eliminar y volver a crear la integración.

No puede crear una integración para una base de datos de origen en la que se esté creando otra integración de forma activa.

Cuando se crea una integración por primera vez, o cuando se vuelve a sincronizar una tabla, la transferencia de datos del origen al destino puede tardar entre 20 y 25 minutos o más, en función del tamaño de la base de datos de origen. Este retardo puede provocar un aumento del retardo en la réplica.

Algunos tipos de datos no son compatibles. Para obtener más información, consulte Diferencias de tipos de datos entre las bases de datos Aurora y Amazon Redshift .

Las tablas del sistema, las tablas temporales y las vistas no se replican en almacenes de destino.

Las operaciones de partición de ALTER TABLE provocan que se vuelva a sincronizar la tabla para recargar los datos de Aurora en el destino de análisis. Durante este proceso, la tabla no se podrá consultar. Para obtener más información, consulte Una o más de mis tablas de Amazon Redshift requieren una resincronización.

El clúster de base de datos de origen debe ejecutar una versión compatible de Aurora MySQL. Para obtener una lista de las versiones compatibles, consulte Regiones y motores de base de datos Aurora admitidos para integraciones sin ETL con Amazon Redshift.

Las integraciones sin ETL se basan en el registro binario de MySQL (binlog) para capturar los cambios en los datos en curso. No utilice el filtrado de datos basado en binlog, ya que puede provocar incoherencias entre los datos de las bases de datos de origen y de destino.

Las integraciones sin ETL solo son compatibles con bases de datos configuradas para usar el motor de almacenamiento de InnoDB.

No se admiten referencias de clave externas con actualizaciones de tablas predefinidas. En concreto, las reglas ON DELETE y ON UPDATE no son compatibles con las acciones CASCADE, SET NULL y SET DEFAULT. Si se intenta crear o actualizar una tabla con este tipo de referencias a otra tabla, se producirá un error en la tabla.

Las transacciones XA realizadas en el clúster de base de datos de origen hacen que la integración entre en un estado de Syncing.

El clúster de base de datos de origen debe ejecutar una versión compatible de Aurora PostgreSQL. Para obtener una lista de las versiones compatibles, consulte Regiones y motores de base de datos Aurora admitidos para integraciones sin ETL con Amazon Redshift.

Si selecciona un clúster de base de datos de origen de Aurora PostgreSQL, debe especificar al menos un patrón de filtro de datos. Como mínimo, el patrón debe incluir una única base de datos (database-name.*.*) para la replicación en el almacén de destino. Para obtener más información, consulte Filtrado de datos para integraciones sin ETL de Aurora.

Todas las bases de datos creadas en el clúster de base de datos de Aurora PostgreSQL de origen deben utilizar la codificación UTF-8.

Si realiza transacciones de particionamiento declarativo en el clúster de base de datos de origen, todas las tablas afectadas pasan a un estado erróneo y dejan de estar accesibles.

No se admiten las transacciones bifásicas.

Si elimina todas las instancias de base de datos de un clúster de base de datos que es el origen de una integración y, a continuación, vuelve a agregar una instancia de base de datos, la replicación se interrumpe entre los clústeres de origen y de destino.

El clúster de base de datos de origen no puede utilizar Aurora Limitless Database.

Los nombres de catálogo están limitados a 19 caracteres de longitud.