ApsaraDB RDS:Migrate to another zone

Type de migration

Scénario

Migration d'une zone vers une autre zone

La zone actuelle est saturée ou rencontre des problèmes de performances.

Migration d'une zone vers plusieurs zones

Après la migration, les instances principale et secondaire résident dans des zones différentes, ce qui permet la reprise après sinistre inter-centres de données.

Par rapport aux instances mono-zone, les instances multi-zones tolèrent des pannes de niveau supérieur. Par exemple, les instances mono-zone résistent aux pannes au niveau du serveur et du rack, tandis que les instances multi-zones résistent aux pannes au niveau du centre de données.

Migration de plusieurs zones vers une zone

Pour répondre à des exigences spécifiques en matière de fonctionnalités.

Catégorie

Description

Avant la migration

• Perte de l'environnement hôte : La migration de zone implique une migration inter-hôtes. Cela efface votre compte hôte ainsi que tous les programmes ou fichiers déployés sur l'hôte d'origine (tels que SSIS, SSAS, SSRS). Sauvegardez ou migrez ces données au préalable.

  Important

  ApsaraDB RDS pour SQL Server est construit sur le moteur natif Microsoft SQL Server et se concentre sur la fourniture de services de base de données managés stables et efficaces. Si votre activité nécessite des fonctionnalités telles que SSIS, SSAS ou SSRS, vous devez disposer d'une solide expertise opérationnelle pour garantir la continuité de l'activité.

• Évitez les modifications de métadonnées : N'ajoutez ni ne supprimez de bases de données et ne modifiez pas le modèle de récupération pendant la migration de zone. Ces actions peuvent entraîner une incohérence des données.

• La migration ne peut pas être annulée : Une fois lancée, la migration ne peut pas être annulée. Procédez avec prudence.

• Choisissez les heures creuses : La migration dure généralement environ 20 minutes, selon le volume de vos données. Une activité intense pendant la migration peut prolonger cette durée. Effectuez la migration pendant les heures creuses de votre activité.

• Assurez la reconnexion automatique : L'instance sera indisponible pendant quelques minutes lors du basculement, ce qui affectera brièvement la disponibilité. Assurez-vous que votre application dispose d'un mécanisme de reconnexion.

• Vérifiez l'adresse de connexion : L'adresse IP virtuelle (VIP) change après la migration. Assurez-vous que votre application utilise l'endpoint plutôt qu'une adresse IP directe pour accéder à l'instance.

  Pour les clients basés sur JVM, définissez le TTL sur 60 secondes ou moins. Cela garantit que votre application reçoit la nouvelle VIP en interrogeant à nouveau le DNS lorsque la VIP de l'endpoint change.

  Définir le TTL dans JVM

  • Pour toutes les applications JVM : Définissez le paramètre networkaddress.cache.ttl sur 60 dans le fichier $JAVA_HOME/jre/lib/security/java.security.

  • Pour une application locale spécifique : Avant d'établir toute connexion réseau, et plus précisément avant le premier appel à InetAddress.getByName(), ajoutez cette ligne au code d'initialisation de votre application : java.security.Security.setProperty("networkaddress.cache.ttl" , "60");.

• Planifiez la gestion des tâches DTS : Si vous avez des tâches DTS actives, anticipez leur gestion. Vous devrez redémarrer manuellement ces tâches après la migration.

• L'activité reste accessible : Les données sont déplacées pendant la migration, mais votre instance RDS SQL Server reste accessible. Les opérations métier ne sont pas affectées.

• Limitation des sauvegardes régulières : Si vous choisissez d'effectuer le basculement pendant la fenêtre de maintenance, les sauvegardes régulières sont désactivées depuis la soumission de la tâche jusqu'à la fin de la migration.

Après la migration

• Vérifiez la cohérence de la configuration : Le nom de l'instance, le port, les tags, les comptes de base de données et autres paramètres restent inchangés. Confirmez que ces configurations fonctionnent correctement.

• Videz le cache DNS : Videz rapidement le cache DNS de votre client pour éviter les échecs de connexion causés par des entrées obsolètes.

• Validez la connectivité : Utilisez l'endpoint pour vérifier que l'instance est accessible et confirmez que les fonctions métier fonctionnent normalement.

• Redémarrez les tâches DTS : Si vous aviez des tâches DTS actives avant la migration, redémarrez-les manuellement pour assurer leur bon fonctionnement.