Intégrations Aurora Zero-ETL avec Amazon Redshift

Elles vous aident à dériver des informations holistiques de plusieurs sources de données.

Elles éliminent la nécessité de créer et de gérer des pipelines de données complexes qui effectuent des opérations d'extraction, de transformation et de chargement (ETL). Les intégrations zéro ETL suppriment les défis liés à la création et à la gestion de pipelines en les provisionnant et en les gérant pour vous.

Elles réduisent la charge opérationnelle et les coûts, et vous permettent de vous concentrer sur l'amélioration de vos applications.

Profitez des fonctionnalités d'analyse et de machine learning d'Amazon Redshift pour obtenir des informations à partir de données transactionnelles et autres, afin de répondre efficacement aux événements critiques et urgents.

Le cluster source doit se trouver dans la même région que l'entrepôt de données Amazon Redshift cible.

Vous ne pouvez pas renommer un cluster ou l'une de ses instances s'il possède des intégrations existantes.

Vous ne pouvez pas créer plusieurs intégrations entre les mêmes bases de données source et cible.

Vous ne pouvez pas supprimer un cluster de données doté d'intégrations existantes. Vous devez d’abord supprimer toutes les intégrations associées.

Si vous arrêtez le cluster de source, les dernières transactions risquent de ne pas être répliquées vers l'entrepôt de données cible tant que vous ne reprenez pas le cluster de .

Si votre cluster de données est à l'origine d'un déploiement bleu/vert, les environnements bleu et vert ne peuvent pas comporter d'intégrations zéro ETL existantes lors du passage au numérique. Vous devez d'abord supprimer l'intégration et basculer, puis la recréer.

Un cluster de base de données doit contenir au moins une instance de base de données pour être la source d'une intégration.

Vous ne pouvez pas créer d'intégration pour un cluster de base de données source qui est un clone entre comptes, tel que ceux partagés à l'aide de AWS Resource Access Manager (AWS RAM).

Si votre cluster source est le cluster de base de données principal d'une base de données globale Aurora et qu'il bascule sur l'un de ses clusters secondaires, l'intégration devient inactive. Vous devez supprimer et recréer l'intégration.

Vous ne pouvez pas créer d'intégration pour une base de données source dont une autre intégration est activement créée.

Lors de la création initiale d'une intégration ou lors de la resynchronisation d'une table, l'ensemencement des données de la source vers la cible peut prendre 20 à 25 minutes, voire plus, selon la taille de la base de données source. Ce délai peut entraîner une augmentation du délai de réplication.

Certains types de données ne sont pas pris en charge. Pour de plus amples informations, veuillez consulter Différences de type de données entre les bases de données Aurora et Amazon Redshift.

Les tables système, les tables temporaires et les vues ne sont pas répliquées sur Amazon Redshift.

ALTER TABLEles opérations de partition entraînent la resynchronisation de votre table afin de recharger les données d'Aurora vers Amazon Redshift. La table ne pourra pas être interrogée pendant la resynchronisation. Pour de plus amples informations, veuillez consulter Une ou plusieurs de mes tables Amazon Redshift nécessitent une resynchronisation.

Votre cluster de base de données source doit exécuter une version prise en charge d'Aurora MySQL. Pour une liste de versions prises en charge, consultez Régions prises en charge et moteurs de base de données Aurora pour les intégrations sans ETL avec Amazon Redshift.

Les intégrations zéro ETL s'appuient sur la journalisation binaire MySQL (binlog) pour capturer les modifications continues des données. N'utilisez pas le filtrage des données basé sur le binlog, car cela peut entraîner des incohérences entre les bases de données source et cible.

Les intégrations zéro ETL sont prises en charge uniquement pour les bases de données configurées pour utiliser le moteur de stockage InnoDB.

Les références de clé étrangère avec des mises à jour de table prédéfinies ne sont pas prises en charge. Plus précisément, ON DELETE les ON UPDATE règles ne sont pas prises en charge par CASCADESET NULL, et SET DEFAULT les actions. Toute tentative de création ou de mise à jour d'une table contenant de telles références à une autre table entraînera l'échec de la table.

Les transactions XA effectuées sur le cluster de base de données source font passer l'intégration à l'état deSyncing.

Votre cluster de base de données source doit exécuter une version prise en charge d'Aurora PostgreSQL. Pour une liste de versions prises en charge, consultez Régions prises en charge et moteurs de base de données Aurora pour les intégrations sans ETL avec Amazon Redshift.

Si vous sélectionnez un cluster de base de données source Aurora PostgreSQL, vous devez spécifier au moins un modèle de filtre de données. Le modèle doit au minimum inclure une seule base de données (database-name.*.*) pour la réplication vers Amazon Redshift. Pour de plus amples informations, veuillez consulter Filtrage des données pour les intégrations Aurora Zero-ETL avec Amazon Redshift.

Toutes les bases de données créées dans le cluster de base de données Aurora PostgreSQL source doivent utiliser le codage UTF-8.

Si vous effectuez des transactions de partitionnement déclaratif sur le cluster de base de données source, toutes les tables concernées entrent dans un état d'échec et ne sont plus accessibles dans Amazon Redshift.

Les transactions en deux phases ne sont pas prises en charge.

Si vous supprimez toutes les instances de base de données d'un cluster de base de données à l'origine d'une intégration, puis que vous ajoutez à nouveau une instance de base de données, la réplication est interrompue entre les clusters source et cible.

Le cluster de base de données source ne peut pas utiliser la base de données Aurora Limitless.