Déplacez une instance Tair (compatible Redis OSS) vers une autre zone au sein de la même région via la console ou l'API MigrateToOtherZone. Cette opération permet notamment de réduire la latence réseau en colocalisant l'instance avec des instances ECS, de mettre en place une reprise après sinistre inter-zones ou d'accéder aux ressources de zone nécessaires à une mise à niveau du type d'instance.
Après la migration, les données de l'instance, les comptes de base de données, les endpoints et les paramètres de la liste d'autorisation restent inchangés.
Prérequis
Avant de commencer, assurez-vous d'avoir :
(Instances cloud-native) Libéré l'endpoint public, s'il existe
(Instances classiques) Libéré l'endpoint public et l'endpoint de connexion directe, s'ils existent
Types de migration pris en charge
| Type de migration | Cas d'utilisation |
|---|---|
| Zone unique vers zone unique | Placez l'instance dans la même zone que votre instance ECS pour réduire la latence du réseau interne |
| Multi-zones vers multi-zones | Ajustez la répartition des zones tout en maintenant la reprise après sinistre inter-zones |
| Zone unique vers multi-zones | Activez la reprise après sinistre inter-zones. Une instance mono-zone est résiliente aux pannes au niveau du serveur et du rack. Une instance multi-zones est déployée sur plusieurs centres de données et peut résister aux pannes complètes d'un centre de données |
| Multi-zones vers zone unique | Consolidez vers une zone unique lorsque des fonctionnalités spécifiques l'exigent |
Impacts
Déconnexion transitoire
Instances cloud-native
La survenue d'une déconnexion transitoire dépend de la zone modifiée :
| Scénario | Déconnexion transitoire |
|---|---|
| Ajout d'une zone secondaire à une instance mono-zone (la zone principale reste identique) | Non |
| Modification uniquement de la zone secondaire, qui ne contient pas de nœud principal | Non |
| Modification de la zone hébergeant le nœud principal, y compris les cas où un basculement haute disponibilité (HA) a déplacé le nœud principal vers la zone secondaire | Oui |
| Modification de la zone secondaire d'une instance avec séparation lecture/écriture lors de la connexion via l'endpoint de la zone secondaire | Oui |
Instances classiques
Une migration de zone peut provoquer une déconnexion transitoire pour les instances classiques.
État en lecture seule
L'instance peut passer en état de lecture seule pendant jusqu'à 60 secondes pour synchroniser les données incrémentielles et éviter les doubles écritures causées par le cache DNS. Dans les scénarios à forte écriture, cette période de lecture seule peut être plus longue.
Aucun état de lecture seule ne se produit si le nœud principal n'est pas migré. Cela s'applique uniquement aux instances cloud-native.
Modifications du mappage DNS
Une migration de zone modifie l'adresse IP virtuelle (VIP) sous-jacente et le mappage DNS. Connectez-vous toujours à l'instance en utilisant son endpoint, tel que r-bp10b3fa3500****.redis.rds.aliyuncs.com, et non directement la VIP.
Les anciennes versions de Jedis peuvent échouer à résoudre correctement l'endpoint après la migration. Si vous utilisez Jedis, assurez-vous que la version est 3.10.0 ou ultérieure. Pour plus de détails, consultez les recommandations de mise à niveau du client Jedis.
Mise à niveau automatique de la version mineure
Si l'instance exécute une version mineure obsolète, le système la met automatiquement à niveau vers la dernière version mineure pendant la migration. Les versions mineures conservent la compatibilité ascendante, donc aucun problème de compatibilité ne survient.
Réinitialisation de la bande passante
Après la migration, la bande passante est réinitialisée à la valeur par défaut. Si vous avez précédemment ajusté la bande passante manuellement, reconfigurez-la après la migration. Auto Scaling restaure les paramètres de bande passante personnalisés lorsque la prochaine règle de mise à l'échelle se déclenche.
Si le nœud principal n'est pas migré, le plan de bande passante reste inchangé. Cela s'applique uniquement aux instances cloud-native.
Recommandations
Implémentez un mécanisme de reconnexion dans votre application.
Effectuez la migration pendant les heures creuses pour minimiser l'impact sur les utilisateurs.
Planifiez la migration pendant la fenêtre de maintenance pour un basculement contrôlé.
Migrer une instance vers une autre zone
Cette opération peut provoquer des déconnexions transitoires. Nous vous recommandons d'effectuer cette opération pendant les heures creuses et de vous assurer que votre application peut se reconnecter automatiquement à votre instance.
Connectez-vous à la console et accédez à la page Instances. Dans la barre de navigation supérieure, sélectionnez la région de l'instance. Trouvez l'instance et cliquez sur son ID.
Dans la section Basic Information, cliquez sur Migrate à côté de Zone.
-
Configurez les paramètres suivants dans le panneau qui s'affiche.
Paramètre Description Primary zone change Sélectionnez la zone cible. Secondary zone change (facultatif) Sélectionnez une zone secondaire pour activer la reprise après sinistre inter-zones. Le nœud secondaire migre vers la zone spécifiée. Si vous ne spécifiez pas de zone secondaire, les nœuds principaux et secondaires migrent tous deux vers la zone principale. Virtual Switch: Sélectionnez le vSwitch de destination. Si aucun vSwitch n'existe dans la zone cible, créez-en un au préalable. Ce paramètre n'apparaît que pour les instances VPC. Execution Time Update Now : La migration démarre immédiatement après avoir cliqué sur OK. La migration est terminée lorsque l'état de l'instance devient Running. Update During Maintenance (recommandé) : Le système effectue les tâches préliminaires et change l'état de l'instance en Migrating to Another Zone. L'instance reste disponible pendant cette phase. Le basculement réel se produit pendant la fenêtre de maintenance configurée. Primary zone nodes per shard / Secondary zone nodes per shard Pour les instances cluster cloud-native ou avec séparation lecture/écriture, ajustez la répartition des nœuds réplica entre les zones principales et secondaires. Cela ne modifie pas le nombre total de nœuds. Pour les instances d'architecture cluster, ces valeurs représentent le nombre de nœuds réplica par shard dans chaque zone. Lisez le message d'avertissement, cochez la case et cliquez sur OK.
Vérifier la migration
Vérifiez la progression de la migration dans Task Center de la console. La migration est terminée lorsque l'état de l'instance revient à Running. La tâche de migration implique plusieurs étapes ; la durée totale dépend du volume de données et des spécifications de l'instance (généralement environ 0,5 à 1 heure pour les petites instances). Après l'étape de basculement, les étapes restantes n'affectent plus les lectures et écritures normales. Veuillez patienter jusqu'à la fin de la tâche.
Référence API
| API | Description |
|---|---|
| MigrateToOtherZone | Migrez une instance vers une autre zone au sein de la même région. |