Integrazioni Zero-ETL di Amazon RDS

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 database di origine deve trovarsi nella stessa Regione della destinazione.

Non è possibile rinominare un database se include integrazioni esistenti.

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

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

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

Non è possibile eliminare un’integrazione se il database di origine viene arrestato.

Se il database è 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.

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 RDS 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 database di origine deve eseguire una versione supportata di RDS per MySQL. Per un elenco delle versioni supportate, consulta Regioni e motori di database supportati per le integrazioni Zero-ETL di Amazon RDS.

Le integrazioni zero-ETL non sono supportate sia sull'istanza principale che su un'istanza di replica di lettura nella stessa regione. AWS

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.

Non è possibile creare un'integrazione per un database di origine che utilizza l'archiviazione magnetica.

Il database di origine deve essere un’istanza RDS per PostgreSQL che esegue la versione 15.7+, 16.3+ o 17.1+. Le versioni precedenti non sono supportate.

Le integrazioni Zero-ETL di RDS per PostgreSQL non supportano i cluster DB Multi-AZ come database di origine.

Non è possibile creare un’integrazione Zero-ETL da un’istanza di replica di lettura di RDS per PostgreSQL.

Le viste materializzate e le tabelle non registrate di PostgreSQL non vengono replicate su Amazon Redshift.

La replica di determinati tipi di dati PostgreSQL, ad esempio i tipi di dati di geometria e i dati con dimensioni superiori a 64 KB, non è supportata a causa delle limitazioni di Amazon Redshift. Per ulteriori informazioni sulle differenze dei tipi di dati tra RDS per PostgreSQL e Amazon Redshift, consulta l’articolo RDS per PostgreSQL nella sezione Differenze tra i tipi di dati.

Non è possibile eseguire un aggiornamento a una versione principale sull’istanza RDS per PostgreSQL di origine se è presente un’integrazione Zero-ETL attiva. Per aggiornare l’istanza di origine, è necessario eliminare prima tutte le integrazioni Zero-ETL. Al termine dell’aggiornamento alla versione principale, è possibile ricreare le integrazioni Zero-ETL.

Se esegui transazioni di partizionamento dichiarativo sull’istanza del database di origine, tutte le tabelle interessate entrano in uno stato di errore e non sono più accessibili.

Il database di origine deve essere un’istanza di RDS per Oracle che esegue la versione 19c Enterprise Edition o Standard Edition 2, aggiornamento della versione di luglio 2019 o successiva. Le versioni precedenti non sono supportate.

Non è possibile creare un’integrazione Zero-ETL da un’istanza di replica di lettura di RDS per Oracle.

Non è possibile rinominare un database del tenant se su tale database esiste un’integrazione zero-ETL.

Un database del tenant può avere una sola integrazione Zero-ETL.

Quando crei un’integrazione zero-ETL da RDS per Oracle, non puoi modificare tale integrazione. Per modificare un’integrazione, devi eliminarla e crearne una nuova.

RDS per Oracle e Amazon Redshift presentano alcune differenze tra i tipi di dati. Per ulteriori informazioni, consulta RDS per Oracle nella sezione Differenze tra i tipi di dati.

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