Tous les produits
Search
Centre de documentation

Data Transmission Service:Synchronize or migrate MongoDB collections with TTL indexes

Dernière mise à jour :Aug 10, 2026

Lorsque vous utilisez Data Transmission Service (DTS) pour synchroniser ou migrer des collections MongoDB dotées d'index Time-to-Live (TTL), la suppression automatique basée sur le TTL côté destination peut entraîner des retards dans les tâches et des incohérences de données. Pour éviter ce problème, définissez temporairement la valeur d'expiration maximale des index TTL sur la destination pendant la synchronisation ou la migration.

Contexte

Lors de la migration d'une instance MongoDB contenant des collections avec des index TTL (par exemple, des sessions utilisateur, des journaux ou des données de cache), vous pouvez utiliser DTS pour effectuer une synchronisation complète et incrémentielle. L'objectif est de garantir une perte de données nulle tout en minimisant l'impact sur les services.

Cependant, le mécanisme de suppression automatique TTL peut entrer en conflit avec la synchronisation DTS, provoquant une latence des tâches et des incohérences de données :

  • Les suppressions REDONDANTES réduisent l'efficacité : Lorsque l'index TTL source supprime les données expirées, il écrit un enregistrement DELETE dans l'Oplog. DTS rejoue cette opération DELETE sur la destination. Si l'index TTL de la destination a déjà supprimé les mêmes données, MongoDB renvoie un nombre de lignes affectées inattendu, ce qui déclenche une gestion des exceptions et ralentit la migration.

  • Incohérence des données due à la suppression asynchrone par TTL : Les index TTL ne suppriment pas les données en temps réel. Il est possible que des données expirées existent encore sur la source alors qu'elles ont déjà été supprimées sur la destination, créant ainsi une incohérence.

    Exemple :

    L'Oplog ou ChangeStream de MongoDB enregistre uniquement les champs mis à jour lors d'une opération UPDATE, et non le document complet. Si une opération UPDATE ne trouve pas les données cibles sur la destination, DTS ignore l'opération.

    Moment

    Instance source

    Instance de destination

    1

    Le service insère des données

    2

    DTS synchronise l'opération INSERT

    3

    Les données ont expiré mais n'ont pas encore été supprimées par l'index TTL

    4

    Le service met à jour les données (par exemple, modifie le champ de l'index TTL pour changer l'heure d'expiration)

    5

    L'index TTL supprime les données

    6

    DTS synchronise l'opération UPDATE, mais les données sont introuvables. L'opération est ignorée.

    Par conséquent, ce document est absent de l'instance MongoDB de destination.

Solution

Définissez temporairement les index TTL de la destination avec la valeur d'expiration maximale pendant toute la durée de la synchronisation ou de la migration (phases complète et incrémentielle). Rétablissez les paramètres TTL d'origine après avoir basculé le trafic vers la nouvelle instance.

Procédure :

  1. Sauvegardez les paramètres des index TTL : Sur la base de données source, exécutez un script pour identifier toutes les collections dotées d'index TTL et enregistrer leurs valeurs d'expiration.

    Cliquez pour afficher l'exemple de script

    // Script: Find and print information about all TTL indexes
    const collections = db.getCollectionNames();
    let ttlIndexes = [];
    collections.forEach(collName => {
        const indexes = db.getCollection(collName).getIndexes();
        indexes.forEach(idx => {
            if (idx.hasOwnProperty('expireAfterSeconds')) {
                console.log(`Found TTL index -> Collection: ${collName}, Index name: ${idx.name}, Expires after: ${idx.expireAfterSeconds} seconds`);
                ttlIndexes.push({
                    collection: collName,
                    name: idx.name,
                    expireAfterSeconds: idx.expireAfterSeconds
                });
            }
        });
    });
    // Save the following JSON output to a file for later steps.
    printjson(ttlIndexes);
  2. Désactivez la suppression automatique TTL sur la destination :

    1. Vérifiez si l'instance de destination contient déjà les collections cibles et les index TTL.

    2. Dans le cas contraire, utilisez la migration de schéma pour synchroniser d'abord les collections. Connectez-vous ensuite à la base de données de destination et définissez la durée d'expiration sur la valeur maximale afin d'éviter toute suppression automatique pendant le processus.

    3. Si elles existent déjà, connectez-vous à la base de données de destination avant de démarrer la tâche DTS et définissez l'expiration TTL sur la valeur maximale pour empêcher la suppression automatique durant le processus.

  3. Exécutez et surveillez la tâche DTS : Démarrez la tâche de synchronisation DTS complète et incrémentielle. La désactivation de la suppression automatique TTL sur la destination permet à DTS de rejouer toutes les opérations provenant de la source sans conflit.

    1. Créez et démarrez la tâche de synchronisation ou de migration des données dans la console DTS.

    2. Surveillez les métriques suivantes pendant le processus :

      • Latence de la tâche DTS : Vérifiez que la latence de la synchronisation incrémentielle reste faible sur la page des détails de la tâche.

      • Utilisation du stockage de la destination : Étant donné que les données sur la destination n'expireront pas pendant la migration, l'utilisation du stockage augmente continuellement. Assurez-vous qu'un espace de stockage suffisant est disponible.

  4. Rétablissez les paramètres TTL : Une fois la synchronisation DTS terminée et le trafic basculé vers la nouvelle instance, restaurez les valeurs d'expiration TTL d'origine à partir de votre sauvegarde. Un thread d'arrière-plan MongoDB nettoiera alors les documents expirés accumulés pendant la migration.

Remarques :

  • Pendant la synchronisation ou la migration incrémentielle, DTS rejoue toujours les opérations DELETE générées par l'index TTL source sur les données expirées.

  • Avec l'augmentation de l'expiration TTL sur la destination, celle-ci stocke les données déjà expirées sur la source en cas de latence pendant la synchronisation/migration. Prévoyez un stockage suffisant sur la destination en fonction du volume d'écriture de la source.

  • Pour les collections ayant des valeurs TTL très courtes (données temporaires ou journaux), évitez de migrer les données historiques. Dans des cas extrêmes, les données entièrement migrées pourraient expirer presque immédiatement sur la destination, laissant la collection vide. Envisagez plutôt une stratégie de double écriture ou une migration incrémentielle uniquement.