Null-ETL-Integrationen von Amazon RDS

Sie helfen Ihnen dabei, ganzheitliche Erkenntnisse aus mehreren Datenquellen zu gewinnen.

Eliminieren Sie die Erfordernis zur Erstellung und Verwaltung komplexer Daten-Pipelines, die Extract, Transform, Load (ETL)-Operationen ausführen. Null-ETL-Integrationen beseitigen die Herausforderungen, die mit dem Aufbau und der Verwaltung von Pipelines einhergehen, indem sie diese für Sie bereitstellen und verwalten.

Sie reduzieren den Betriebsaufwand und die Kosten, sodass Sie sich ganz auf die Verbesserung Ihrer Anwendungen konzentrieren können.

Sie ermöglichen die Nutzung der Analyse- und ML-Funktionen des Ziels zum Gewinnen von Erkenntnissen aus Transaktions- und anderen Daten, um effektiv auf (zeit-)kritische Ereignisse reagieren zu können.

Die Quelldatenbank muss sich in derselben Region befinden wie das Ziel.

Sie können eine Datenbank nicht umbenennen, wenn das Element über bestehende Integrationen verfügt.

Sie können nicht mehrere Integrationen zwischen derselben Quell- und Zieldatenbank erstellen.

Sie können eine Datenbank mit bestehenden Integrationen nicht löschen. Sie müssen zuerst alle zugehörigen Integrationen löschen.

Wenn Sie die Quelldatenbank anhalten, werden die letzten Transaktionen möglicherweise erst dann in das Ziel repliziert, wenn Sie die Datenbank fortsetzen.

Sie können eine Integration nicht löschen, wenn die Quelldatenbank angehalten ist.

Wenn die Datenbank die Quelle einer Blau/Grün-Bereitstellung ist, können die blaue und die grüne Umgebung während der Umstellung keine vorhandenen Null-ETL-Integrationen haben. Sie müssen zuerst die Integration löschen und umstellen. Anschließend erstellen Sie die Integration neu.

Sie können keine Integration für eine Quelldatenbank erstellen, für die aktiv eine andere Integration erstellt wird.

Wenn Sie zum ersten Mal eine Integration erstellen oder wenn eine Tabelle erneut synchronisiert wird, kann das Seeding von Daten von der Quelle zum Ziel je nach Größe der Quelldatenbank 20 bis 25 Minuten oder länger dauern. Diese Verzögerung kann zu einer erhöhten Replikatverzögerung führen.

Einige Datentypen werden nicht unterstützt. Weitere Informationen finden Sie unter Datentypunterschiede zwischen RDS und Amazon Redshift-Datenbanken.

Systemtabellen, temporäre Tabellen und Ansichten werden nicht in Ziel-Warehouses repliziert.

Das Ausführen von DDL-Befehlen (z. B. ALTER TABLE) für eine Quelltabelle kann eine erneute Synchronisierung der Tabelle auslösen, wobei die Tabelle während der erneuten Synchronisierung nicht mehr abgefragt werden kann. Weitere Informationen finden Sie unter Eine oder mehrere meiner Amazon-Redshift-Tabellen erfordern eine erneute Synchronisation.

In Ihrer Quelldatenbank muss eine unterstützte Version von RDS für MySQL ausgeführt werden. Eine Liste der unterstützten Versionen finden Sie unter Unterstützte Regionen und DB-Engines für Amazon-RDS-Null-ETL-Integrationen.

Zero-ETL-Integrationen werden nicht sowohl auf der primären Instance als auch auf einer Read Replica-Instance in derselben Region unterstützt. AWS

Null-ETL-Integrationen benötigen die MySQL-Binärprotokollierung (Binlog), um laufende Datenänderungen zu erfassen. Verwenden Sie keine Binlog-basierte Datenfilterung, da dies zu Dateninkonsistenzen zwischen der Quell- und der Zieldatenbank führen kann.

Null-ETL-Integrationen werden nur für Datenbanken unterstützt, die für die Verwendung der InnoDB-Speicher-Engine konfiguriert sind.

Fremdschlüsselverweise mit vordefinierten Tabellenaktualisierungen werden nicht unterstützt. Insbesondere werden ON DELETE- und ON UPDATE-Regeln mit CASCADE-, SET NULL- und SET DEFAULT-Aktionen nicht unterstützt. Der Versuch, eine Tabelle mit solchen Verweisen in einer anderen Tabelle zu erstellen oder zu aktualisieren, führt zu einem Fehlschlag der Tabelle.

Sie können keine Integration für eine Quelldatenbank erstellen, die Magnetspeicher verwendet.

Die Quelldatenbank muss eine Instance von RDS für PostgreSQL mit Version 15.7+, 16.3+ oder 17.1+ sein. Frühere Versionen werden nicht unterstützt.

Zero-ETL-Integrationen von RDS für PostgreSQL unterstützen keine Multi-AZ-DB-Cluster als Quelldatenbanken.

Sie können keine Null-ETL-Integration aus einer Lesereplikat-Instance von RDS für PostgreSQL erstellen.

Nicht protokollierte PostgreSQL-Tabellen und materialisierte Ansichten werden nicht in Amazon Redshift repliziert.

Die Replikation bestimmter PostgreSQL-Datentypen wie Geometriedatentypen und Daten mit mehr als 64 KB wird aufgrund von Einschränkungen in Amazon Redshift nicht unterstützt. Weitere Informationen zu den Datentypunterschieden zwischen RDS für PostgreSQL und Amazon Redshift finden Sie unter RDS für PostgreSQL im Abschnitt Datentypunterschiede.

Sie können kein Hauptversion-Upgrade für die Quell-Instance von RDS für PostgreSQL durchführen, solange sie über eine aktive Null-ETL-Integration verfügt. Um die Quell-Instance zu aktualisieren, müssen Sie zunächst alle vorhandenen Null-ETL-Integrationen löschen. Nachdem das Hauptversion-Upgrade abgeschlossen ist, können Sie die Null-ETL-Integrationen erneut erstellen.

Wenn Sie deklarative Partitionierungstransaktionen auf der Quell-DB-Instance durchführen, gehen alle betroffenen Tabellen in den Status „failed“ über und sind nicht mehr abrufbar.

Bei der Quelldatenbank muss es sich um eine Instance von RDS für Oracle handeln, auf der Version 19c Enterprise Edition oder Standard Edition 2, Versionsupdate vom Juli 2019 oder später ausgeführt wird. Frühere Versionen werden nicht unterstützt.

Sie können keine Null-ETL-Integration aus einer Lesereplikat-Instance von RDS für Oracle erstellen.

Sie können eine Tenant-Datenbank nicht umbenennen, wenn in dieser Tenant-Datenbank eine Null-ETL-Integration vorhanden ist.

Eine Tenant-Datenbank kann nur eine Null-ETL-Integration haben.

RDS für Oracle und Amazon Redshift weisen einige Datentypunterschiede auf. Weitere Informationen finden Sie unter RDS für Oracle im Abschnitt Unterschiede zwischen Datentypen.

Katalognamen sind auf von 64 Zeichen beschränkt.