Tair (Redis® OSS-Compatible):Migration unidirectionnelle entre instances

Comparaison des méthodes de migration

¹ Il est recommandé d'utiliser la même version de base de données pour la source et la destination afin d'éviter les problèmes de compatibilité.

² Avant de migrer d'une instance à architecture standard vers une instance à architecture en cluster ou avec séparation lecture/écriture, consultez les command limits for those architectures.

Fonctionnement de la migration des données avec DTS

DTS prend en charge deux types de migration. Sélectionnez les deux lors de la configuration d'une tâche pour migrer les données sans interrompre la base de données source.

• Full Migration + Incremental Migration (par défaut) : utilise la logique native Redis SYNC/PSYNC pour écrire les données depuis un snapshot mémoire vers la destination, puis synchronise les mises à jour incrémentielles en temps réel. La migration complète est gratuite ; la migration incrémentielle est facturée selon la durée.

• Full Data Migration : utilise la commande SCAN pour parcourir l'intégralité de la base de données source. N'écrivez pas dans la source pendant ce type de migration, car cela pourrait entraîner une incohérence des données.

Prérequis

Avant de commencer, assurez-vous que :

• Une instance de destination Tair (compatible OSS Redis) existe.

• L'instance de destination dispose d'une mémoire totale supérieure à celle utilisée par l'instance source, avec une marge d'au moins 10 %. Par exemple, si la source utilise 10 Go, la destination doit disposer d'au moins 11 Go de mémoire totale. Une mémoire insuffisante sur la destination entraîne une incohérence des données ou l'échec de la tâche.

• Le chiffrement transparent des données (TDE) n'est not activé sur l'instance de destination. DTS ne prend pas en charge la migration vers des instances avec TDE activé.

• L'instance de destination n'exécute pas Tair (compatible OSS Redis) 2,8. DTS ne prend pas en charge les instances 2,8.

Limites

• Ne modifiez pas la capacité, le type d'instance ou l'endpoint de la base de données source ou de destination pendant l'exécution d'une tâche de migration. Ces opérations entraînent l'échec de la tâche et nécessitent sa reconfiguration.

• Effectuez la migration pendant les heures creuses, car le processus consomme des ressources sur les deux instances.

• La pré-vérification confirme que la politique d'éviction de la base de données de destination est définie sur noeviction. La politique d'éviction par défaut pour Tair (compatible OSS Redis) est volatile-lru. Si la destination manque de mémoire avec volatile-lru, les données sont évictées silencieusement, ce qui provoque une incohérence. En définissant la politique sur noeviction, les écritures échouent (et la tâche échoue) en cas de saturation de la mémoire, mais aucune donnée n'est évictée silencieusement. Pour plus d'informations, consultez la rubrique Redis data eviction policies.

• Une fois la migration terminée, l'ID d'instance et l'endpoint de l'instance de destination diffèrent de ceux de l'instance source. Mettez à jour la configuration de votre client pour utiliser l'endpoint de l'instance de destination.

• Les instances Tair optimisées pour la mémoire persistante ne peuvent pas être mises à niveau sur place vers des instances Redis Open-Source Edition. Si vous souhaitez changer le type d'instance, créez une instance Redis Open-Source Edition et utilisez DTS pour y migrer les données.

Configuration d'une tâche de migration

FAQ

Pourquoi le test de connexion échoue-t-il ?

Vérifiez les points suivants :

• Le compte ou le mot de passe est incorrect. Le format du mot de passe Redis est user:password. Pour plus d'informations, consultez la rubrique Logon methods for an instance.

• Si la base de données source se trouve dans un centre de données sur site ou sur un cloud tiers, un pare-feu réseau peut bloquer DTS. Ajoutez les adresses IP des serveurs DTS de votre région à la liste d'autorisation du pare-feu. Pour obtenir des instructions, consultez la rubrique Add the CIDR blocks of DTS servers to a whitelist.

Pourquoi la tâche de migration échoue-t-elle ?

• Le redimensionnement, le changement de type d'instance ou la modification de l'endpoint de l'instance source ou de destination pendant la migration entraîne l'échec de la tâche. Reconfigurez la tâche une fois l'opération terminée.

• Si l'instance de destination ou un shard de cluster manque de mémoire (erreur OOM), la tâche échoue. Assurez-vous que la destination dispose de suffisamment de mémoire avant de démarrer.

