Null-ETL-Integrationen von Aurora

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.

Der Quell-DB-Cluster muss sich in derselben Region befinden wie das Ziel.

Sie können einen DB-Cluster oder die zugehörigen Instances 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 einen DB-Cluster mit bestehenden Integrationen nicht löschen. Sie müssen zuerst alle zugehörigen Integrationen löschen.

Wenn Sie den Quell-DB-Cluster anhalten, werden die letzten Transaktionen möglicherweise erst dann in das Ziel repliziert, wenn Sie den Cluster fortsetzen.

Wenn der Cluster 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.

Ein DB-Cluster muss mindestens eine DB-Instance enthalten, um die Quelle einer Integration zu sein.

Sie können keine Integration für einen Quell-DB-Cluster erstellen, bei dem es sich um einen kontoübergreifenden Klon handelt, wie z. B. solche, die mit AWS Resource Access Manager ()AWS RAM gemeinsam genutzt werden.

Wenn der DB-Quell-Cluster in einer globalen Aurora-Datenbank verwendet wird und ein Failover zu einem der sekundären Cluster erfolgt, wird die Integration inaktiv. Sie müssen die Integration löschen und erneut erstellen.

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 Aurora 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.

Auf Ihrem Quell-DB-Cluster muss eine unterstützte Version von Aurora MySQL ausgeführt werden. Eine Liste der unterstützten Versionen finden Sie unter Unterstützte Regionen und Aurora-DB-Engines für Null-ETL-Integrationen.

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.

XA-Transaktionen, die auf dem Quell-DB-Cluster ausgeführt werden, führen dazu, dass die Integration in den Status Syncing wechselt.

Auf Ihrem Quell-DB-Cluster muss eine unterstützte Version von Aurora PostgreSQL ausgeführt werden. Eine Liste der unterstützten Versionen finden Sie unter Unterstützte Regionen und Aurora-DB-Engines für Null-ETL-Integrationen.

Wenn Sie einen Quell-DB-Cluster von Aurora PostgreSQL auswählen, müssen Sie mindestens ein Datenfiltermuster angeben. Das Muster muss mindestens eine einzelne Datenbank (database-name.*.*) für die Replikation in das Ziel-Warehouse enthalten. Weitere Informationen finden Sie unter Datenfilterung für Null-ETL-Integrationen für Aurora.

Alle Datenbanken, die im DB-Cluster von Aurora-PostgreSQL erstellt wurden, müssen UTF-8-Kodierung verwenden.

Bei Verwendung der deklarativen Partitionierung werden die Tabellenpartitionen in Amazon Redshift repliziert. Die partitionierte Tabelle selbst wird jedoch nicht in Amazon Redshift repliziert.

Zweiphasige Transaktionen werden nicht unterstützt.

Wenn Sie alle DB-Instances aus einem DB-Cluster löschen, der die Quelle einer Integration ist, und dann erneut eine DB-Instance hinzufügen, wird die Replikation zwischen dem Quell- und dem Ziel-Cluster unterbrochen.

Der Quell-DB-Cluster kann Aurora Limitless Database nicht verwenden.

Primärschlüssel sind für alle im Datenfilter vorhandenen Tabellen erforderlich. Alle Tabellen ohne Primärschlüssel werden in den Status „failed“ versetzt.

Katalognamen sind auf von 64 Zeichen beschränkt.