Cette page présente les bonnes pratiques d'utilisation de Datastream. Cela inclut les bonnes pratiques générales lors de l'utilisation de Datastream.
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 répliquer les données à partir d'une instance répliquée plutôt que 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 n'extrait 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 veille le flux qui lit les données de l'instance principale.
- Facultatif. Supprimez le flux qui transmettait des données depuis 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 par défaut n'est configurée 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 Vue d'ensemble. Pour les autres métriques, procédez comme suit :
Dans la console Google Cloud , accédez à la page notifications 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 Next (Suivant).
Saisissez les informations requises dans la section Configurer un déclencheur d'alerte. Cliquez sur Suivant.
Configurez vos notifications dans la section Configurer les notifications et finaliser l'alerte.
Examinez l'alerte et cliquez sur Créer une règle lorsque vous êtes prêt.
Pour en savoir plus sur 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 de flux non acceptés
- Latences totales des 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é enregistrées dans la source et celui où elles ont été lues par Datastream. Si cette métrique est élevée, cela signifie que Datastream lit les données plus lentement qu'elles ne sont générées à 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, depuis le moment où il est lu dans la source jusqu'à ce qu'il soit écrit dans la destination.
- Latence totale : décalage 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 celui 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
maxConcurrentCdcTaskspour lire plus de journaux en parallèle. - Action pour PostgreSQL : isolez les tables à fort taux de désabonnement dans leurs propres flux dédiés.
- Action pour SQL Server : augmentez le paramètre
maxConcurrentCdcTaskspour lire plus de tables de modifications en parallèle.
- Action pour MySQL/Oracle :
Augmentez le paramètre
- Pénurie de ressources sources : 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 disque.
- Action : Assurez-vous que l'instance source est opérationnelle. Vérifiez l'utilisation du processeur et 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 système (SGA) suffisante est allouée.
- Action : Assurez-vous que l'instance source est opérationnelle. Vérifiez l'utilisation du processeur et de la RAM. Pour PostgreSQL, envisagez d'augmenter la valeur du paramètre
- 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 Cloud Interconnect.
- Transaction unique et volumineuse : un job par lot volumineux, tel qu'un
UPDATEsur des millions de lignes, peut entraîner un pic de latence temporaire.- Action : ce comportement est normal. Attendez que Datastream traite l'événement volumineux. Envisagez de diviser les grands jobs par lot en plus petits à l'avenir.
Si la latence système est élevée, cela peut indiquer un problème dans Datastream ou la destination.
- Action : vérifiez Cloud Logging pour détecter les erreurs persistantes au niveau des lignes (par exemple,
invalid input for type json). Si le flux se trouve dans une boucle de réessai en raison d'erreurs de type de données ou de contraintes, il peut être nécessaire de corriger manuellement les données à la source. Si aucune erreur évidente n'est détectée, contactez l'assistance Google pour obtenir de l'aide.
Combien de tables un même flux peut-il gérer ?
Nous vous recommandons d'inclure jusqu'à 10 000 tables dans un même 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.