Diagnostiquer les problèmes

Présentation

Le flux peut générer des erreurs lors de l'exécution.

  • Certaines erreurs, telles qu'un mot de passe incorrect dans la base de données source, peuvent être récupérées, ce qui signifie qu'elles peuvent être corrigées et que le flux reprend automatiquement.
  • Les erreurs peuvent avoir une incidence sur un seul objet, par exemple un événement contenant des types de données non compatibles. D'autres erreurs peuvent affecter plusieurs objets ou l'intégralité du flux, par exemple lorsque Datastream ne peut pas se connecter à la base de données source.
  • Selon l'erreur, des informations sont fournies sur les pages Flux ou Détails du flux de l'interface utilisateur de Datastream. Vous pouvez également utiliser les API de Datastream pour récupérer des informations sur l'erreur.

Pour corriger une erreur, accédez au flux pour afficher l'erreur, puis suivez les étapes décrites dans le message d'erreur.

Cette page contient des informations sur les erreurs de configuration, de connectivité, Oracle et MySQL, ainsi que la procédure à suivre pour les résoudre.

Erreurs de configuration et de connectivité

Erreur Procédure de dépannage
Échec de la connexion à la base de données source (générique).

Cette situation peut se produire pour diverses raisons. Pour résoudre cette erreur, procédez comme suit :

  1. Assurez-vous que la base de données source est opérationnelle et accessible.
  2. Accédez au profil de connexion source à partir des pages Flux ou Profils de connexion.
  3. Vérifiez que les informations de connectivité du profil de connexion sont correctes.
  4. Vérifiez que le nom d'utilisateur et le mot de passe correspondent.
  5. Vérifiez que le nom d'utilisateur existe dans la base de données et qu'il dispose des droits requis.
  6. Enregistrez les modifications apportées sur la page Profils de connexion.

La diffusion reprend automatiquement.
Échec de la connexion à la base de données source (liste d'autorisation d'adresses IP). Cela peut se produire si la méthode de connectivité choisie est la liste d'autorisation d'adresses IP, mais qu'une ou plusieurs des adresses IP sortantes de Datastream ne sont pas correctement ajoutées à la base de données source. Assurez-vous que les adresses IP sortantes affichées dans le profil de connexion Datastream sont configurées sur le pare-feu du réseau afin que le serveur de base de données source puisse accepter les connexions provenant de ces adresses IP. Une fois le problème résolu, la diffusion reprend automatiquement.
Échec de la connexion à la base de données source (tunnel SSH de transfert). Cela peut se produire en cas de problème avec le tunnel SSH de transfert. Vérifiez l'état du tunnel. Si le tunnel est arrêté, il doit être démarré. Une fois le problème résolu, la diffusion reprend automatiquement.
Datastream ne peut pas se connecter à un hôte bastion via un tunnel SSH de transfert. Vérifiez que la configuration du tunnel SSH de transfert est correcte dans le profil de connexion source et que le port est ouvert sur le serveur du tunnel SSH.
Échec de la connexion à la base de données source en raison de certificats incorrects. Cela peut se produire en cas de problème avec les certificats fournis lors de la définition du profil de connexion source. Accédez à la page Profils de connexion, puis sélectionnez le profil de connexion donné. Vérifiez que les certificats sont correctement configurés. Après avoir effectué vos modifications, enregistrez le profil de connexion pour que le flux reprend automatiquement.
Échec de l'utilisation de la connectivité privée pour se connecter à la base de données source.
  1. Assurez-vous d'avoir rempli toutes les conditions préalables décrites à la section Avant de commencer.

  2. Après avoir créé la configuration de connectivité privée, vérifiez que la route contenant l'adresse IP interne de la base de données apparaît dans l'onglet Routes exportées de la page Appairage de réseaux VPC.

    Pour ce faire, accédez à la page Appairage de réseaux VPC, puis recherchez l'appairage qui a été ajouté (nommé peering-[UUID]). Vous trouverez la route dans l'onglet Routes exportées. Si cette route n'existe pas, ajoutez-la manuellement.

  3. Datastream ne vérifie pas le chevauchement de routes d'appairage dynamiques. Fournir un sous-réseau qui chevauche une route dynamique peut entraîner des problèmes de connectivité. Par conséquent, nous vous déconseillons d'utiliser un sous-réseau faisant partie d'une route dynamique.
  4. Assurez-vous que les routes personnalisées pour les plages d'adresses IP Datastream sont correctement annoncées. Si les routes personnalisées sont manquantes, consultez le guide Annonces de routage personnalisées.
  5. Si vous n'arrivez toujours pas à vous connecter à la base de données source, consultez Configurer un proxy inverse.
