ApsaraDB RDS for MySQL prend en charge la migration des nœuds de proxy entre zones au sein d'une même région. Migrez les nœuds de proxy vers la zone de l'instance RDS principale pour réduire la latence d'écriture interzone et éviter la dégradation des performances d'écriture causée par le trafic entre le proxy et l'instance principale.
Prérequis
Avant de commencer, vérifiez que :
-
L'instance RDS remplit toutes les conditions suivantes :
Moteur : MySQL
Édition : RDS High-availability Edition ou RDS Cluster Edition
Stockage : disques cloud
Database proxy : activé
État de l'instance : Running — y compris l'instance principale, toutes les instances en lecture seule et le nœud de proxy
L'instance utilise des endpoints VPC (Virtual Private Cloud). La migration entre zones n'est pas prise en charge pour les proxies de base de données sur réseau classique. Pour plus de détails, consultez View and manage instance endpoints and ports.
Si le nœud de proxy et l'instance RDS principale se trouvent dans des zones différentes et que vous vous connectez via un endpoint de proxy, les performances d'écriture diminuent. Configurez le même VPC et le même vSwitch pour les deux ressources afin d'éviter ce problème.
Facturation
La migration entre zones est gratuite.
Impacts potentiels
Examinez les impacts suivants avant de migrer.
Interruption temporaire de la connexion
La migration entre zones provoque une interruption temporaire de la connexion d'environ 30 secondes. Pour minimiser les perturbations :
-
Connectez votre application à l'aide d'un endpoint non affecté par la migration :
RDS High-availability Edition : l'endpoint de l'instance RDS principale ou un endpoint d'instance RDS en lecture seule
RDS Cluster Edition : l'endpoint de lecture/écriture, l'endpoint en lecture seule ou l'endpoint de connexion directe au nœud
Planifiez la migration pendant les heures creuses.
Vérifiez que votre application dispose d'un mécanisme de reconnexion automatique. Si ce n'est pas le cas, reconnectez-vous manuellement une fois la migration terminée.
Modifications des adresses IP virtuelles
La migration entre zones modifie les adresses IP virtuelles (VIP) associées aux endpoints de votre instance. Connectez votre application à l'aide d'endpoints plutôt que d'adresses IP afin qu'elle résolve automatiquement la nouvelle VIP après la migration.
Après la migration, effacez immédiatement les enregistrements DNS mis en cache sur le client de base de données. Lorsque les VIP changent, la propagation DNS prend du temps ; si le client continue de résoudre l'ancienne VIP, les connexions échouent jusqu'à l'expiration du cache. Pour les clients s'exécutant sur une machine virtuelle Java (JVM), définissez la durée de vie (TTL) dans la configuration de la JVM à 60 secondes ou moins afin que le client interroge à nouveau le DNS rapidement après un changement de VIP. Pour plus de détails, consultez Class InetAddress.
Accès le plus proche
La migration entre zones peut invalider la configuration d'accès le plus proche. Après la migration, la nouvelle zone est accessible par défaut ; la zone d'origine n'est plus accessible. Si la zone de l'endpoint de proxy diffère de la nouvelle zone par défaut, l'accès le plus proche à cette zone échoue.
Le tableau suivant présente des exemples de scénarios.
| Scénario | Zone du nœud de proxy d'origine | Endpoint de proxy | Accès le plus proche d'origine | Nouvelle zone du nœud de proxy | Nouvelle zone par défaut | Nouvelle zone de l'endpoint de proxy | Nouvel accès le plus proche |
|---|---|---|---|---|---|---|---|
Scénario 1 : Zone A+Zone B → Zone A+Zone C |
Zone A | Endpoint de proxy a | Zone A | Zone A | Zone A | Zone A | Zone A |
| Zone C | Invalide | ||||||
| Zone B | Endpoint de proxy b | Zone B | Zone C | Zone C | Zone C | Zone C | |
| Zone D | Invalide | ||||||
Scénario 2 : Zone A+Zone B → Zone C+Zone D |
Zone A | Endpoint de proxy a | Zone A | Zone C | Zone C | Zone C | Zone C |
| Zone E | Invalide | ||||||
| Zone B | Endpoint de proxy b | Zone B | Zone D | Zone D | Zone D | Zone D | |
| Zone E | Invalide |
Ressources insuffisantes
Si la zone de destination ne dispose pas de ressources suffisantes, la migration peut échouer.
Migrer les nœuds de proxy
Connectez-vous à la console ApsaraDB RDS. Sur la page Instances, sélectionnez la région où se trouve votre instance, repérez l'instance et cliquez sur son ID.
Dans le volet de navigation de gauche, cliquez sur Database Proxy pour afficher les informations de base de votre proxy de base de données.
-
Cliquez sur Cross-zone Migration.
RemarqueSi l'option Cross-zone Migration n'est pas affichée, vérifiez que votre instance remplit tous les prérequis.
-
Dans la boîte de dialogue Cross-zone Migration of Database Proxy, examinez les informations de zone et de réseau pour l'instance RDS principale et le proxy de base de données. Définissez Destination Zone, Destination vSwitch et Change Time, puis cliquez sur OK.
ImportantVous ne pouvez pas modifier le type ou les spécifications du proxy de base de données pendant la migration.
Passez en revue les impacts répertoriés et cliquez sur OK pour confirmer.
Référence API
| Opération | Description |
|---|---|
| ModifyDBProxyInstance | Migre les nœuds de proxy vers une zone de destination en spécifiant les vSwitchIds |
FAQ
La migration entre zones affecte-t-elle mon application si je n'utilise pas d'endpoint de proxy ?
Non. La migration n'affecte que les applications connectées via un endpoint de proxy. Si vous vous connectez via l'endpoint de l'instance RDS principale ou un endpoint d'instance RDS en lecture seule (RDS High-availability Edition), ou via l'endpoint de lecture/écriture, l'endpoint en lecture seule ou l'endpoint de connexion directe au nœud (RDS Cluster Edition), vos charges de travail ne sont pas affectées.
Quelle est la durée de l'interruption de connexion ?
L'interruption temporaire de la connexion dure environ 30 secondes, bien que la durée réelle puisse varier selon votre activité. Planifiez la migration pendant les heures creuses et utilisez un type d'endpoint non affecté pour minimiser l'impact.