Data Transmission Service:Cross-account migration

Limites de la base de données source

• Exigence de bande passante : le serveur hébergeant la base de données source doit disposer d'une bande passante sortante suffisante. Sinon, la vitesse de migration des données sera affectée.

• La version 2.8 de Tair (compatible Redis OSS) n'est pas prise en charge en tant que source.

• Si vous effectuez uniquement une migration complète (sans migration incrémentielle), arrêtez les écritures sur la source pendant la migration pour éviter toute incohérence des données.

• Lors de la migration d'une source Basic Edition vers une destination à architecture de cluster, utilisez uniquement des opérations sur une seule clé. Les commandes multi-clés qui s'étendent sur plusieurs slots renvoient l'erreur suivante :

  CROSSSLOT Keys in request don't hash to the same slot

• DTS insère une clé avec le préfixe DTS_REDIS_TIMESTAMP_HEARTBEAT dans la source pour suivre les horodatages de mise à jour. Si la source utilise une architecture de cluster, cette clé est insérée dans chaque shard. La clé est filtrée pendant la migration et expire à la fin de la tâche.

• Si la source est une instance en lecture seule ou si le compte DTS ne dispose pas de l'autorisation SETEX, la latence signalée peut être inexacte.

• Pour améliorer la stabilité de la migration, augmentez la valeur du paramètre repl-backlog-size dans le fichier redis.conf.

• Si la source est une instance Tair Enterprise Edition dont le Storage Medium est défini sur Persistent Memory, définissez le paramètre appendonly sur yes. Pour plus de détails, consultez la Procédure.

• Si la source est une instance enfant d'un Global Distributed Cache, DTS migre uniquement cette instance enfant. Les autres instances enfants ne sont pas prises en charge.

Autres limites

• Ni la source ni la destination ne prennent en charge les instances de stockage de capacité Tair (compatible Redis OSS) Enterprise Edition.

• Si le chiffrement transparent des données (TDE) est activé sur l'une ou l'autre instance, DTS ne peut pas effectuer la migration.

• Si la destination manque de mémoire, la politique d'éviction par défaut (maxmemory-policy) est volatile-lru, ce qui peut provoquer une incohérence des données. Pour éviter une perte silencieuse de données, définissez la politique d'éviction de la destination sur noeviction. Avec noeviction, les opérations d'écriture échouent lorsque la mémoire est pleine et la tâche s'arrête, mais aucune donnée n'est supprimée silencieusement. Pour plus de détails sur les politiques, consultez la rubrique Présentation des politiques d'éviction des données Redis.

• Si l'instance de destination utilise une architecture de cluster et qu'un shard atteint sa limite de mémoire, ou si l'instance manque d'espace de stockage, la tâche DTS échoue avec une erreur d'épuisement de la mémoire (OOM).

• Les opérations de mise à l'échelle (ajout ou suppression de shards), les modifications de spécifications ou les modifications d'endpoint ou de port sur l'une ou l'autre instance pendant la migration interrompront la tâche. Si cela se produit, effacez toutes les données synchronisées de la destination et reconfigurez la tâche.

• Après un événement de basculement (y compris le basculement maître/esclave) sur la destination, les données peuvent être écrites uniquement en mémoire sans réplication vers le secondaire, ce qui entraîne une perte de données.

• Si une instance de migration inclut à la fois des tâches complètes et incrémentielles, le redémarrage de l'instance peut amener DTS à réexécuter les deux tâches.

• Le redémarrage d'une instance de migration peut entraîner l'exécution répétée de commandes non idempotentes (telles que INCRBY ou LPUSH), conduisant à une incohérence des données.

• Pour les scripts Lua invoqués via EVAL ou EVALSHA, DTS ne peut pas confirmer l'exécution réussie pendant la migration incrémentielle.

• Pour les structures de données List, DTS ne vide pas les données de destination existantes lors de l'utilisation de psync ou sync, ce qui peut entraîner des entrées en double.

• Si les clés de la source ont des politiques d'expiration, le nombre de clés visible dans la destination (par exemple, via INFO) peut être inférieur à celui de la source. Les clés sans politiques d'expiration ou les clés non expirées sont cohérentes entre la source et la destination.

• Lorsque la Access Method est Public IP Address, le Instance Mode ne prend pas en charge l'option Cluster.

• Effectuez la migration pendant les heures creuses. La migration complète consomme des ressources de lecture et d'écriture sur les deux instances.

• Après la migration complète, l'espace de stockage de la destination sera plus grand que celui de la source en raison des opérations INSERT concurrentes.

• DTS tente de récupérer automatiquement les tâches ayant échoué pendant sept jours maximum. Avant de basculer le trafic vers la destination, arrêtez ou libérez la tâche, ou révoquez l'autorisation d'écriture du compte DTS en utilisant REVOKE pour empêcher les tâches récupérées d'écraser les données de destination.

• Si une instance Tair (compatible Redis OSS) chiffrée TLS est impliquée, connectez-vous à DTS en utilisant l'option SSL-encrypted (TLSv1.3 n'est pas pris en charge). La connexion avec l'option SSL-encrypted à une source de type Alibaba Cloud Instance n'est actuellement pas prise en charge.

• Si une tâche échoue, l'équipe support DTS tentera de la restaurer dans un délai de huit heures. La restauration peut impliquer le redémarrage de la tâche ou l'ajustement des paramètres de la tâche. Seuls les paramètres de la tâche DTS sont modifiés, pas les paramètres de la base de données. Pour connaître les paramètres ajustables, consultez la rubrique Modifier les paramètres de l'instance.