Le type de connectivité STATIC_SERVICE_IP_CONNECTIVITY n'est pas autorisé lorsque la règle d'administration constraints/datastream.disablePublicConnectivity est activée.

Vous avez sélectionné les méthodes de connectivité réseau publiques pour la liste d'autorisation d'adresses IP ou le tunnel SSH de transfert pour le profil de connexion que vous créez. Toutefois, la règle d'administration Bloquer les méthodes de connectivité publique pour Datastream est activée. Par conséquent, vous ne pouvez pas sélectionner de méthodes de connectivité publique pour votre profil de connexion.

Pour résoudre ce problème, sélectionnez la méthode de connectivité réseau privée Appairage de VPC ou désactivez la règle d'administration.

Pour désactiver la règle d'administration, procédez comme suit :

  1. Accédez à la page Règles d'administration dans Google Cloud Console.
  2. Sélectionnez la règle d'administration Datastream - Bloquer les méthodes de connectivité publique.

  3. Cliquez sur MODIFIER.

  4. Dans la section S'applique à de la page, sélectionnez Personnaliser.

  5. Dans la section Application, sélectionnez Désactivé.

  6. Cliquez sur SAVE (ENREGISTRER).
  7. Revenez au profil de connexion Oracle que vous créez, puis cliquez sur CREATE (CRÉER).
Lors de la configuration de la base de données source pour mon flux, je ne trouve pas les tables et les schémas que je souhaite transférer dans la liste des objets à inclure.

Cela peut se produire si votre base de données comporte des milliers de tables et de schémas. Il est possible que certains d'entre eux ne figurent pas dans la liste des objets à extraire lors de la configuration de la source du flux dans la console Google Cloud. Au lieu de sélectionner Schémas et tables spécifiques dans la section Sélectionner des objets à inclure, choisissez Personnalisé. Dans le champ Critère de correspondance des objets, saisissez les schémas et les tables que vous souhaitez que Datastream extraie.
J'ai ajouté plusieurs tables à mon flux à l'aide du menu Objets à inclure. Toutefois, lorsque je consulte l'onglet Objets dans Détails du flux, je constate qu'il manque certaines tables. Assurez-vous d'avoir effectué au moins une mise à jour de la CDC pour chacune de ces tables afin que Datastream puisse reconnaître les modifications et inclure automatiquement les tables dans le flux.
Échec du chargement de la liste des objets lors de l'utilisation du menu Objets à inclure dans la console Google Cloud. Cela peut se produire si votre base de données comporte plus de 5 000 schémas et tables. Utilisez une autre méthode pour spécifier les objets à inclure, ou utilisez l'API Datastream. Pour en savoir plus, consultez la page Configurer les bases de données sources.
Événements supprimés pendant la diffusion et non répliqués dans la destination.

Datastream peut ignorer les événements non compatibles pendant la diffusion. Vous pouvez effectuer les actions suivantes pour résoudre le problème:

  • Déclenchez manuellement un remplissage de l'ensemble de la table. Cela fonctionne si les événements supprimés ne sont que des événements UPSERT. Si les événements supprimés incluent des événements DELETE, vous devez tronquer la table dans BigQuery avant d'effectuer le remplissage.

    Pour en savoir plus sur la manière d'effectuer un remplissage, consultez Déclencher un remplissage.

  • Contactez l'assistance Google pour lui demander d'effectuer un remplissage partiel. Cela n'est possible que si vous pouvez identifier les événements supprimés avec une clause SQL WHERE et qu'aucun des événements n'est un événement DELETE.
  • Ignorez ce problème si le nombre d'événements supprimés est faible ou si les événements supprimés ne sont pas significatifs.

Erreurs Oracle

Erreur Procédure de dépannage
La journalisation supplémentaire est mal configurée dans la base de données source.

Une erreur de récupération des données de capture des données modifiées (CDC, Change Data Capture) en cours peut se produire si la configuration de la journalisation complémentaire n'est pas correcte sur la base de données source. Vérifiez que la journalisation complémentaire est correctement configurée. Vérifiez en particulier que la journalisation complémentaire est activée pour les tables de base de données qui sont diffusées en continu depuis la source vers la destination. La diffusion reprend automatiquement.
Impossible de reprendre la réplication, car la position dans le journal est perdue. Cette erreur peut se produire lorsque le processus de réplication est suspendu pendant une longue période, ce qui entraîne une perte de position dans le journal. Les flux ne doivent pas être mis en pause pendant des périodes proches de la durée de conservation des journaux. Recréez le flux.
Les fichiers journaux sont manquants (en partie ou en totalité).

