Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
Résolution des problèmes liés aux intégrations zéro ETL
Utilisez les sections suivantes pour résoudre les problèmes que vous rencontrez avec les intégrations Zero-ETL.
Utilisez les informations suivantes pour résoudre les problèmes courants liés aux intégrations zéro ETL avec Aurora MySQL.
Rubriques
Les tables Aurora MySQL ne se répliquent pas vers Amazon Redshift
Les modifications suivies entre les sources de données ne correspondent pas
Le nombre de tables est supérieur à 100 000 ou le nombre de schémas est supérieur à 4 950
La base de données n’est pas créée pour activer une intégration zéro ETL
Table dans l’état Resynchronisation requise ou Resynchronisation initiée
Échec de la création de l’intégration
Si la création de l’intégration zéro ETL a échoué, le statut de l’intégration est Inactive
. Assurez-vous que les informations suivantes sont correctes pour votre cluster de bases de données Aurora source :
-
Vous avez créé votre cluster dans la console Amazon RDS.
-
Votre cluster de base de données Aurora source exécute une version prise en charge. Pour obtenir la liste des 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. Pour le vérifier, accédez à l’onglet Configuration du cluster et vérifiez la Version du moteur.
-
Vous avez correctement configuré les paramètres binlog pour votre cluster. Si les paramètres binlog d’Aurora MySQL ne sont pas définis correctement ou s’ils ne sont pas associés au cluster de bases de données Aurora source, la création échoue. Consultez Configuration des paramètres du cluster de bases de données.
En outre, assurez-vous que les informations suivantes sont correctes pour votre entrepôt des données Amazon Redshift :
-
La sensibilité à la casse est activée. Consultez Activation de la sensibilité à la casse pour votre entrepôt des données.
-
Vous avez ajouté le principal autorisé et la source d’intégration appropriés pour votre espace de noms. Consultez Configuration de l’autorisation pour votre entrepôt des données Amazon Redshift.
Les tables ne possèdent pas de clés primaires
Dans la base de données de destination, une ou plusieurs tables ne possèdent pas de clé primaire et ne peuvent pas être synchronisées.
Pour résoudre ce problème, accédez à l’onglet Statistiques de table sur la page des détails de l’intégration ou utilisez SVV_INTEGRATION_TABLE_STATE pour afficher les tables ayant échoué. Vous pouvez ajouter des clés primaires aux tables et Amazon Redshift resynchronisera les tables. Bien que cela ne soit pas recommandé, vous pouvez supprimer ces tables sur Aurora et créer des tables avec une clé primaire. Pour plus d’informations, consultez Bonnes pratiques Amazon Redshift pour la conception de tables.
Les tables Aurora MySQL ne se répliquent pas vers Amazon Redshift
Si aucune ou plusieurs tables ne sont reflétées dans Amazon Redshift, vous pouvez exécuter la commande suivante pour les resynchroniser. dbname
Remplacez-le par le nom de votre base de données Amazon Redshift. Et remplacez table1
et table2
par les noms des tables à synchroniser.
ALTER DATABASE
dbname
INTEGRATION REFRESH TABLEStable1
,table2
;
Pour plus d'informations, consultez ALTER DATABASE dans le manuel Amazon Redshift Database Developer Guide.
Vos données ne sont peut-être pas répliquées car une ou plusieurs de vos tables sources ne possèdent pas de clé primaire. Le tableau de bord de surveillance d'Amazon Redshift affiche l'état de ces tables au fur Failed
et à mesure que le statut de l'intégration Zero-ETL globale passe à. Needs
attention
Pour résoudre ce problème, vous pouvez identifier une clé existante dans votre table qui peut devenir une clé primaire, ou vous pouvez ajouter une clé primaire synthétique. Pour des solutions détaillées, consultez Gérer les tables sans clés primaires lors de la création d'intégrations Amazon Aurora MySQL ou RDS for MySQL Zero-ETL avec Amazon Redshift
Vérifiez également que si votre cible est un cluster Amazon Redshift, le cluster n'est pas suspendu.
Types de données non pris en charge dans les tables
Dans la base de données que vous avez créée à partir de l’intégration dans Amazon Redshift et dans laquelle les données sont répliquées à partir du cluster de bases de données Aurora, une ou plusieurs tables contiennent des types de données non pris en charge et ne peuvent pas être synchronisées.
Pour résoudre ce problème, accédez à l’onglet Statistiques de table sur la page des détails de l’intégration ou utilisez SVV_INTEGRATION_TABLE_STATE pour afficher les tables ayant échoué. Supprimez ensuite ces tables et recréez de nouvelles tables dans Amazon RDS. Pour plus d’informations sur les types de données non pris en charge, consultez Différences de type de données entre les bases de données Aurora et Amazon Redshift dans le Guide de l’utilisateur Amazon Aurora.
Échec des commandes en langage de manipulation de données
Amazon Redshift n’a pas pu exécuter de commandes DML sur les tables Redshift. Pour résoudre ce problème, utilisez SVV_INTEGRATION_TABLE_STATE pour afficher les tables ayant échoué. Amazon Redshift resynchronise automatiquement les tables pour résoudre cette erreur.
Les modifications suivies entre les sources de données ne correspondent pas
Cette erreur se produit lorsque les modifications entre Amazon Aurora et Amazon Redshift ne correspondent pas, ce qui bascule l’intégration à l’état Failed
.
Pour résoudre ce problème, supprimez l’intégration zéro ETL et créez-la à nouveau dans Amazon RDS. Pour plus d’informations, consultez Création d’intégrations zéro ETL et Suppression d’intégrations zéro ETL.
Échec d’autorisation
L’autorisation a échoué, car le cluster de bases de données Aurora source a été supprimé en tant que source d’intégration autorisée pour l’entrepôt des données Amazon Redshift.
Pour résoudre ce problème, supprimez l’intégration zéro ETL et créez-la à nouveau dans Amazon RDS. Pour plus d’informations, consultez Création d’intégrations zéro ETL et Suppression d’intégrations zéro ETL.
Le nombre de tables est supérieur à 100 000 ou le nombre de schémas est supérieur à 4 950
Pour un entrepôt des données de destination, le nombre de tables est supérieur à 100 000 ou le nombre de schémas est supérieur à 4 950. Amazon Aurora ne peut pas envoyer de données à Amazon Redshift. Le nombre de tables et de schémas dépasse la limite définie. Pour résoudre ce problème, supprimez tous les schémas ou tables inutiles de la base de données source.
Amazon Redshift ne peut pas charger les données
Amazon Redshift ne peut pas charger de données dans l’intégration zéro ETL.
Pour résoudre ce problème, supprimez l’intégration zéro ETL dans Amazon RDS et créez-la à nouveau. Pour plus d’informations, consultez Création d’intégrations zéro ETL et Suppression d’intégrations zéro ETL.
Les paramètres du groupe de travail sont incorrects
La sensibilité à la casse n’est pas activée dans votre groupe de travail.
Pour résoudre ce problème, accédez à l’onglet Propriétés sur la page des détails de l’intégration, choisissez le groupe de paramètres et activez l’identifiant sensible à la casse dans l’onglet Propriétés. Si vous n’avez pas de groupe de paramètres existant, créez-en un en activant l’identifiant sensible à la casse. Créez ensuite une nouvelle intégration zéro ETL dans Amazon RDS. Pour plus d’informations, consultez Création d’intégrations zéro ETL.
La base de données n’est pas créée pour activer une intégration zéro ETL
Aucune base de données n’a été créée pour activer l’intégration zéro ETL.
Pour résoudre ce problème, créez une base de données pour l’intégration. Pour de plus amples informations, veuillez consulter Création de bases de données de destination dans Amazon Redshift.
Table dans l’état Resynchronisation requise ou Resynchronisation initiée
Votre table est dans l’état Resynchronisation requise ou Resynchronisation initiée.
Pour recueillir des informations d’erreur plus détaillées sur les raisons pour lesquelles votre table est dans cet état, utilisez la vue système SYS_LOAD_ERROR_DETAIL.
Le retard d'intégration augmente
Le délai d'intégration de vos intégrations sans ETL peut augmenter en cas d'utilisation intensive de SAVEPOINT dans votre base de données source.
Utilisez les informations suivantes pour résoudre les problèmes courants liés aux intégrations zéro ETL avec Aurora PostgreSQL.
Rubriques
Les tables Aurora PostgreSQL ne sont pas répliquées vers Amazon Redshift
Les modifications suivies entre les sources de données ne correspondent pas
Le nombre de tables est supérieur à 100 000 ou le nombre de schémas est supérieur à 4 950
La base de données n’est pas créée pour activer une intégration zéro ETL
Table dans l’état Resynchronisation requise ou Resynchronisation initiée
Échec de la création de l’intégration
Si la création de l’intégration zéro ETL a échoué, le statut de l’intégration est Inactive
. Assurez-vous que les informations suivantes sont correctes pour votre cluster de bases de données Aurora source :
-
Vous avez créé votre cluster dans la console Amazon RDS.
-
Votre cluster de base de données Aurora source exécute une version prise en charge. Pour obtenir la liste des 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. Pour le vérifier, accédez à l’onglet Configuration du cluster et vérifiez la Version du moteur.
-
Vous avez correctement configuré les paramètres binlog pour votre cluster. Si les paramètres binlog d’Aurora PostgreSQL ne sont pas définis correctement ou s’ils ne sont pas associés au cluster de bases de données Aurora source, la création échoue. Consultez Configuration des paramètres du cluster de bases de données.
En outre, assurez-vous que les informations suivantes sont correctes pour votre entrepôt des données Amazon Redshift :
-
La sensibilité à la casse est activée. Consultez Activation de la sensibilité à la casse pour votre entrepôt des données.
-
Vous avez ajouté le principal autorisé et la bonne source d'intégration pour votre endterm= » zero-etl-using .redshift-iam.title » />.
Les tables ne possèdent pas de clés primaires
Dans la base de données de destination, une ou plusieurs tables ne possèdent pas de clé primaire et ne peuvent pas être synchronisées.
Pour résoudre ce problème, accédez à l’onglet Statistiques de table sur la page des détails de l’intégration ou utilisez SVV_INTEGRATION_TABLE_STATE pour afficher les tables ayant échoué. Vous pouvez ajouter des clés primaires aux tables et Amazon Redshift resynchronisera les tables. Bien que cela ne soit pas recommandé, vous pouvez supprimer ces tables sur Aurora et créer des tables avec une clé primaire. Pour plus d’informations, consultez Bonnes pratiques Amazon Redshift pour la conception de tables.
Les tables Aurora PostgreSQL ne sont pas répliquées vers Amazon Redshift
Si aucune ou plusieurs tables ne sont reflétées dans Amazon Redshift, vous pouvez exécuter la commande suivante pour les resynchroniser. dbname
Remplacez-le par le nom de votre base de données Amazon Redshift. Et remplacez table1
et table2
par les noms des tables à synchroniser.
ALTER DATABASE
dbname
INTEGRATION REFRESH TABLEStable1
,table2
;
Pour plus d'informations, consultez ALTER DATABASE dans le manuel Amazon Redshift Database Developer Guide.
Vos données ne sont peut-être pas répliquées car une ou plusieurs de vos tables sources ne possèdent pas de clé primaire. Le tableau de bord de surveillance d'Amazon Redshift affiche l'état de ces tables au fur Failed
et à mesure que le statut de l'intégration Zero-ETL globale passe à. Needs
attention
Pour résoudre ce problème, vous pouvez identifier une clé existante dans votre table qui peut devenir une clé primaire, ou vous pouvez ajouter une clé primaire synthétique. Pour des solutions détaillées, consultez Gérer les tables sans clés primaires lors de la création d'intégrations Amazon Aurora PostgreSQL Zero-ETL
Vérifiez également que si votre cible est un cluster Amazon Redshift, le cluster n'est pas suspendu.
Types de données non pris en charge dans les tables
Dans la base de données que vous avez créée à partir de l’intégration dans Amazon Redshift et dans laquelle les données sont répliquées à partir du cluster de bases de données Aurora, une ou plusieurs tables contiennent des types de données non pris en charge et ne peuvent pas être synchronisées.
Pour résoudre ce problème, accédez à l’onglet Statistiques de table sur la page des détails de l’intégration ou utilisez SVV_INTEGRATION_TABLE_STATE pour afficher les tables ayant échoué. Supprimez ensuite ces tables et recréez de nouvelles tables dans Amazon RDS. Pour plus d’informations sur les types de données non pris en charge, consultez Différences de type de données entre les bases de données Aurora et Amazon Redshift dans le Guide de l’utilisateur Amazon Aurora.
Échec des commandes en langage de manipulation de données
Amazon Redshift n’a pas pu exécuter de commandes DML sur les tables Redshift. Pour résoudre ce problème, utilisez SVV_INTEGRATION_TABLE_STATE pour afficher les tables ayant échoué. Amazon Redshift resynchronise automatiquement les tables pour résoudre cette erreur.
Les modifications suivies entre les sources de données ne correspondent pas
Cette erreur se produit lorsque les modifications entre Amazon Aurora et Amazon Redshift ne correspondent pas, ce qui bascule l’intégration à l’état Failed
.
Pour résoudre ce problème, supprimez l’intégration zéro ETL et créez-la à nouveau dans Amazon RDS. Pour plus d’informations, consultez Création d’intégrations zéro ETL et Suppression d’intégrations zéro ETL.
Échec d’autorisation
L’autorisation a échoué, car le cluster de bases de données Aurora source a été supprimé en tant que source d’intégration autorisée pour l’entrepôt des données Amazon Redshift.
Pour résoudre ce problème, supprimez l’intégration zéro ETL et créez-la à nouveau dans Amazon RDS. Pour plus d’informations, consultez Création d’intégrations zéro ETL et Suppression d’intégrations zéro ETL.
Le nombre de tables est supérieur à 100 000 ou le nombre de schémas est supérieur à 4 950
Pour un entrepôt des données de destination, le nombre de tables est supérieur à 100 000 ou le nombre de schémas est supérieur à 4 950. Amazon Aurora ne peut pas envoyer de données à Amazon Redshift. Le nombre de tables et de schémas dépasse la limite définie. Pour résoudre ce problème, supprimez tous les schémas ou tables inutiles de la base de données source.
Amazon Redshift ne peut pas charger les données
Amazon Redshift ne peut pas charger de données dans l’intégration zéro ETL.
Pour résoudre ce problème, supprimez l’intégration zéro ETL dans Amazon RDS et créez-la à nouveau. Pour plus d’informations, consultez Création d’intégrations zéro ETL et Suppression d’intégrations zéro ETL.
Les paramètres du groupe de travail sont incorrects
La sensibilité à la casse n’est pas activée dans votre groupe de travail.
Pour résoudre ce problème, accédez à l’onglet Propriétés sur la page des détails de l’intégration, choisissez le groupe de paramètres et activez l’identifiant sensible à la casse dans l’onglet Propriétés. Si vous n’avez pas de groupe de paramètres existant, créez-en un en activant l’identifiant sensible à la casse. Créez ensuite une nouvelle intégration zéro ETL dans Amazon RDS. Pour plus d’informations, consultez Création d’intégrations zéro ETL.
La base de données n’est pas créée pour activer une intégration zéro ETL
Aucune base de données n’a été créée pour activer l’intégration zéro ETL.
Pour résoudre ce problème, créez une base de données pour l’intégration. Pour de plus amples informations, veuillez consulter Création de bases de données de destination dans Amazon Redshift.
Table dans l’état Resynchronisation requise ou Resynchronisation initiée
Votre table est dans l’état Resynchronisation requise ou Resynchronisation initiée.
Pour recueillir des informations d’erreur plus détaillées sur les raisons pour lesquelles votre table est dans cet état, utilisez la vue système SYS_LOAD_ERROR_DETAIL.
Utilisez les informations suivantes pour résoudre les problèmes courants liés aux intégrations zéro ETL à RDS for MySQL.
Rubriques
Les tables RDS pour MySQL ne sont pas répliquées vers Amazon Redshift
Les modifications suivies entre les sources de données ne correspondent pas
Le nombre de tables est supérieur à 100 000 ou le nombre de schémas est supérieur à 4 950
La base de données n’est pas créée pour activer une intégration zéro ETL
Table dans l’état Resynchronisation requise ou Resynchronisation initiée
Échec de la création de l’intégration
Si la création de l’intégration zéro ETL a échoué, le statut de l’intégration est Inactive
. Assurez-vous que les informations suivantes sont correctes pour votre instance de base de données RDS source :
-
Vous avez créé votre instance dans la console Amazon RDS.
-
Votre instance de base de données RDS source exécute une version prise en charge de RDS pour MySQL. Pour obtenir la liste des versions prises en charge, consultez Régions prises en charge et moteurs de base de données pour les intégrations Amazon RDS Zero-ETL avec Amazon Redshift. Pour vérifier cela, accédez à l’onglet Configuration de l’instance et vérifiez la version du moteur.
-
Vous avez correctement configuré les paramètres binlog pour votre instance. Si les paramètres binlog de RDS for MySQL ne sont pas définis correctement ou s’ils ne sont pas associés à l’instance de base de données RDS source, la création échoue. Consultez Configuration des paramètres de l’instance de base de données.
En outre, assurez-vous que les informations suivantes sont correctes pour votre entrepôt des données Amazon Redshift :
-
La sensibilité à la casse est activée. Consultez Activation de la sensibilité à la casse pour votre entrepôt des données.
-
Vous avez ajouté le principal autorisé et la source d’intégration appropriés pour votre espace de noms. Consultez Configuration de l’autorisation pour votre entrepôt des données Amazon Redshift.
Les tables ne possèdent pas de clés primaires
Dans la base de données de destination, une ou plusieurs tables ne possèdent pas de clé primaire et ne peuvent pas être synchronisées.
Pour résoudre ce problème, accédez à l’onglet Statistiques de table sur la page des détails de l’intégration ou utilisez SVV_INTEGRATION_TABLE_STATE pour afficher les tables ayant échoué. Vous pouvez ajouter des clés primaires aux tables et Amazon Redshift resynchronisera les tables. Bien que cela ne soit pas recommandé, vous pouvez également supprimer ces tables sur RDS et créer des tables avec une clé primaire. Pour plus d’informations, consultez Bonnes pratiques Amazon Redshift pour la conception de tables.
Les tables RDS pour MySQL ne sont pas répliquées vers Amazon Redshift
Si aucune ou plusieurs tables ne sont reflétées dans Amazon Redshift, vous pouvez exécuter la commande suivante pour les resynchroniser. dbname
Remplacez-le par le nom de votre base de données Amazon Redshift. Et remplacez table1
et table2
par les noms des tables à synchroniser.
ALTER DATABASE
dbname
INTEGRATION REFRESH TABLEStable1
,table2
;
Pour plus d'informations, consultez ALTER DATABASE dans le manuel Amazon Redshift Database Developer Guide.
Vos données ne sont peut-être pas répliquées car une ou plusieurs de vos tables sources ne possèdent pas de clé primaire. Le tableau de bord de surveillance d'Amazon Redshift affiche l'état de ces tables au fur Failed
et à mesure que le statut de l'intégration Zero-ETL globale passe à. Needs
attention
Pour résoudre ce problème, vous pouvez identifier une clé existante dans votre table qui peut devenir une clé primaire, ou vous pouvez ajouter une clé primaire synthétique. Pour des solutions détaillées, consultez Gérer les tables sans clés primaires lors de la création d'intégrations Aurora MySQL Compatible Edition ou RDS for MySQL Zero-ETL
Vérifiez également que si votre cible est un cluster Amazon Redshift, le cluster n'est pas suspendu.
Types de données non pris en charge dans les tables
Dans la base de données que vous avez créée à partir de l’intégration dans Amazon Redshift et dans laquelle les données sont répliquées à partir de l’instance de base de données RDS, une ou plusieurs tables contiennent des types de données non pris en charge et ne peuvent pas être synchronisées.
Pour résoudre ce problème, accédez à l’onglet Statistiques de table sur la page des détails de l’intégration ou utilisez SVV_INTEGRATION_TABLE_STATE pour afficher les tables ayant échoué. Supprimez ensuite ces tables et recréez de nouvelles tables dans Amazon RDS. Pour plus d’informations sur les types de données non pris en charge, consultez Différences de type de données entre les bases de données RDS et Amazon Redshift dans le Guide de l’utilisateur Amazon RDS.
Échec des commandes en langage de manipulation de données
Amazon Redshift n’a pas pu exécuter de commandes DML sur les tables Redshift. Pour résoudre ce problème, utilisez SVV_INTEGRATION_TABLE_STATE pour afficher les tables ayant échoué. Amazon Redshift resynchronise automatiquement les tables pour résoudre cette erreur.
Les modifications suivies entre les sources de données ne correspondent pas
Cette erreur se produit lorsque les modifications entre Amazon Aurora et Amazon Redshift ne correspondent pas, ce qui bascule l’intégration à l’état Failed
.
Pour résoudre ce problème, supprimez l’intégration zéro ETL et créez-la à nouveau dans Amazon RDS. Pour plus d’informations, consultez Création d’intégrations zéro ETL et Suppression d’intégrations zéro ETL.
Échec d’autorisation
L’autorisation a échoué, car l’instance de base de données RDS source a été supprimée en tant que source d’intégration autorisée pour l’entrepôt des données Amazon Redshift.
Pour résoudre ce problème, supprimez l’intégration zéro ETL et créez-la à nouveau dans Amazon RDS. Pour plus d’informations, consultez Création d’intégrations zéro ETL et Suppression d’intégrations zéro ETL.
Le nombre de tables est supérieur à 100 000 ou le nombre de schémas est supérieur à 4 950
Pour un entrepôt des données de destination, le nombre de tables est supérieur à 100 000 ou le nombre de schémas est supérieur à 4 950. Amazon Aurora ne peut pas envoyer de données à Amazon Redshift. Le nombre de tables et de schémas dépasse la limite définie. Pour résoudre ce problème, supprimez tous les schémas ou tables inutiles de la base de données source.
Amazon Redshift ne peut pas charger les données
Amazon Redshift ne peut pas charger de données dans l’intégration zéro ETL.
Pour résoudre ce problème, supprimez l’intégration zéro ETL dans Amazon RDS et créez-la à nouveau. Pour plus d’informations, consultez Création d’intégrations zéro ETL et Suppression d’intégrations zéro ETL.
Les paramètres du groupe de travail sont incorrects
La sensibilité à la casse n’est pas activée dans votre groupe de travail.
Pour résoudre ce problème, accédez à l’onglet Propriétés sur la page des détails de l’intégration, choisissez le groupe de paramètres et activez l’identifiant sensible à la casse dans l’onglet Propriétés. Si vous n’avez pas de groupe de paramètres existant, créez-en un en activant l’identifiant sensible à la casse. Créez ensuite une nouvelle intégration zéro ETL dans Amazon RDS. Pour plus d’informations, consultez Création d’intégrations zéro ETL.
La base de données n’est pas créée pour activer une intégration zéro ETL
Aucune base de données n’a été créée pour activer l’intégration zéro ETL.
Pour résoudre ce problème, créez une base de données pour l’intégration. Pour de plus amples informations, veuillez consulter Création de bases de données de destination dans Amazon Redshift.
Table dans l’état Resynchronisation requise ou Resynchronisation initiée
Votre table est dans l’état Resynchronisation requise ou Resynchronisation initiée.
Pour recueillir des informations d’erreur plus détaillées sur les raisons pour lesquelles votre table est dans cet état, utilisez la vue système SYS_LOAD_ERROR_DETAIL.
Utilisez les informations suivantes pour résoudre les problèmes courants liés aux intégrations sans ETL avec Amazon DynamoDB.
Rubriques
Échec de la création de l’intégration
Si la création de l’intégration zéro ETL a échoué, le statut de l’intégration est Inactive
. Assurez-vous que les informations suivantes sont correctes pour votre entrepôt de données Amazon Redshift et votre table source DynamoDB :
-
La distinction majuscules/minuscules est activée pour votre entrepôt de données. Consultez la section Activer la distinction majuscules/minuscules dans le guide de gestion Amazon Redshift.
-
Vous avez ajouté le principal autorisé et la bonne source d'intégration pour votre espace de noms dans Amazon Redshift. Consultez la section Configurer l'autorisation pour votre entrepôt de données Amazon Redshift dans le guide de gestion Amazon Redshift.
-
Vous avez ajouté la bonne stratégie basée sur les ressources à la table DynamoDB source. Consultez la section Politiques et autorisations dans IAM dans le guide de l'utilisateur d'IAM.
Types de données non pris en charge dans les tables
Les numéros DynamoDB sont convertis en décimal (38,10) dans Amazon Redshift. Les nombres dépassant cette plage de précision sont automatiquement transformés en (38,10). Supprimez l'intégration et unifiez les précisions numériques, puis recréez l'intégration.
Noms de table et d'attribut non pris en charge
Amazon Redshift prend en charge jusqu'à 127 noms de table et d'attribut de caractères. Si un nom long, tel que le nom de table DynamoDB ou le nom de colonne de clé de partition ou de clé de tri, échoue lors de votre intégration, corrigez-le en utilisant un nom plus court et recréez l'intégration.
Échec d’autorisation
L'autorisation peut échouer lorsque la table DynamoDB source est supprimée en tant que source d'intégration autorisée pour l'entrepôt de données Amazon Redshift.
Pour résoudre ce problème, supprimez l'intégration Zero-ETL et recréez-la à l'aide d'Amazon DynamoDB.
Amazon Redshift ne peut pas charger les données
Amazon Redshift ne peut pas charger de données à partir d'une intégration zéro ETL.
Pour résoudre ce problème, actualisez l'intégration avec ALTER DATABASE.
ALTER DATABASE
sample_integration_db
INTEGRATION REFRESH ALL TABLES
Les paramètres du groupe de travail ou du cluster sont incorrects
La distinction majuscules/minuscules n'est pas activée dans votre groupe de travail ou cluster.
Pour résoudre ce problème, accédez à l’onglet Propriétés sur la page des détails de l’intégration, choisissez le groupe de paramètres et activez l’identifiant sensible à la casse dans l’onglet Propriétés. Si vous n’avez pas de groupe de paramètres existant, créez-en un en activant l’identifiant sensible à la casse. Créez ensuite une nouvelle intégration Zero-ETL sur DynamoDB. Consultez la section Activer la distinction majuscules/minuscules dans le guide de gestion Amazon Redshift.
La base de données n’est pas créée pour activer une intégration zéro ETL
Aucune base de données n’a été créée pour activer l’intégration zéro ETL.
Pour résoudre ce problème, créez une base de données pour l’intégration. Consultez la section Création de bases de données de destination dans Amazon Redshift dans le guide de gestion Amazon Redshift.
Point-in-time la restauration (PITR) n'est pas activée sur la table DynamoDB source
L'activation du PITR est nécessaire pour que DynamoDB puisse exporter des données. Assurez-vous que le PITR est toujours activé. Si vous désactivez le PITR alors que l'intégration est active, vous devrez suivre les instructions du message d'erreur et actualiser l'intégration à l'aide d'ALTER DATABASE.
ALTER DATABASE
sample_integration_db
INTEGRATION REFRESH ALL TABLES
Accès à la clé KMS refusé
La clé KMS utilisée pour la table source ou l'intégration doit être configurée avec des autorisations suffisantes. Pour plus d'informations sur le chiffrement et le déchiffrement des tables, consultez la section Chiffrement DynamoDB au repos dans le manuel du développeur Amazon DynamoDB.
Amazon Redshift n'a pas accès à la clé de table DynamoDB
Si le chiffrement de la table source est un Clé gérée par AWS, passez à une clé gérée par le client Clé détenue par AWS ou une clé gérée par le client. Si la table est déjà chiffrée avec une clé gérée par le client, assurez-vous que la politique ne comporte aucune clé de condition.
Utilisez les informations suivantes pour résoudre les problèmes courants liés aux intégrations sans ETL avec des applications telles que Salesforce ServiceNow, SAP et Zendesk.
Rubriques
Échec de la création de l’intégration
Si la création de l’intégration zéro ETL a échoué, le statut de l’intégration est Inactive
. Assurez-vous que les informations suivantes sont correctes pour votre entrepôt de données Amazon Redshift :
-
La sensibilité à la casse est activée. Consultez Activation de la sensibilité à la casse pour votre entrepôt des données.
-
Vous avez ajouté le principal autorisé et la source d’intégration appropriés pour votre espace de noms. Consultez Configuration de l’autorisation pour votre entrepôt des données Amazon Redshift.
Les tables ne sont pas répliquées vers Amazon Redshift
Dans la base de données de destination, une ou plusieurs tables ne possèdent pas de clé primaire et ne peuvent pas être synchronisées.
Pour résoudre ce problème, accédez à l’onglet Statistiques de table sur la page des détails de l’intégration ou utilisez SVV_INTEGRATION_TABLE_STATE pour afficher les tables ayant échoué. Vous pouvez ajouter des clés primaires aux tables et Amazon Redshift resynchronisera les tables. Vous pouvez exécuter la commande suivante pour les resynchroniser. dbname
Remplacez-le par le nom de votre base de données Amazon Redshift. Et remplacez table1
et table2
par les noms des tables à synchroniser.
ALTER DATABASE
dbname
INTEGRATION REFRESH TABLEStable1
,table2
;
Pour plus d'informations, consultez ALTER DATABASE dans le manuel Amazon Redshift Database Developer Guide.
Types de données non pris en charge dans les tables
Dans la base de données que vous avez créée à partir de l'intégration dans Amazon Redshift et dans laquelle les données sont répliquées à partir d'intégrations sans ETL avec des applications, une ou plusieurs tables contiennent des types de données non pris en charge et ne peuvent pas être synchronisées.
Pour résoudre ce problème, accédez à l’onglet Statistiques de table sur la page des détails de l’intégration ou utilisez SVV_INTEGRATION_TABLE_STATE pour afficher les tables ayant échoué. Supprimez ensuite ces tables et recréez-en de nouvelles à la source. Pour plus d'informations, consultez la section Intégrations Zero-ETL dans le Guide du AWS Glue développeur.
Les paramètres du groupe de travail sont incorrects
La sensibilité à la casse n’est pas activée dans votre groupe de travail.
Pour résoudre ce problème, accédez à l’onglet Propriétés sur la page des détails de l’intégration, choisissez le groupe de paramètres et activez l’identifiant sensible à la casse dans l’onglet Propriétés. Si vous n’avez pas de groupe de paramètres existant, créez-en un en activant l’identifiant sensible à la casse. Créez ensuite une nouvelle intégration Zero-ETL. Pour plus d'informations, consultez la section Intégrations Zero-ETL dans le Guide du AWS Glue développeur.
La base de données n’est pas créée pour activer une intégration zéro ETL
Aucune base de données n’a été créée pour activer l’intégration zéro ETL.
Pour résoudre ce problème, créez une base de données pour l’intégration. Pour de plus amples informations, veuillez consulter Création de bases de données de destination dans Amazon Redshift.
Table dans l’état Resynchronisation requise ou Resynchronisation initiée
Votre table est dans l’état Resynchronisation requise ou Resynchronisation initiée.
Pour recueillir des informations d’erreur plus détaillées sur les raisons pour lesquelles votre table est dans cet état, utilisez la vue système SYS_LOAD_ERROR_DETAIL.