Diagnostiquer les problèmes

Lorsqu'un flux rencontre une erreur d'exécution dans Datastream, vous pouvez afficher les détails sur la page Flux ou Détails du flux de la console Google Cloud . Vous pouvez également récupérer des informations de diagnostic à l'aide de l'API Datastream. Certains problèmes, tels qu'un mot de passe non valide, sont récupérables, et la réplication reprend automatiquement une fois que vous les avez résolus. D'autres erreurs n'affectent qu'un seul objet, comme un type de données non compatible, ou arrêtent le flux lorsque Datastream ne peut pas se connecter à la source.

Pour résoudre un problème, vérifiez le message d'erreur et suivez les étapes pour les erreurs de configuration, de connectivité, de source ou de destination BigQuery.

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 :

  1. Assurez-vous que la base de données source est opérationnelle et accessible.
  2. Accédez au profil de connexion source depuis la page 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 que vous avez apportées sur la page Profils de connexion.

La diffusion reprend automatiquement.
Échec de la connexion à la base de données source (mise sur liste d'autorisation des adresses IP). Cela peut se produire si la méthode de connectivité choisie est Liste d'adresses IP autorisées, mais qu'une ou plusieurs des adresses IP sortantes de Datastream ne sont pas ajoutées correctement à 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 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 apporté vos modifications, enregistrez le profil de connexion. Le flux reprendra automatiquement.
Échec de la connexion à la base de données source à l'aide de la connectivité privée. Cette erreur concerne la méthode de connectivité privée par appairage de VPC.
  1. Assurez-vous d'avoir rempli toutes les conditions préalables à l'appairage de VPC.

  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é (le nom est peering-[UUID]). La route se trouve dans l'onglet Routes exportées. Si cette route n'existe pas, ajoutez-la manuellement.

  3. Datastream ne vérifie pas s'il y a un chevauchement avec les 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 Routes annoncées personnalisées.
  5. Si vous rencontrez toujours des problèmes pour vous connecter à la base de données source, consultez Configurer un proxy inverse.
Échec de l'utilisation de l'interface Private Service Connect pour se connecter à la base de données source.
  1. Assurez-vous d'avoir rempli toutes les conditions préalables.
  2. Assurez-vous que vos règles de pare-feu autorisent le sous-réseau du rattachement de réseau fourni à se connecter à la base de données source.
  3. 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 Routes annoncées personnalisées.
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 Liste d'autorisation d'adresses IP publiques ou 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 Interfaces Private Service Connect, 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 de la console Google Cloud .
  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 Mesure d'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. Certains d'entre eux peuvent ne pas être inclus dans la liste des objets à extraire lors de la configuration de la source pour le 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, sélectionnez Personnalisé. Dans le champ Critères de correspondance des objets, saisissez les schémas et les tables que vous souhaitez que Datastream récupère.
J'ai ajouté plusieurs tables à mon flux à l'aide du menu Objets à inclure. Cependant, lorsque je consulte l'onglet Objets dans Détails du flux, je constate qu'il manque certaines tables. Assurez-vous qu'il existe au moins une mise à jour 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 d'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 Configurer des bases de données sources.
Événements supprimés pendant le streaming et non répliqués dans la destination.

Datastream peut supprimer les événements non compatibles pendant la diffusion. Pour résoudre le problème, vous pouvez effectuer les actions suivantes :

  • Déclencher manuellement un remplissage de l'intégralité de la table. Cela fonctionne si les événements supprimés sont uniquement 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 backfill.

    Pour savoir comment effectuer un remplissage, consultez Lancer un remplissage.

  • Contactez l'assistance Google et demandez-lui d'effectuer un backfill partiel. Cela n'est possible que si vous pouvez identifier les événements supprimés à l'aide d'une clause SQL WHERE et si aucun des événements n'est un événement DELETE.
  • Ignorez le problème si le nombre d'événements supprimés est faible ou si les événements supprimés ne sont pas significatifs.
Le délai de connexion a expiré lors de la tentative de connexion à la source de données. Assurez-vous que la configuration du nom d'hôte et du port est correcte, et que la source de données est accessible. Étant donné que le réseau Datastream ne peut pas être appairé directement à un réseau de services privés (par exemple, une instance Cloud SQL) lorsque vous utilisez l'appairage de VPC, vous devez utiliser une VM de traduction d'adresse réseau (NAT) pour établir la connectivité entre Datastream et votre ressource. Pour en savoir plus sur la configuration d'une VM NAT, consultez Configurer l'appairage de VPC.
Le schéma de l'objet OBJECT_NAME est trop volumineux pour être traité par Datastream. Datastream ne permet pas de répliquer des événements dont les schémas sources correspondants dépassent 2 621 440 caractères Unicode. Ces événements sont supprimés avec le code de motif suivant : UNSUPPORTED_LARGE_SCHEMA. Vous pouvez exclure certaines colonnes ou les renommer. Vous pouvez également exclure l'objet avec le schéma volumineux.
L'état du flux a changé. Bien que plusieurs raisons puissent expliquer cette erreur, un problème sous-jacent courant est une configuration de source non valide. Si votre flux ne démarre pas et que ce message d'erreur s'affiche, vérifiez si votre configuration source contient des clés ou des noms de table en double, des incohérences de données ou des conflits de schéma. De nombreux problèmes peuvent être résolus en modifiant les paramètres du flux ayant échoué directement dans la console Google Cloud et en ajustant les entrées pour les objets inclus et exclus. Pour en savoir plus, consultez Modifier les informations de configuration de la base de données source.

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 de données modifiées (CDC) en cours peut se produire si la configuration de la journalisation supplémentaire n'est pas correcte sur la base de données source. Vérifiez que la journalisation supplémentaire est correctement configurée. Plus précisément, vérifiez que la journalisation supplémentaire est activée pour les tables de base de données qui sont diffusées de la source vers la destination. La diffusion reprend automatiquement.
Impossible de reprendre la réplication, car la position dans le journal a été 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 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, partiellement ou entièrement.

Les fichiers journaux ont peut-être été supprimés. Oracle purge les fichiers journaux dès que possible, 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 englobe 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. La recréation de 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 répercutées dans la destination lorsque le flux est déjà en cours d'exécution. Si vous utilisez LogMiner comme méthode de CDC, Datastream lit les fichiers journaux de rétablissement archivés. Dans ce cas, 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, remplacez la méthode CDC par le lecteur de journaux binaires, 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.
Échec de la validation de la configuration Oracle CDC. Vous avez sélectionné une méthode CDC pour laquelle votre base de données source n'était pas configurée. Sélectionnez une autre méthode ou terminez la configuration de votre méthode CDC. Pour en savoir plus, consultez Configurer une base de données Oracle source.
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 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 proches de la durée de conservation du binlog. 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 respecte 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 purge les binlogs dès que possible, 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 englobe 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 est autorisé à répliquer la base de données.
Lorsque vous créez un profil de connexion pour une source MySQL, plusieurs certificats SSL encodés au format PEM ne sont pas acceptés dans le menu Type de chiffrement. Datastream n'accepte pas 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 la diffusion à partir d'une source MySQL.

Augmentez la capacité de Datastream à lire la base de données source :
Échec de la validation de la configuration CDC MySQL. Votre base de données source n'a pas été configurée pour la méthode CDC que vous avez sélectionnée. Sélectionnez une autre méthode ou terminez la configuration de votre méthode CDC. Pour en savoir plus, consultez Configurer une base de données MySQL 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 de données modifiées (CDC) en cours peut se produire si l'emplacement de réplication n'existe pas dans 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 est configuré avec un plug-in incorrect. Cette erreur peut se produire si l'emplacement de réplication est configuré avec un plug-in autre que 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 à ne pas utiliser le même emplacement de réplication dans un autre processus que 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 correctement configurée. Consultez Configurer les informations sur la base de données source du 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 correctement configurée. 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, ce qui entraîne la perte des fichiers WAL. Les flux ne doivent pas être mis en pause pendant des périodes proches de la période de conservation des fichiers WAL. Recréez le flux.
La liste d'exclusion englobe 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 est autorisé à 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. Étant donné que les emplacements de réplication PostgreSQL sont monothread, le traitement des autres modifications dans l'emplacement de réplication, y compris les modifications apportées aux données d'autres tables, est retardé jusqu'à ce que Datastream rattrape toutes les modifications dans l'emplacement de réplication.
Les transactions volumineuses sur la base de données source entraînent un faible débit de CDC. Datastream n'est pas compatible avec la CDC multithread dans PostgreSQL. Pour contourner cette limite et augmenter votre débit CDC, vous pouvez diviser la source en plusieurs flux, chacun disposant de sa propre publication et de son propre emplacement de réplication. Par exemple, vous pouvez créer un flux pour la plus grande table de votre base de données et un autre pour toutes les autres tables, ou un flux pour vos tables prioritaires et un autre pour les tables restantes. Les cas d'utilisation peuvent varier. Vous devez donc déterminer ce qui est le plus pertinent dans 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é de l'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 ne respecte pas la limite de BigQuery CDC et entraîne l'erreur. Pour résoudre ce problème, procédez comme suit :
  1. Remplacez l'identité de l'instance répliquée par 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 à inclure dans le flux. 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 Supprimer des tables.
  4. Dans Datastream, ajoutez de nouveau la table au flux en modifiant la configuration de votre 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 de données modifiées (CDC) doit être activée pour la base de données. Datastream a besoin d'un accès en lecture direct aux journaux de transactions pour répliquer les modifications en temps réel dans la base de données source et obtenir des informations complètes sur les journaux. 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) doit être activée pour toutes les tables incluses dans le flux. Datastream a besoin d'un accès en lecture direct aux journaux de transactions pour répliquer les modifications en temps réel dans les tables sources et obtenir des informations complètes sur les journaux. 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 utilisé pour 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 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 Présentation de SQL Server en tant que source.
Le flux n'est pas en mesure de lire l'événement "YOUR_LSN" dans LSN, car le journal des transactions semble être tronqué.

Ce problème peut se produire lorsque les journaux de transactions n'existent plus dans la base de données source. Lorsque vous répliquez des données à partir d'une source SQL Server à l'aide de la méthode CDC des journaux de transactions, les journaux peuvent être tronqués avant que Datastream ne les lise. Dans ce cas, Datastream ne peut pas répliquer de manière fiable la base de données source vers la destination.

Pour résoudre le problème, récupérez votre flux ou envisagez d'utiliser la méthode CDC des tables de modifications. Pour en savoir plus sur les différences entre les deux méthodes, consultez Présentation de SQL Server en tant que source.
Échec de la configuration de la CDC 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 Salesforce

Erreur Procédure de dépannage
Autorisations insuffisantes.

L'utilisateur de l'application connectée ou de l'application cliente externe que vous avez configurée pour authentifier la connexion entre votre organisation Salesforce et Datastream ne dispose pas des autorisations suffisantes pour accéder aux données que vous souhaitez répliquer. Assurez-vous d'avoir correctement configuré votre source Salesforce. Pour en savoir plus, consultez Configurer une source Salesforce.
API Bulk 2.0 désactivée.

L'API Bulk 2.0 est activée par défaut pour les éditions Performance, Unlimited, Enterprise et Developer. Ce message d'erreur indique que l'API est désactivée dans votre édition ou que les identifiants que vous utilisez ne disposent pas des autorisations suffisantes. Assurez-vous que le profil utilisateur que vous utilisez dispose de l'autorisation API Enabled.
Limite dépassée.

Vous avez dépassé la limite de requêtes de l'API Salesforce. Ce message s'affiche lorsque vous atteignez 90 % de votre quota de limite d'API. Dans ce cas, Datastream réessayera l'opération plus tard. Vous pouvez envisager d'augmenter votre quota d'API Salesforce.
Limite de suppression dépassée.

Lors de l'interrogation des enregistrements supprimés, Salesforce limite la réponse à 600 000 identifiants d'enregistrement. La précision de requête la plus faible dans Salesforce est d'une minute. Si vous supprimez plus de 600 000 enregistrements en une minute, Salesforce renvoie cette erreur.
Erreur d'authentification.

Datastream ne peut pas s'authentifier auprès de Salesforce. Vous avez probablement utilisé des identifiants ou un nom de domaine incorrects.

Erreurs MongoDB

Erreur Procédure de dépannage
Échec de l'authentification. Veuillez vérifier si le authSource de l'utilisateur Datastream est admin. L'utilisateur Datastream doit être créé dans la base de données admin. Cette base de données est une base de données privilégiée qui permet aux utilisateurs d'exécuter certaines commandes d'administration.
Échec de la connexion à la base de données. Vérifiez votre nom d'utilisateur et votre mot de passe, puis réessayez. Assurez-vous aussi que votre compte utilisateur a été créé dans la base de données admin. Si le problème persiste, il est possible que votre compte utilisateur ait été supprimé ou qu'il n'ait pas été créé correctement.
La liste des objets exclus n'est pas valide : {exclude_list}. Spécifiez vos objets exclus au format suivant : DATABASE_NAME.COLLECTION_NAME.FIELD_NAME.NESTED_FIELD_NAME avec des caractères génériques facultatifs. Exemples valides : db.*, database.collection.*, database.*.field.*.
Nous ne disposons pas des autorisations nécessaires pour lire la source. Attribuez le rôle readAnyDatabase à votre utilisateur, puis réessayez.
La version VERSION_NAME de MongoDB n'est pas compatible. Veuillez utiliser la version 5.0 ou une version ultérieure.
Datastream n'a pas pu exécuter la commande buildinfo pour déterminer la version de MongoDB. Assurez-vous que l'utilisateur dispose des autorisations nécessaires pour exécuter la commande buildinfo, puis réessayez. Pour en savoir plus sur les autorisations requises, consultez Configurer une base de données MongoDB.
Délai de connexion au cluster MongoDB dépassé. Assurez-vous d'avoir fourni le nom d'hôte et les identifiants corrects, puis réessayez.
Impossible de lire les données nécessaires en raison d'autorisations insuffisantes. Attribuez le rôle readAnyDatabase au compte utilisé pour se connecter à votre cluster MongoDB, puis réessayez.
Le compte utilisateur utilisé pour se connecter à votre cluster MongoDB n'existe pas. Veuillez créer le compte utilisateur, puis réessayer.
Impossible de se connecter avec les informations fournies. Veuillez vérifier que le format de connexion (SRV ou Standard) utilisé est correct et que toutes les informations nécessaires (comme les noms de l'ensemble d'instances répliquées pour la chaîne de connexion de l'ensemble d'instances répliquées) sont incluses. Pour en savoir plus, consultez Créer un profil de connexion pour une base de données MongoDB.
Une exception MongoDB s'est produite. Message d'erreur source : {source_error}. Si le message d'erreur source n'est pas clair, contactez l'assistance Google.

Erreurs Spanner

Erreur Procédure de dépannage
Erreur de lecture Spanner. Si votre base de données Spanner se trouve dans un projet différent de celui dans lequel Datastream est exécuté, assurez-vous d'avoir fourni les autorisations nécessaires. Assurez-vous également que votre base de données Spanner dispose de ressources de processeur suffisantes et qu'elle ne limite pas les requêtes.
Flux de modifications hors de la période de conservation. Vous ne pouvez pas récupérer un flux ayant rencontré cette erreur. Cette erreur signifie que Datastream a pris du retard par rapport à la période de conservation de votre flux de modifications Spanner et a perdu des données. Si la période de conservation était courte (par exemple, si elle durait quelques secondes ou minutes), vous pouvez essayer de l'augmenter et de créer un flux.

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 backfill. Il s'agit d'une limite de BigQuery, car il n'est pas possible de garantir la 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 comporte 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" (ajout uniquement), 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 lors de l'exécution d'un backfill en mode d'écriture Ajout uniquement.

Lorsque vous sélectionnez le mode d'écriture Ajout uniquement pour votre flux, vos données sont ajoutées dans BigQuery sous la forme d'un flux d'événements INSERT, UPDATE-INSERT, UPDATE-DELETE et DELETE, sans aucune consolidation. 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 l'outil d'écriture BigQuery réessaie 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
Datastream est configuré pour le mode d'écriture par fusion, mais les modifications ne sont pas fusionnées dans BigQuery.

Vérifiez qu'il existe une clé primaire dans votre table source. BigQuery en a besoin pour fusionner les modifications dans la table de destination.

S'il n'y a pas de clé primaire, envisagez d'en ajouter une dans la table source ou la table de destination. Pour ajouter une clé primaire dans votre table BigQuery de destination, procédez comme suit :

  1. Mettre le flux en pause.
  2. Tronquez la table dans BigQuery.
  3. Ajoutez la clé primaire à la définition de la table.
  4. Reprendre le flux.
  5. Déclenchez le remplissage de la table.
Impossible d'ajouter une clé primaire, de supprimer une clé primaire ou de modifier la définition de la clé primaire d'une table déjà répliquée dans BigQuery.

Par défaut, Datastream ne permet pas d'ajouter une clé primaire à une table déjà répliquée dans BigQuery sans clé primaire, ni de supprimer une clé primaire d'une table répliquée dans BigQuery avec une clé primaire. Vous pouvez toutefois modifier la définition de la clé primaire d'une table source répliquée dans BigQuery qui possède déjà une clé primaire :

  1. Vérifiez la métrique de latence totale du flux et attendez au moins aussi longtemps que la latence actuelle pour vous assurer que tous les événements en cours sont écrits dans la destination. Cela permet de diffuser correctement tous les événements avec la clé primaire d'origine.
  2. Mettez le flux en pause.
  3. Copiez la commande LDD (langage de définition de données) CREATE TABLE pour la table dans BigQuery : 
        SELECT ddl FROM PROJECT_ID.DATASET.INFORMATION_SCHEMA.TABLES
      WHERE table_name='TABLE_NAME';

    Remplacez les éléments suivants :

    • PROJECT_ID : identifiant de votre projet Google Cloud .
    • DATASET_ID : identifiant de l'ensemble de données dans BigQuery.
    • TABLE_NAME : nom de la table pour laquelle vous souhaitez copier la commande LDD.
  4. Supprimez la table dans BigQuery.
  5. Ajustez la commande LDD CREATE TABLE avec les nouvelles clés primaires. Incluez les clés de partition et de cluster, ainsi que max_staleness OPTION : 
        CREATE TABLE `[PROJECT_ID].[DATASET_ID].[TABLE_NAME]`
    (
      product_id INT64 NOT NULL,
      product_name STRING,
      datastream_metadata STRUCT,
      PRIMARY KEY (product_id) NOT ENFORCED
    )
    CLUSTER BY dept_no
    OPTIONS(
      max_staleness=INTERVAL '0-0 0 0:MINS:0' YEAR TO SECOND
    );
    ;

    Remplacez les éléments suivants :

    • PROJECT_ID : identifiant de votre projet Google Cloud .
    • DATASET_ID : identifiant de l'ensemble de données dans BigQuery.
    • TABLE_NAME : nom de la table pour laquelle vous avez copié la commande LDD.
    • MINS : nombre de minutes que vous souhaitez définir pour l'option max_staleness, par exemple 15.
  6. Exécutez la requête ajustée pour recréer la table dans BigQuery.
  7. Reprenez la diffusion.
  8. Lancez le backfill de la table.

Étapes suivantes

  • Pour savoir comment rechercher d'éventuels problèmes liés à votre flux, consultez Résoudre les problèmes liés à un flux.
  • Pour savoir comment configurer votre base de données source, consultez Sources.
  • Pour savoir comment configurer votre destination BigQuery ou Cloud Storage, consultez Destinations.