Les fichiers journaux ont peut-être été supprimés. Oracle supprime définitivement les fichiers journaux dès qu'ils le peuvent, sauf si vous spécifiez une période de rotation minimale pour les conserver. Sur le serveur Oracle, définissez la durée de conservation des fichiers journaux. Par exemple, utilisez CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 4 DAYS; pour conserver les fichiers journaux pendant au moins quatre jours.

Pour un déploiement RDS, utilisez exec rdsadmin.rdsadmin_util.set_configuration('archivelog retention hours',96);.
La liste d'exclusion sous-tend la liste d'inclusion. La liste d'inclusion est entièrement contenue dans la liste d'exclusion. Par conséquent, la liste des objets que Datastream extrait de la source est vide. Modifiez la sélection d'objets, puis réessayez.
Le mode de journalisation de la base de données Oracle n'est pas défini sur ARCHIVELOG. Modifiez le mode de journalisation, puis réessayez.
Datastream renvoie un message d'erreur ORA-00942: table or view does not exist, mais tout est correctement configuré. Cela peut être dû à la mise en cache sur le serveur Oracle. Recréer l'utilisateur de la base de données devrait résoudre le problème de mise en cache.
Les modifications apportées à une source Oracle ne sont pas reflétées dans la destination lorsque le flux est déjà en cours d'exécution. Étant donné que Datastream lit les fichiers journaux de rétablissement archivés, les modifications que vous apportez à la source ne sont pas répercutées dans la destination tant que le journal n'est pas archivé. Pour voir les modifications dans la destination, modifiez la règle d'archivage des journaux ou forcez manuellement un changement de journal. Pour en savoir plus, consultez Utiliser les fichiers journaux de rétablissement de base de données Oracle.
Une erreur interne inattendue s'est produite. Pour en savoir plus, contactez l'assistance Google.

Erreurs MySQL

Erreur Procédure de dépannage
Le binlog n'est pas configuré correctement dans la base de données source.

Cela peut se produire pour les flux MySQL continus si la configuration du binlog est incorrecte dans la base de données source. Pour résoudre cette erreur, procédez comme suit :

  1. Vérifiez que le binlog est correctement configuré.
  2. Vérifiez que le format du journal binaire de la base de données MySQL est défini sur ROW.
  3. Redémarrez le flux.
Impossible de reprendre la réplication car la position du binlog est perdue. Cette erreur peut se produire lorsque le processus de réplication est suspendu pendant une longue période, ce qui entraîne la perte de la position du binlog. Les flux ne doivent pas être mis en pause pendant des périodes approchant de la durée de conservation des binlogs. Recréez le flux.
Échec de l'exécution du flux en raison de versions de base de données source et de destination incompatibles.

Cela peut se produire lorsque la base de données source ne respecte pas la matrice de compatibilité des versions. Pour résoudre cette erreur, procédez comme suit :

  1. Assurez-vous que la base de données source est conforme à la matrice.
  2. Recréez le flux avec la base de données source mise à jour.
Les binlogs sources MySQL AWS RDS sont partiellement ou entièrement manquants. Les binlogs ont peut-être été supprimés. AWS RDS supprime définitivement les binlogs dès qu'ils le peuvent, sauf si vous spécifiez une période de rotation minimale pour les conserver. Dans l'instance MySQL AWS RDS source, définissez la durée de conservation des binlogs, en heures. Par exemple, utilisez mysql.rds_set_configuration('binlog retention hours', 168); pour conserver les binlogs pendant au moins sept jours.
La liste d'exclusion sous-tend la liste d'inclusion. La liste d'inclusion est entièrement contenue dans la liste d'exclusion. Par conséquent, la liste des objets que Datastream extrait de la source est vide. Modifiez la sélection d'objets, puis réessayez.
Datastream ne peut pas répliquer une base de données MySQL. Assurez-vous que Datastream dispose des autorisations nécessaires pour répliquer la base de données.
Lorsque vous créez un profil de connexion pour une source MySQL, le menu Type de chiffrement n'accepte pas plusieurs certificats SSL encodés au format PEM. Datastream n'est pas compatible avec les chaînes de certificats SSL dans les profils de connexion MySQL. Seuls les certificats uniques encodés au format PEM x509 sont acceptés.
Latence élevée lors de l'insertion de données en flux continu à partir d'une source MySQL.