• Si TDE est activé sur l'instance de destination, la migration DTS n'est pas prise en charge.

Pourquoi observe-t-on une incohérence des données ?

• Clés TTL : Si certaines clés de la source ont une politique de durée de vie (TTL), la destination peut contenir moins de clés car les clés expirées ne sont pas toujours supprimées immédiatement.

• Objets List : DTS n'effectue pas de FLUSH sur les données List existantes dans la destination lors de l'utilisation de PSYNC ou SYNC, ce qui peut entraîner des doublons.

• Nouvelles tentatives de migration complète : Si le réseau est interrompu pendant la migration complète, DTS effectue une nouvelle tentative et écrase les clés portant le même nom. Si la source supprime une clé pendant une nouvelle tentative, cette suppression n'est pas synchronisée, de sorte que la destination peut temporairement contenir plus de données que la source.

Pourquoi ne puis-je pas sélectionner une instance Tair (compatible OSS Redis) 2,8 ?

DTS ne prend pas en charge les instances Tair (compatibles OSS Redis) 2,8.

Pourquoi la pré-vérification vérifie-t-elle que la politique d'éviction est définie sur noeviction ?

La politique d'éviction par défaut (maxmemory-policy) pour Tair (compatible OSS Redis) est volatile-lru. Si la destination manque de mémoire, cette politique déclenche l'éviction des données, provoquant une incohérence entre la source et la destination sans faire échouer la tâche. Définir la politique sur noeviction empêche la perte silencieuse de données : si la mémoire est saturée, les écritures échouent et la tâche échoue, mais aucune donnée n'est évictée. Pour plus d'informations, consultez la rubrique Redis data eviction policies.

Pourquoi y a-t-il une clé DTS_REDIS_TIMESTAMP_HEARTBEAT dans la base de données source ?

Pour surveiller la qualité de la migration et de la synchronisation, DTS insère une clé préfixée par DTS_REDIS_TIMESTAMP_HEARTBEAT dans la base de données source afin de suivre les horodatages des mises à jour. Pour les architectures en cluster, DTS insère cette clé dans chaque shard. DTS filtre cette clé lors de la migration, et la clé expire automatiquement à la fin de la tâche.

Quelles commandes sont prises en charge pour la migration incrémentielle ?

Les commandes suivantes sont prises en charge :

• APPEND

• BITOP, BLPOP, BRPOP, BRPOPLPUSH

• DECR, DECRBY, DEL

• EVAL, EVALSHA, EXEC, EXPIRE, EXPIREAT

• FLUSHALL, FLUSHDB

• GEOADD, GETSET

• HDEL, HINCRBY, HINCRBYFLOAT, HMSET, HSET, HSETNX

• INCR, INCRBY, INCRBYFLOAT

• LINSERT, LPOP, LPUSH, LPUSHX, LREM, LSET, LTRIM

• MOVE, MSET, MSETNX, MULTI

• PERSIST, PEXPIRE, PEXPIREAT, PFADD, PFMERGE, PSETEX, PUBLISH

• RENAME, RENAMENX, RESTORE, RPOP, RPOPLPUSH, RPUSH, RPUSHX

• SADD, SDIFFSTORE, SELECT, SET, SETBIT, SETEX, SETNX, SETRANGE, SINTERSTORE, SMOVE, SPOP, SREM, SUNIONSTORE

• ZADD, ZINCRBY, ZINTERSTORE, ZREM, ZREMRANGEBYLEX, ZUNIONSTORE, ZREMRANGEBYRANK, ZREMRANGEBYSCORE

• XADD, XCLAIM, XDEL, XAUTOCLAIM, XGROUP CREATECONSUMER, XTRIM

Remarque : Pour les scripts Lua appelés par EVAL ou EVALSHA, DTS ne peut pas confirmer si le script a été exécuté avec succès sur la destination, car celle-ci ne renvoie pas de résultat d'exécution explicite.

Références

Si vous souhaitez cloner l'intégralité des données d'une instance Tair (compatible OSS Redis) vers une nouvelle instance plutôt que de migrer vers une instance existante, utilisez la fonctionnalité de sauvegarde et de restauration :

• Restore from a backup set

• Restore to a point in time