Cas particuliers pour les sources Redis gérées par l'utilisateur

Lorsque la Access Method de la source n'est pas Alibaba Cloud Instance :

• Le basculement maître/esclave sur la source provoque l'échec de la tâche.

• DTS calcule la latence en comparant l'horodatage du dernier enregistrement migré avec l'heure actuelle. Si la source n'a aucune activité DML pendant une période prolongée, la latence affichée peut être inexacte. Exécutez une opération DML sur la source pour actualiser la latence. Si vous migrez une base de données entière, utilisez une table de heartbeat qui écrit des données chaque seconde.

• Les modifications de l'endpoint Redis pendant la migration (par exemple, en raison d'une migration d'instance ou d'un basculement maître/esclave) peuvent provoquer des tentatives, des retards, des échecs ou une incohérence des données. Surveillez l'état de la tâche et reconfigurez-la si un comportement anormal apparaît.

Étape 1 : Ouvrir la liste des tâches de migration

Connectez-vous à l'aide du compte de destination et accédez à la liste des tâches de migration de données en utilisant l'une des méthodes suivantes :

Étape 2 : Créer la tâche

Cliquez sur Create Task pour ouvrir la page de configuration de la tâche.

Étape 3 : Configurer les bases de données source et de destination

Configurez les paramètres pour les bases de données source et de destination :

Nom de la tâche

Base de données source

Base de données de destination

Étape 4 : Tester la connectivité

Cliquez sur Test Connectivity and Proceed en bas de la page.

Assurez-vous que les plages d'adresses IP du service DTS sont ajoutées aux paramètres de sécurité des deux instances. Consultez la rubrique Ajouter les adresses IP des serveurs DTS à une liste d'autorisation .

Si l'une ou l'autre instance est gérée par l'utilisateur (la Méthode d'accès n'est pas Alibaba Cloud Instance ), cliquez sur Test Connectivity dans la boîte de dialogue CIDR Blocks of DTS Servers .

Étape 5 : Configurer les objets de migration

Sur la page Configure Objects , définissez les paramètres suivants :

Paramètre	Description
Migration Types	Sélectionnez à la fois Full Data Migration et Incremental Data Migration pour une migration sans temps d'arrêt. Sélectionnez uniquement Full Data Migration si le compte DTS ne dispose pas de l'autorisation SYNC/PSYNC sur la source.
Processing Mode of Conflicting Tables	Precheck and Report Errors : La pré-vérification vérifie que la destination est vide. Si ce n'est pas le cas, la tâche ne démarre pas. Ignore Errors and Proceed : Ignore la vérification de destination vide. Si une clé de la destination porte le même nom qu'une clé source, les données source écrasent la destination. Cela peut entraîner une perte de données — procédez avec prudence.
Source Objects	Cliquez sur les objets dans la zone Source Objects , puis cliquez sur pour les déplacer vers Selected Objects. Sélectionnez des bases de données entières ou utilisez le filtrage des données pour des clés spécifiques.
Selected Objects	Pour mapper des bases de données (DB 0–255) ou filtrer par préfixe de clé, faites un clic droit sur une base de données dans Selected Objects et configurez-la dans la boîte de dialogue Edit Schema . Consultez les rubriques Mappage de schéma et Définir les conditions de filtre.

Cliquez sur Next Advanced Settings et configurez les éléments suivants :

Cliquez sur Next Data Verification pour configurer la vérification des données. Pour plus de détails, consultez la rubrique Configurer une tâche de vérification des données.

Étape 6 : Exécuter la pré-vérification

Cliquez sur Next: Save Task Settings and Precheck .

Pour prévisualiser les paramètres API pour cette configuration, survolez le bouton et cliquez sur Preview OpenAPI parameters .

DTS exécute une pré-vérification avant de démarrer la migration. La tâche ne démarre qu'après la réussite de la pré-vérification.

Si la pré-vérification échoue, cliquez sur View Details à côté de l'élément ayant échoué, corrigez le problème et relancez la pré-vérification.

Si un avertissement apparaît : pour les éléments qui ne peuvent pas être ignorés, corrigez le problème et relancez. Pour les éléments qui peuvent être ignorés, cliquez sur Confirm Alert Details > Ignore > OK > Precheck Again . Ignorer les avertissements peut entraîner une incohérence des données.

Étape 7 : Acheter et démarrer

1. Lorsque le Success Rate atteint 100 %, cliquez sur Next: Purchase Instance .

2. Sur la page Purchase , sélectionnez la classe d'instance :

   Paramètre	Description
   Resource Group Settings	Sélectionnez le groupe de ressources pour cette instance. Par défaut : groupe de ressources par défaut. Consultez la rubrique Qu'est-ce que Resource Management ?.
   Instance Class	Sélectionnez une spécification en fonction de votre volume de migration et de vos exigences de vitesse. Consultez la rubrique Spécifications des liens de migration de données.

3. Lisez et acceptez les Data Transmission Service (Pay-as-you-go) Service Terms .

4. Cliquez sur Buy and Start , puis cliquez sur OK dans la boîte de dialogue de confirmation.

Surveillez la progression de la migration sur la page de migration des données.

Si la tâche inclut à la fois la migration complète et incrémentielle, elle est affichée comme Incremental Data Migration sur la page de liste des tâches de migration.