Augmentez la capacité de Datastream à lire des données depuis la base de données source:
Une erreur interne inattendue s'est produite. Pour en savoir plus, contactez l'assistance Google.

Erreurs PostgreSQL

Erreur Procédure de dépannage
Le décodage logique n'est pas configuré correctement sur la base de données source.

Vérifiez que le décodage logique est correctement configuré. Consultez Configurer une base de données PostgreSQL source.
L'emplacement de réplication n'existe pas Une erreur de récupération des données de capture des données modifiées (CDC, Change Data Capture) en cours peut se produire si l'emplacement de réplication n'existe pas sur la base de données. Vérifiez que l'emplacement de réplication est correctement configuré. Consultez Configurer une base de données PostgreSQL source.
L'emplacement de réplication n'est pas configuré avec un plug-in incorrect Cette erreur peut se produire si l'emplacement de réplication est configuré avec un plug-in différent de pgoutput. Vérifiez que l'emplacement de réplication est correctement configuré. Pour en savoir plus, consultez Base de données PostgreSQL source.
L'emplacement de réplication est actif dans un autre processus. Cette erreur peut se produire lorsque l'emplacement de réplication est utilisé par un autre processus. Les emplacements de réplication ne peuvent être utilisés que par un seul processus à la fois. Veillez à n'utiliser le même emplacement de réplication dans aucun autre processus que celui de Datastream.
La publication n'est pas configurée correctement Cette erreur peut se produire lorsque la publication n'est pas configurée pour exposer les tables incluses dans la configuration du flux. Vérifiez que la publication est configurée correctement. Consultez la section Configurer les informations sur la base de données source pour le flux.
La publication n'existe pas. Cette erreur peut se produire si la publication n'existe pas dans la base de données. Vérifiez que la publication est configurée correctement. Consultez Configurer une base de données PostgreSQL source.
Impossible de reprendre la réplication, car les fichiers WAL sont perdus. Cette erreur peut se produire lorsque le processus de réplication est suspendu pendant une longue période, entraînant la perte des fichiers WAL. N'interrompez pas les flux pendant des périodes proches de la durée de conservation des fichiers WAL. Recréez le flux.
La liste d'exclusion sous-tend la liste d'inclusion. La liste d'inclusion est entièrement contenue dans la liste d'exclusion. Par conséquent, la liste des objets que Datastream extrait de la source est vide. Modifiez la sélection d'objets, puis réessayez.
Datastream ne peut pas répliquer un schéma PostgreSQL. Assurez-vous que Datastream dispose des autorisations nécessaires pour répliquer le schéma.
Les transactions volumineuses sur la base de données source entraînent des problèmes de réplication et de synchronisation des données. Si vous insérez, mettez à jour ou supprimez un nombre important d'enregistrements dans la base de données source, l'emplacement de réplication peut être surchargé par les événements correspondants. Datastream a besoin de temps pour lire et traiter ces événements. Les emplacements de réplication PostgreSQL étant monothread, le traitement des autres modifications apportées à l'emplacement de réplication, y compris celles apportées aux données d'autres tables, est retardé jusqu'à ce que Datastream rattrape toutes les modifications apportées à l'emplacement de réplication.
Les transactions volumineuses sur la base de données source entraînent un débit CDC faible. Datastream n'est pas compatible avec la CDC multithread dans PostgreSQL. Pour contourner cette limitation et augmenter votre débit CDC, vous pouvez diviser la source en plusieurs flux, chacun avec ses propres emplacements de publication et de réplication. Par exemple, vous pouvez créer un flux pour la table la plus grande de votre base de données et un autre pour toutes les autres tables, ou un flux pour vos tables les plus prioritaires et un autre pour les tables restantes. Les cas d'utilisation peuvent varier, vous devez donc déterminer ce qui convient le mieux à votre scénario CDC spécifique. Pour en savoir plus sur la création d'une publication, consultez Configurer une base de données PostgreSQL source.
Événements non compatibles supprimés avec le code de motif: BIGQUERY_TOO_MANY_PRIMARY_KEYS. Lorsque l'identité d'instance répliquée PostgreSQL d'une table est définie sur FULL, Datastream traite toutes les colonnes de cette table comme des clés primaires. Si la table comporte plus de 16 colonnes, cela signifie que les limites de la CDC BigQuery ne sont pas respectées et provoquent l'erreur. Pour résoudre le problème, procédez comme suit :
  1. Définissez l'identité de l'instance répliquée sur DEFAULT : 
    ALTER TABLE TABLE_NAME REPLICA IDENTITY DEFAULT
    Remplacez TABLE_NAME par le nom de la table pour laquelle vous souhaitez modifier l'identité de l'instance répliquée.
  2. Supprimez la table de la liste des objets du flux à inclure. Pour en savoir plus, consultez Modifier les informations de configuration de la base de données source.
  3. Supprimez la table de BigQuery. Pour en savoir plus, consultez la section Supprimer des tables.
  4. Dans Datastream, ajoutez de nouveau la table au flux en modifiant la configuration source.
