Google utilise la technologie IA pour traduire le contenu dans votre langue préférée. Les traductions générées par IA peuvent contenir des erreurs.

Bonnes pratiques générales lors de l'utilisation de Datastream

Pour assurer une réplication fiable et réduire les temps d'arrêt dans Datastream, vous pouvez appliquer les bonnes pratiques opérationnelles à vos flux et à vos bases de données sources. Ces pratiques vous aident à modifier la base de données source d'un flux, à configurer des alertes de métriques, à résoudre les problèmes de latence et à planifier les limites de tables par flux.

Modifier la base de données source d'un flux

Dans certains cas, vous devrez peut-être modifier la base de données source d'un flux. Par exemple, vous devrez peut-être modifier le flux pour qu'il réplique les données à partir d'une réplique au lieu de l'instance de base de données principale.

Créez un profil de connexion pour l'instance répliquée.
Créez un flux à l'aide du profil de connexion pour la réplique que vous avez créée et du profil de connexion existant pour la destination.
Démarrez le flux avec le remplissage historique désactivé. Lorsque le flux est démarré, il ne récupère que les données des journaux binaires.
Facultatif. Une fois le flux en cours d'exécution, modifiez-le pour activer le remplissage automatique.
Mettez en pause le flux qui lit les données de l'instance principale.
Facultatif. Supprimez le flux qui diffusait les données de l'instance principale.
Facultatif. Supprimez le profil de connexion pour l'instance principale.

Alertes et surveillance dans Datastream

Le tableau de bord Datastream contient de nombreuses informations. Ces informations peuvent être utiles à des fins de débogage. Vous trouverez des informations supplémentaires dans les journaux, disponibles dans Cloud Logging.

Alertes Datastream

Aucune alerte n'est configurée par défaut pour Datastream. Par exemple, vous pouvez créer une règle d'alerte pour la métrique Fraîcheur des données en cliquant sur le lien Créer une règle d'alerte dans l'onglet Présentation. Pour les autres métriques, procédez comme suit :

Dans la Google Cloud console, accédez à la Alertes page :

Accéder à Alertes
Cliquez sur Créer une règle.
Cliquez sur le menu déroulant Sélectionner une métrique.
Dans le champ de filtre, saisissez Datastream.
Facultatif : Vous devrez peut-être désactiver le filtre Actif pour afficher toutes les métriques disponibles.
Recherchez la métrique que vous souhaitez surveiller sous Flux Datastream.
Cliquez sur Appliquer.
Facultatif : Saisissez les informations requises dans les sections Ajouter des filtres et Transformer les données. Cliquez sur Suivant.
Saisissez les informations requises dans la section Configurer un déclencheur d'alerte. Cliquez sur Suivant.
Configurez vos notifications dans la section Configurer des notifications et finaliser l'alerte.
Vérifiez votre alerte, puis cliquez sur Créer une règle lorsque vous êtes prêt.

Pour obtenir des informations détaillées sur la procédure à suivre pour chacune de ces étapes, consultez Créer une règle d'alerte.

Nous vous recommandons de créer des alertes pour les métriques Datastream suivantes :

Fraîcheur des données
Nombre d'événements non compatibles avec le flux
Latences totales du flux

Une alerte sur l'une de ces métriques peut indiquer un problème avec le flux ou la base de données source.

Comprendre la latence

Datastream fournit les métriques suivantes pour vous aider à comprendre la latence de réplication :

Fraîcheur des données : différence entre le moment où les données ont été validées dans la source et le moment où elles ont été lues par Datastream. Si cette métrique est élevée, cela indique que Datastream lit les données plus lentement qu'elles ne sont générées dans la source. Cela indique qu'il peut y avoir un problème avec la source ou avec la connexion réseau à la source.
Latence du système : temps nécessaire à Datastream pour traiter un événement, à partir du moment où l'événement est lu à partir de la source jusqu'à ce qu'il soit écrit dans la destination.
Latence totale : délai de réplication de bout en bout, représentant le temps total entre le moment où les données sont validées dans la source et le moment où elles sont écrites dans la destination.

Si la fraîcheur des données est élevée, les causes courantes sont les suivantes :

Surcharge de la source : la base de données source génère des journaux (fichiers binlog, fichiers journaux de rétablissement, fichiers WAL) plus rapidement que Datastream ne peut les lire.
- Action pour MySQL/Oracle augmentez le paramètre maxConcurrentCdcTasks pour lire plus de journaux en parallèle.
- Action pour PostgreSQL : isolez les tables à forte rotation dans leurs propres flux dédiés.
- Action pour SQL Server : augmentez le paramètre maxConcurrentCdcTasks pour lire plus de tables de modifications en parallèle.
Pénurie de ressources de la source : le serveur de base de données source lui-même rencontre des problèmes tels qu'une utilisation élevée du processeur, une mémoire insuffisante ou des goulots d'étranglement des E/S de disque.
- Action : assurez-vous que l'instance source est opérationnelle. Vérifiez l'utilisation du processeur/de la RAM. Pour PostgreSQL, envisagez d'augmenter la valeur du paramètre logical_decoding_work_mem. Pour Oracle, assurez-vous qu'une zone globale du système (SGA) suffisante est allouée.
Problèmes de capacité réseau : temps de ping élevé ou bande passante saturée entre votre source et Google Cloud.
- Action : surveillez la bande passante et la latence de votre VPN ou de votre Cloud Interconnect.
Transaction unique volumineuse : un job par lot volumineux, tel qu'une instruction UPDATE sur des millions de lignes, peut entraîner un pic temporaire de latence.
- Action : ce comportement est normal. Attendez que Datastream traite l'événement volumineux. Envisagez de diviser les jobs par lot volumineux en blocs plus petits à l'avenir.

Si la latence du système est élevée, cela peut indiquer un problème dans Datastream ou la destination.

Action : recherchez les erreurs persistantes au niveau des lignes dans Cloud Logging (par exemple, invalid input for type json). Si le flux est dans une boucle de nouvelle tentative en raison d'erreurs de type de données ou de contraintes, cela peut nécessiter une correction manuelle des données dans la source. Si aucune erreur évidente n'est détectée, contactez l'assistance Google pour obtenir de l'aide.

Combien de tables un seul flux peut-il gérer ?

Nous vous recommandons d'inclure jusqu'à 10 000 tables dans un seul flux. La taille des tables n'est pas limitée. Si vous devez créer un flux avec plus de tables, il est possible qu'il passe à l'état d'erreur. Pour éviter cela, envisagez de diviser la source en plusieurs flux.