Integrazioni Zero-ETL di Aurora

Ti consentono di ottenere approfondimenti di tipo olistico da più origini dati.

Eliminano la necessità di creare e gestire pipeline dei dati complesse che eseguono operazioni di estrazione, trasformazione e caricamento (ETL). Le integrazioni Zero-ETL forniscono e gestiscono le pipeline per te, eliminando le sfide legate alla loro creazione e gestione.

Ti consentono di ridurre il carico e i costi operativi e di concentrarti sul miglioramento delle applicazioni.

Puoi utilizzare le funzionalità di analisi e machine learning della destinazione per ricavare informazioni dettagliate da dati transazionali e di altro tipo e reagire in modo efficace in caso di eventi critici e urgenti.

Il cluster di database di origine deve trovarsi nella stessa Regione della destinazione.

Non è possibile rinominare un cluster di database né alcuna delle sue istanze se include integrazioni esistenti.

Non è possibile creare più integrazioni tra gli stessi database di origine e destinazione.

Non è possibile eliminare un cluster di database con integrazioni esistenti. Devi prima eliminare tutte le integrazioni associate.

Se il cluster di database di origine viene arrestato, è possibile che le ultime transazioni non vengano replicate nella destinazione finché non si riprende il cluster.

Se il cluster è l’origine di un’implementazione blu/verde, gli ambienti blu e verde non possono avere integrazioni Zero-ETL esistenti durante lo switchover. Occorre eliminare l’integrazione, eseguire lo switchover e poi ricrearla.

Un cluster di database deve contenere almeno un’istanza database per essere l’origine di un’integrazione.

Non è possibile creare un'integrazione per un cluster DB di origine che è un clone tra più account, come quelli condivisi utilizzando (). AWS Resource Access Manager AWS RAM

Se il cluster di origine è il cluster di database primario in un database globale Aurora e esegue il failover su uno dei relativi cluster secondari, l’integrazione diventa inattiva. È necessario eliminare e ricreare l’integrazione.

Non è possibile creare un’integrazione per un database di origine in cui un’altra integrazione è attivamente in fase di creazione.

Durante la fase iniziale della creazione di un’integrazione o quando una tabella viene risincronizzata, il seeding dei dati dall’origine alla destinazione può richiedere 20-25 minuti o più, a seconda delle dimensioni del database di origine. Ciò può causare un aumento del ritardo di replica.

Alcuni tipi di dati non sono supportati. Per ulteriori informazioni, consulta Differenze tra i tipi di dati tra i database Aurora e Amazon Redshift.

Le tabelle di sistema, le tabelle temporanee e le viste non vengono replicate nei warehouse di destinazione.

L’esecuzione di comandi DDL (ad esempio ALTER TABLE) su una tabella di origine può attivare una risincronizzazione della tabella. Durante tale operazione non sarà possibile utilizzare la tabella per le query. Per ulteriori informazioni, consulta Una o più tabelle Amazon Redshift richiedono una risincronizzazione.

Il cluster di database di origine deve eseguire una versione supportata di Aurora MySQL. Per un elenco delle versioni supportate, consulta Regioni e motori di database Aurora supportati per le integrazioni Zero-ETL.

Le integrazioni Zero-ETL si basano sui log binari MySQL (binlog) per acquisire le modifiche continue dei dati. Il filtraggio dei dati basato su binlog è sconsigliato, poiché può causare incoerenze nei dati tra il database di origine e quello di destinazione.

Le integrazioni Zero-ETL sono supportate solo per i database configurati per l’utilizzo del motore di storage InnoDB.

I riferimenti a chiavi esterne con aggiornamenti di tabella predefiniti non sono supportati. In particolare, le regole ON DELETE e ON UPDATE non sono supportate nelle azioni CASCADE, SET NULL e SET DEFAULT. Se si tenta di creare o aggiornare una tabella con tali riferimenti a un’altra tabella, la tabella entrerà in uno stato di errore.

Le transazioni XA eseguite sul cluster di database di origine fanno sì che l’integrazione entri in uno stato di Syncing.

Il cluster di database di origine deve eseguire una versione supportata di Aurora PostgreSQL. Per un elenco delle versioni supportate, consulta Regioni e motori di database Aurora supportati per le integrazioni Zero-ETL.

Se selezioni un cluster di database di origine Aurora PostgreSQL, è necessario specificare almeno un modello di filtro dei dati. Come minimo, il modello deve includere un singolo database (database-name.*.*) per la replica nel warehouse di destinazione. Per ulteriori informazioni, consulta Filtro dei dati per integrazioni Zero-ETL di Aurora.

Tutti i database creati all’interno del cluster di database di origine Aurora PostgreSQL devono utilizzare la codifica UTF-8.

Quando utilizzi il partizionamento dichiarativo, le partizioni delle tabelle verranno replicate su Amazon Redshift. Tuttavia, la tabella partizionata stessa non viene replicata su Amazon Redshift.

Le transazioni in due fasi non sono supportate.

Se elimini tutte le istanze database da un cluster di database che è l’origine di un’integrazione e successivamente aggiungi di nuovo un’istanza database, la replica tra il cluster di origine e quello di destinazione si interrompe.

Il cluster di database di origine non può utilizzare Aurora Limitless Database.

Le chiavi primarie sono obbligatorie su tutte le tabelle presenti nel filtro dati. Tutte le tabelle senza una chiave primaria verranno messe nello stato di errore.

I nomi dei cataloghi hanno un limite di lunghezza di 19 caratteri.