Synchronisation en temps réel de bases de données complètes : Opérations et optimisation - DataWorks

Prérequis

Avant d'effectuer des opérations ou de dépanner, vérifiez que les conditions suivantes sont remplies :

Exigences en matière d'autorisations

Compte source : Le compte doit disposer des autorisations nécessaires pour lire les métadonnées, telles que les bases de données, les tables, les colonnes, les clés primaires et les index. Il requiert également les autorisations pour lire le journal des modifications source, tel que Binlog, WAL (Write-Ahead Logging) ou Oplog.
Compte cible : Le compte doit disposer des autorisations pour créer des tables, modifier des tables et écrire des données.

Connectivité réseau

Le groupe de ressources doit pouvoir atteindre à la fois la source et la cible. Des problèmes réseau peuvent entraîner des échecs de migration de schéma, un blocage de l'initialisation complète ou une interruption de la synchronisation incrémentielle.

Rétention des journaux source

Une rétention insuffisante des journaux constitue la cause la plus fréquente d'échec de reprise d'une tâche à partir de son décalage d'origine après un arrêt.

Compatibilité de la source de données et du canal

Les capacités de synchronisation (telles que le chargement complet, l'incrémentiel et les DDL) varient selon la source de données. Les options configurables dans l'interface utilisateur représentent les fonctionnalités prises en charge. Vérifiez que les versions de votre source et de votre cible sont compatibles avec le canal.

Portée et applicabilité

Avant de dépanner une tâche de synchronisation en temps réel de base de données complète, examinez le type de tâche, les capacités du canal et les principaux domaines de dépannage afin de confirmer que cette rubrique s'applique à votre scénario.

Critères	Portée applicable	Non applicable / point clé
Type de tâche	Capture des données modifiées (CDC) en temps réel pour plusieurs tables ou une base de données complète.	Ne s'applique pas à la synchronisation en temps réel sur une seule table. Pour les tâches mono-table, consultez Opérations et optimisation pour la synchronisation en temps réel sur une seule table.
Canaux types	Source de base de données vers Hologres, MaxCompute, ADB (AnalyticDB), Doris, StarRocks, SelectDB, Kafka, DLF (Data Lake Formation), Lindorm, Elasticsearch ou OSS (Object Storage Service).	Non applicable aux autres types de canaux.
Axe de dépannage	Rétention des journaux, décalage, clé primaire, DDL, charge source, performances d'écriture cible, partitions, validations, petits fichiers, limitation du débit et arriéré.	En plus de l'état de la tâche, utilisez les métriques et les journaux pour un dépannage précis.

Important

La synchronisation en temps réel d'une base de données complète repose sur la fourniture continue par la source d'un journal des modifications (tel que Binlog, WAL ou Oplog). La cible doit prendre en charge le mode d'écriture actuel, la sémantique de la clé primaire ou de la clé unique, ainsi que les modifications de schéma nécessaires. Si ces conditions ne sont pas remplies, la tâche risque de ne pas s'exécuter correctement ou de ne pas garantir la cohérence des données.

Étapes de la tâche

Une tâche de synchronisation en temps réel de base de données complète progresse généralement à travers les étapes suivantes, chacune ayant un objectif opérationnel différent.

Étape	Description	Objectif opérationnel
Migration du schéma	Lecture des informations sur la base de données, les tables et les colonnes depuis la source, puis création ou mise à jour des structures de table sur la cible.	Autorisations de métadonnées source, autorisations de création de table cible, mappage des types de données, règles de mappage des noms de table.
Initialisation complète	Lecture des données historiques depuis la source et écriture sur la cible pour remplir les données existantes avant le démarrage de la tâche.	Clé de partitionnement, concurrence du chargement complet, nombre de connexions source, groupe de ressources, capacité d'écriture cible, rattrapage complet et incrémentiel.
Synchronisation incrémentielle	Consommation continue des modifications source et écriture sur la cible.	Décalage, débit de lecture et d'écriture, basculement, point de contrôle, événements DDL, rétention des journaux source.

Important

Une tâche de synchronisation en temps réel de base de données complète termine généralement la migration du schéma et l'initialisation complète en premier lieu, puis traite continuellement la synchronisation incrémentielle.

Les données incrémentielles générées lors de l'initialisation complète dépendent de la rétention des journaux source et de la capacité du pipeline en temps réel à rattraper son retard. Par conséquent, lors du démarrage, de l'arrêt, de la réexécution ou de l'ajout de tables à une tâche, vous devez surveiller à la fois la Progression de l'initialisation complète et la Latence en temps réel.

Opérations

Démarrage et arrêt des tâches

Après avoir démarré une tâche, vérifiez qu'elle s'exécute correctement en contrôlant les points suivants dans l'ordre :

Vérifiez que la migration du schéma est terminée et que les structures de table ont été créées sur la cible.
Observez l'initialisation complète pour vous assurer que la lecture et l'écriture des données se déroulent normalement. Le taux de lecture complet et le taux d'écriture doivent être stables, et le nombre de tables terminées doit augmenter continuellement.
Confirmez que la synchronisation incrémentielle fonctionne normalement. La latence en temps réel doit se situer dans une plage raisonnable, sans basculements fréquents et avec des validations de point de contrôle réussies.

Avant d'arrêter une tâche, vérifiez que la période de rétention des journaux source est suffisamment longue pour couvrir la durée d'arrêt. Si une tâche est arrêtée trop longtemps, les journaux Binlog, WAL ou les journaux de messages source peuvent être purgés, empêchant la tâche de reprendre à partir de son dernier décalage enregistré. Lorsque vous reprenez la tâche, elle continue à partir du dernier décalage enregistré. Si le décalage a expiré, vous devez évaluer les risques liés à la réinitialisation du décalage ou à la réinitialisation de la tâche. Pour plus d'informations, consultez la section « Impossible de reprendre une tâche à partir de son décalage précédent après un arrêt » dans la FAQ.

Modification des configurations

Pour une tâche de synchronisation en temps réel de base de données complète en cours d'exécution, vous pouvez avoir besoin d'ajouter ou de supprimer des tables, d'ajuster les mappages de tables ou de modifier les ressources pour les charges de travail complètes ou incrémentielles. Après avoir modifié la configuration, soumettez et appliquez les mises à jour en suivant les instructions à l'écran.

Type de modification	Risques	Recommandations
Ajouter une table	Nécessite une relecture des métadonnées et, selon les capacités du canal, peut déclencher une migration de schéma, une initialisation complète et une synchronisation incrémentielle.	Confirmez que les nouvelles tables correspondent aux règles de sélection, puis actualisez les mappages de tables. Surveillez la progression de l'initialisation complète, le statut d'intégration incrémentielle et la rétention des journaux source pour les nouvelles tables.
Supprimer une table	La suppression de tables d'une tâche en cours d'exécution peut affecter les mappages de tables existants, les données cibles et les dépendances en aval.	Avant de supprimer une table, confirmez qu'aucun processus métier n'en dépend. Si nécessaire, créez une nouvelle tâche pour gérer la portée mise à jour.
Modifier les règles de mappage	Peut provoquer des conflits de noms de tables cibles, des colonnes manquantes, des changements de partition ou des modifications dans la gestion des données existantes.	Avant de soumettre, vérifiez les noms des tables cibles, les types de colonnes, les clés primaires, les partitions, les colonnes supplémentaires et les données existantes sur la cible.
Ajuster les ressources	Les allocations de ressources, la concurrence et le nombre de connexions diffèrent entre l'initialisation complète et la synchronisation incrémentielle. Des ajustements inappropriés peuvent augmenter la charge sur la source ou la cible.	Ajustez les ressources de manière incrémentielle. Après chaque changement, surveillez le taux d'initialisation complète, la latence en temps réel, le basculement, le point de contrôle et l'utilisation des ressources.

Prise d'effet des modifications de configuration :

L'actualisation des mappages de tables et l'ajout de nouvelles tables ne nécessitent généralement pas de mettre la tâche en pause.
L'ajustement des spécifications de ressources, telles que CU (Compute Unit), peut nécessiter le redémarrage de la tâche ou l'attente du prochain point de contrôle pour prendre effet. Suivez les instructions à l'écran.
Modifiez les règles de mappage lorsque la tâche est en pause pour éviter d'affecter les données en cours de traitement.
Si une modification de configuration échoue, revenez à la configuration précédente et resoumettez-la.

Configuration des alertes

Pour les tâches de synchronisation en temps réel de bases de données complètes, configurez des alertes pour au moins les événements suivants :

Type d'alerte	Cas d'utilisation	Description
État de tâche anormal	Toutes les tâches	Déclenche une alerte immédiatement si une tâche échoue ou se termine de manière inattendue.
Latence métier	Toutes les tâches	Déclenche une alerte lorsque la latence en temps réel dépasse le seuil acceptable pour l'activité.
Basculement	Toutes les tâches	Des basculements fréquents indiquent généralement un problème nécessitant une intervention manuelle.
Utilisation des ressources	Scénarios contraints par les ressources	Déclenche une alerte lorsque l'utilisation du CPU, de la mémoire ou du réseau est excessivement élevée.
Notification DDL	Canaux traitant les événements DDL	Les événements DDL peuvent affecter le schéma cible et doivent être surveillés.
Arriéré	Sources Kafka, DataHub ou LogHub	Surveillez l'arriéré des partitions, des shards ou des topics en utilisant la console source ou les métriques de la tâche.

Pour les sources basées sur des journaux comme MySQL et PostgreSQL, surveillez également la période de rétention des journaux tels que Binlog et WAL afin d'éviter les échecs de récupération des tâches causés par l'expiration des journaux.

Pour les étapes détaillées de configuration des règles d'alerte, consultez Règles d'alerte courantes.

Méthodes de dépannage

Échecs de migration de schéma

Les échecs de migration de schéma résultent généralement de problèmes d'autorisations, d'erreurs de lecture des métadonnées, d'incompatibilités de types de données ou de problèmes de création de table sur la cible. Procédez au dépannage dans l'ordre suivant :

Vérifiez si le compte source dispose des autorisations pour lire les métadonnées, y compris les bases de données, les tables, les colonnes, les clés primaires et les index.
Vérifiez la connectivité réseau entre le groupe de ressources de la tâche et à la fois la source et la cible.
Vérifiez si le compte cible dispose des autorisations pour créer des tables, modifier des tables et écrire des données.
Vérifiez si les règles de mappage des noms de table, de base de données ou de schéma génèrent des noms dupliqués ou invalides.
Vérifiez si les types de données, les clés primaires, les colonnes de partition et les colonnes supplémentaires sont compatibles avec la cible.

Lors de la sélection de tables à l'aide d'expressions régulières ou en masse, testez d'abord avec un petit nombre de tables avant d'étendre la portée de la synchronisation.

Initialisation complète lente ou échouée

Si l'initialisation complète est lente ou échoue, déterminez si la tâche est bloquée lors de l'initialisation des ressources, de la lecture depuis la source, de l'écriture sur la cible ou de l'attente du rattrapage des modifications incrémentielles. Vérifiez les métriques telles que le taux de lecture complet, le taux d'écriture, le nombre de tables terminées, les shards restants, le nombre de connexions source et la latence d'écriture cible.

Symptôme	Cause possible	Recommandation
La tâche d'initialisation complète ne démarre pas pendant une longue période.	Mise en file d'attente du groupe de ressources, échec de l'initialisation des ressources ou problèmes de connectivité avec la source ou la cible.	Vérifiez l'état du groupe de ressources et la connectivité réseau. Assurez-vous que les autorisations des comptes source et cible sont correctes.
Faible taux de lecture complet.	Clé de partitionnement mal répartie, requêtes SQL source n'utilisant pas les index, charge source élevée ou connexions ou quota insuffisants.	Vérifiez la clé de partitionnement et les index, et ajustez modérément la concurrence du chargement complet. Si la charge source est élevée, appliquez une limitation du débit ou exécutez la tâche pendant les heures creuses.
Faible taux d'écriture complet.	Capacité d'écriture cible insuffisante, partitions mal conçues ou paramètres d'écriture par lot inadaptés.	Vérifiez la charge cible, les QPS d'écriture, la latence de validation par lot et le nombre de partitions.
Rattrapage incrémentiel lent après la fin de l'initialisation complète.	Un volume important de modifications s'est produit à la source pendant l'initialisation complète, et le pipeline en temps réel doit traiter l'arriéré des journaux.	Vérifiez si la latence en temps réel diminue continuellement et assurez-vous que la période de rétention des journaux source est suffisante.

Latence en temps réel élevée

Lorsque la latence en temps réel augmente, déterminez d'abord si la tâche est toujours en phase de rattrapage de l'initialisation complète. Identifiez ensuite si le goulot d'étranglement se situe au niveau du lecteur, dans le pipeline de traitement ou au niveau de l'écriture.

Symptôme	Cause possible	Recommandation
La latence reste élevée après la fin de l'initialisation complète.	Arriéré important de modifications incrémentielles accumulées pendant l'initialisation complète ; lecture lente des journaux source ; écriture de rattrapage lente sur la cible.	Surveillez le taux de lecture incrémentiel, le taux d'écriture et la durée de rétention des journaux source pour confirmer que la latence diminue continuellement.
Temps d'attente du lecteur élevé.	Augmentation soudaine du volume de modifications source, transactions volumineuses, arriéré des journaux source ou déséquilibre des partitions/shards.	Vérifiez les pics d'écriture source, la croissance des journaux et la distribution des partitions ou des shards.
Temps d'attente de l'écriture élevé.	Performances d'écriture cible lentes, limitation du débit, connexions insuffisantes ou trop de partitions dynamiques.	Vérifiez les ressources cibles, les QPS d'écriture, la latence de validation par lot et la conception des partitions.
Basculements fréquents.	Mémoire insuffisante, instabilité des services externes, échecs de point de contrôle ou erreurs de traitement DDL.	Examinez les journaux avant et après le basculement. Analysez la mémoire, l'utilisation des ressources et les métriques de point de contrôle pour résoudre le problème.
La latence augmente après un événement DDL.	Traitement DDL chronophage ou échec de la modification du schéma sur la cible.	Passez en revue l'événement DDL et les autorisations cibles pour confirmer que la politique de gestion DDL est conforme aux attentes.

Si la source est Kafka, DataHub ou LogHub, une seule partition ou shard peut généralement être consommée par un seul processus concurrent. Si les données sont concentrées dans quelques partitions, l'augmentation de la concurrence globale de la tâche peut ne pas aider.

Nouvelles tables non synchronisées

Si une nouvelle table n'est pas synchronisée, vérifiez les points suivants dans l'ordre :

La nouvelle table correspond-elle aux règles de sélection actuelles de la base de données et des tables ?
Le mappage de table a-t-il été actualisé avec succès ?
Vérifiez que les tables ont été créées ou que le schéma a été migré sur la cible.
La tâche prend-elle en charge l'ajout dynamique de tables lors de l'exécution ?
Vérifiez les détails d'exécution pour la migration du schéma, l'initialisation complète ou les événements en temps réel de la table correspondante.

Pour les canaux qui ne prennent pas en charge l'ajout dynamique de tables, modifiez la configuration et republiez, ou créez une nouvelle tâche pour gérer les nouvelles tables. Si les nouvelles tables nécessitent des données historiques, confirmez si le canal effectue une initialisation complète pour celles-ci. Sinon, utilisez un remplissage de données ou une capacité de synchronisation complète distincte.

Recommandations d'optimisation

Élément d'optimisation	Scénario	Recommandation
Spécifications des ressources de chargement complet / Compute Unit (CU)	L'initialisation complète est mise en file d'attente, la vitesse d'exécution est faible ou l'utilisation du groupe de ressources est élevée.	Augmentez progressivement les ressources de chargement complet ou exécutez les tâches pendant les heures creuses. Surveillez le taux de lecture du chargement complet, le taux d'écriture et la charge source.
Concurrence du chargement complet et clé de partitionnement	La phase de chargement complet s'exécute, mais la vitesse globale est lente.	Choisissez une clé de partitionnement uniformément répartie et indexée. Augmentez modérément la concurrence. Si la charge source est élevée, réduisez la concurrence ou appliquez une limitation du débit.
Connexions source / Quota	L'initialisation complète signale des erreurs liées aux connexions, au Quota ou à la limitation du débit.	Réduisez la concurrence des tâches provenant de la même source. Ou augmentez le nombre de connexions et le Quota si la capacité source le permet.
Spécifications des ressources incrémentielles / CU	L'utilisation du CPU, de la mémoire, du réseau ou du groupe de ressources est élevée.	Augmentez progressivement les ressources. Observez si la latence, le basculement et les performances du point de contrôle s'améliorent.
Concurrence incrémentielle	Plusieurs tables, partitions ou shards disposent d'un parallélisme suffisant.	Confirmez d'abord l'absence de points chauds sur une seule table ou de goulots d'étranglement sur un seul shard. Ensuite, augmentez la concurrence.
Point de contrôle / Intervalle de vidage	La cible valide fréquemment ou la surcharge des validations par lot est élevée.	Augmentez légèrement l'intervalle et observez le débit et la latence de visibilité des données. Ne l'augmentez pas trop d'un coup.
Paramètres d'écriture par lot de la cible	Le temps d'attente de la cible est élevé.	Ajustez les paramètres de lot, de vidage, de validation ou de pool de connexions en fonction des limitations du produit cible.
Granularité des partitions dynamiques	La cible comporte trop de partitions ou subit une pression de vidage élevée.	Privilégiez l'ajustement de la granularité des partitions. Évitez d'utiliser des champs à cardinalité élevée pour le partitionnement, tels que les horodatages à la seconde, les ID de commande ou les ID utilisateur.

Remarque

L'initialisation complète et la synchronisation incrémentielle ont des objectifs d'optimisation différents. L'initialisation complète vise à terminer l'écriture des données historiques de manière stable. La synchronisation incrémentielle vise à réduire continuellement la latence. Après l'optimisation, observez les performances pendant au moins une fenêtre stable. Juger de l'efficacité uniquement sur le débit à court terme après un redémarrage peut être trompeur.

Pour les paramètres de ressources recommandés, consultez CU recommandés pour l'intégration des données. Ajustez les paramètres selon vos besoins.

Foire aux questions

Les questions suivantes proviennent de l'historique de dépannage des tâches de synchronisation en temps réel de bases de données complètes et sont organisées par phase de tâche. Lors du dépannage, confirmez d'abord la phase actuelle de votre tâche. Ensuite, effectuez une vérification croisée à l'aide des événements de tâche, des journaux d'exécution, des métriques, de la rétention des journaux source et des résultats cibles.

Problèmes liés à la migration de schéma

Problème	Zones clés à vérifier	Action recommandée
L'actualisation du mappage de table est lente, expire ou les tables ne sont pas sélectionnables	Connectivité du groupe de ressources, autorisations de métadonnées source, nombre de bases de données et de tables, nombre de champs, types d'objets source et cache de la source de données	Réduisez d'abord la portée des bases de données et des tables pour tester. Confirmez que le compte dispose des autorisations pour lire les bases de données, les tables, les champs, les clés primaires et les index. Si un objet n'est pas sélectionnable, sa disponibilité est déterminée par la portée prise en charge du canal actuel.

Problèmes liés à l'initialisation complète

Problème	Zones clés à vérifier	Action recommandée
L'initialisation complète est bloquée ou ne parvient pas à démarrer	File d'attente du groupe de ressources, connectivité source ou cible, quota de la source de données, ressources pour la phase d'initialisation complète et résultats de création de table sur la cible	Confirmez d'abord que la migration du schéma est terminée. Ensuite, vérifiez si les sous-tâches complètes ont démarré. Si le quota ou le nombre de connexions est insuffisant, réduisez la concurrence ou augmentez le quota pour la source ou la cible.

Problèmes liés à la synchronisation incrémentielle

Problème	Zones clés à vérifier	Action recommandée
La latence en temps réel reste élevée après la fin de l'initialisation complète	Données incrémentielles accumulées pendant l'initialisation complète, vitesse de lecture des journaux source, vitesse d'écriture cible, points de contrôle et basculement	Observez si la latence diminue continuellement. Si ce n'est pas le cas, vérifiez le décalage de lecture, le temps d'attente d'écriture, les échecs de point de contrôle et la limitation du débit sur la cible.
La tâche ne peut pas reprendre à partir de son décalage précédent après un arrêt	Vérifiez si la période de rétention de Binlog, Write-Ahead Logging (WAL), des journaux de messages ou des décalages de consommation a expiré. Vérifiez si l'instance source a été reconstruite ou si ses journaux ont été effacés.	Avant d'arrêter une tâche, confirmez que la période de rétention des journaux couvre la durée d'arrêt prévue. Si un décalage n'est pas disponible, vous devez généralement le réinitialiser ou réinitialiser la tâche. Évaluez les risques de duplication et de perte de données avant de poursuivre.
La tâche échoue ou la latence augmente après une opération Data Definition Language (DDL)	Types d'opérations DDL que la source peut générer, actions de gestion DDL prises en charge par la cible, stratégie DDL de la tâche et autorisations	Passez en revue les événements DDL et les résultats de la modification du schéma sur la cible. N'ignorez pas les opérations DDL non prises en charge. Confirmez d'abord leur impact sur le schéma cible et la cohérence des données.
Les données cibles sont incorrectes après des opérations DELETE ou UPDATE	La cible dispose-t-elle d'une clé primaire ou unique pour localiser les enregistrements ? Le mappage de la clé primaire est-il cohérent ? Le mode d'écriture prend-il en charge les mises à jour et les suppressions ?	Vérifiez la clé primaire source, la clé primaire cible, le mappage de table et les journaux de données erronées. Si la cible ne possède pas de clé primaire valide ou si le mappage est incohérent, les opérations UPDATE et DELETE peuvent ne pas s'appliquer aux bons enregistrements cibles.

Problèmes liés aux sources de messages

Problème	Zones clés à vérifier	Action recommandée
Latence élevée des sources de messages telles que Kafka, DataHub et LogHub	Vérifiez la présence de points chauds dans les partitions, les shards ou les topics. Vérifiez si la concurrence de consommation dépasse le nombre de partitions pouvant être consommées en parallèle. Vérifiez si le décalage de consommation présente un retard significatif.	Vérifiez d'abord les goulots d'étranglement sur une seule partition ou un seul shard. Si les points chauds sont concentrés, l'augmentation de la concurrence totale peut ne pas être efficace. Ajustez plutôt les partitions source ou la capacité d'écriture de la cible.

Problèmes liés à l'écriture sur la cible

Problème	Zones clés à vérifier	Action recommandée
Écritures lentes sur des cibles telles que MaxCompute en raison d'un nombre excessif de partitions	Granularité des champs de partition dynamique, nombre de partitions au sein d'un seul point de contrôle, durée Tunnel ou de validation et limitation du débit de la cible	Réduisez la granularité des partitions ou évitez d'utiliser des champs à cardinalité élevée pour le partitionnement. Ensuite, ajustez les validations par lot, le cache de partition et les spécifications de ressources en fonction des capacités de la cible.

Problèmes liés à la cohérence des données

Problème	Zones clés à vérifier	Action recommandée
Les données historiques ne sont pas synchronisées après l'ajout d'une nouvelle table	Vérifiez si la nouvelle table correspond aux règles de sélection. Vérifiez si le mappage de table a été actualisé avec succès. Vérifiez si le canal prend en charge l'initialisation complète pour les nouvelles tables. Vérifiez si la nouvelle table est configurée uniquement pour la synchronisation incrémentielle.	Si vous avez besoin de données historiques, confirmez que l'initialisation complète est activée ou a été déclenchée pour la nouvelle table. Si cela n'est pas pris en charge, utilisez un processus de remplissage de données ou une tâche de synchronisation complète distincte pour remplir les données historiques.
Les données deviennent incohérentes après la suppression d'une table lors de l'exécution ou à la source	Vérifiez si la table supprimée correspond toujours aux règles de la tâche. Vérifiez comment la stratégie DDL gère DROP TABLE. Vérifiez les éventuelles dépendances en aval sur la table cible.	Avant de supprimer une table lors de l'exécution, confirmez qu'aucun processus métier n'en dépend. La suppression d'une table à la source ne la nettoie pas automatiquement sur la cible. Si nécessaire, gérez la table cible séparément conformément à vos politiques de gouvernance des données.
Une quantité anormale de données erronées est générée	Vérifiez si la tâche est configurée pour tolérer les données erronées. Vérifiez les modifications apportées aux types de champs, aux longueurs, aux clés primaires, aux contraintes de non-nullité ou aux limites d'écriture de la cible.	N'augmentez pas simplement le seuil de données erronées pour permettre à la tâche de continuer. Déterminez d'abord si les données erronées entraîneront des données manquantes ou des anomalies de champ sur la cible. Ensuite, décidez s'il faut corriger les données, ajuster le mappage ou tolérer temporairement les erreurs.

Problèmes spécifiques à PostgreSQL

Problème	Zones clés à vérifier	Action recommandée
Les fichiers WAL s'accumulent à la source PostgreSQL	Retard du slot de réplication, décalage de consommation, points de contrôle et validation correcte des décalages par la tâche	Si la tâche consomme des données normalement mais que la taille WAL ne diminue pas, vérifiez le retard du slot de réplication et l'état de validation des décalages. Cela permet d'éviter que le disque source ne soit saturé par les fichiers WAL.

Liste de contrôle des opérations à haut risque

Avant de supprimer des tables, d'ajouter un grand nombre de tables, de redémarrer une tâche, de relancer une initialisation complète ou d'apporter des modifications majeures aux paramètres, vérifiez chaque élément de cette liste de contrôle. Si une vérification échoue, prenez la mesure recommandée avant de poursuivre.

La période de rétention des journaux source est-elle suffisamment longue pour l'initialisation complète et le rattrapage incrémentiel ?
Si la cible contient des données existantes ou des dépendances en aval, une stratégie claire de remplacement, d'ajout ou de nettoyage est-elle en place avant de relancer l'initialisation complète ?
Les nouvelles tables nécessitent-elles des données historiques et le canal actuel prend-il en charge l'initialisation complète pour celles-ci ?
Y a-t-il des instructions Data Definition Language (DDL) non traitées ou des basculements fréquents ?
Les alertes couvrent-elles l'état de la tâche, les exceptions d'initialisation complète, la latence métier, le basculement et les DDL ?