Une erreur interne inattendue s'est produite. Pour en savoir plus, contactez l'assistance Google.

Erreurs SQL Server

Erreur Procédure de dépannage
La CDC est désactivée pour la base de données DATABASE_NAME.

La capture des données modifiées (CDC, Change Data Capture) doit être activée pour la base de données. Datastream a besoin d'un accès en lecture directe aux journaux de transactions afin de répliquer en temps réel les modifications apportées à la base de données source et d'obtenir des informations de journal complètes. Activez la CDC pour la base de données, puis réessayez.

Pour en savoir plus sur l'activation de la CDC pour une base de données, consultez Configurer une base de données SQL Server source.
Tables avec CDC désactivée

La capture de données modifiées (CDC, Change Data Capture) doit être activée pour toutes les tables incluses dans le flux. Datastream a besoin d'un accès en lecture directe aux journaux de transactions afin de répliquer en temps réel les modifications apportées aux tables sources et d'obtenir des informations de journal complètes. Activez la CDC pour les tables incluses dans le flux, puis réessayez.

Pour en savoir plus sur l'activation de la CDC pour les tables sources, consultez Configurer une base de données SQL Server source.
Autorisations manquantes. Datastream ne dispose pas des autorisations nécessaires pour lire la source. Accordez les droits appropriés au compte utilisateur permettant de se connecter à votre base de données, puis réessayez.
L'édition SQL Server EDITION_NAME n'est pas compatible. Datastream n'est pas compatible avec cette édition de SQL Server. Pour en savoir plus sur les éditions compatibles de SQL Server, consultez la page Présentation de SQL Server en tant que source.
La version VERSION_NAME de SQL Server de l'édition Standard n'est pas compatible. Datastream n'est pas compatible avec cette version de l'édition SQL Server Standard. Pour en savoir plus sur les versions compatibles de SQL Server, consultez la page Présentation de SQL Server en tant que source.
Échec de la configuration de la CDC pour SQL Server. La méthode CDC que vous avez sélectionnée n'est pas conforme à la configuration de votre base de données. Modifiez la méthode CDC, puis réessayez.

Erreurs BigQuery

Erreur Procédure de dépannage
BIGQUERY_UNSUPPORTED_PRIMARY_KEY_CHANGE, details: Failed to write to BigQuery due to an unsupported primary key change: adding primary keys to existing tables is not supported. Si la clé primaire change dans la source, vous devez supprimer la table dans BigQuery et relancer le remplissage. Il s'agit d'une limitation de BigQuery, car il n'existe aucun moyen de garantir une fusion correcte des nouveaux événements avec les lignes existantes si la clé primaire est différente. Pour en savoir plus, consultez Configurer une destination BigQuery.
La table BigQuery de destination contient beaucoup plus d'enregistrements que la table source. Cela peut se produire lorsque la table source ne possède pas de clé primaire. Dans ce cas, Datastream traite la table en mode d'écriture "append-only", et chaque événement d'une ligne donnée apparaît sous la forme d'une ligne distincte dans BigQuery.
Les données sont dupliquées lorsque vous effectuez un remplissage en mode d'écriture Append-only (Ajouter uniquement).

Lorsque vous sélectionnez le mode d'écriture Ajouter uniquement pour votre flux, vos données sont ajoutées dans BigQuery en tant que flux d'événements INSERT, UPDATE-INSERT, UPDATE-DELETE et DELETE, sans aucun regroupement. Cela peut entraîner l'écriture de lignes en double dans BigQuery lorsque vous effectuez un remplissage ou lorsqu'un problème survient et que le rédacteur BigQuery retente les opérations d'écriture. Pour résoudre ce problème, nous vous recommandons d'exécuter régulièrement une requête de déduplication, semblable à celle-ci:

SELECT * FROM (SELECT *, row_number() OVER (PARTITION BY datastream_metadata.uuid) AS num FROM TABLE_NAME) WHERE num=1