PolarDB for MySQL permet de déplacer les nœuds de calcul d'un cluster vers une autre zone sans modifier ses endpoints. Utilisez cette fonctionnalité pour optimiser la latence des instances Elastic Compute Service (ECS) colocalisées, exécuter des exercices de reprise après sinistre ou rééquilibrer la répartition entre les zones.
Choisir une opération
Trois opérations sont disponibles. Sélectionnez celle correspondant à votre objectif :
| Objectif | Opération | Migration des données | Interruption de service |
|---|---|---|---|
| Déplacer le cluster vers une zone hébergeant vos instances ECS, ou exécuter un exercice de reprise après sinistre si la cible est déjà une zone secondaire | Modifier la zone principale | Non (nœuds de calcul uniquement, ~5 min par nœud) | 1 à 2 connexions transitoires, ~30 s chacune |
| Déplacer le cluster vers une zone hébergeant vos instances ECS, lorsque la cible n'est pas une zone secondaire | Modifier la zone principale | Oui (durée variable selon le volume de données) | 1 à 2 connexions transitoires, ~30 s chacune |
| Rééquilibrer l'emplacement des zones secondaires | Modifier la zone secondaire | Oui (durée variable selon le volume de données) | — |
| Basculer du stockage principal vers le cluster de stockage de secours à chaud | Basculer vers le cluster de stockage de secours à chaud | Non | 1 à 2 connexions transitoires, ~30 s chacune |
Prérequis
Avant de commencer, vérifiez que :
Les ressources de votre région sont déployées dans au moins deux zones. Le déploiement multizone n'est pas disponible dans les régions suivantes : Philippines (Manille), Corée du Sud (Séoul), Chine (Qingdao), Chine (Chengdu), Chine (Hohhot) et Thaïlande (Bangkok).
Pour le basculement vers le cluster de stockage de secours à chaud : la fonctionnalité correspondante est activée sur votre cluster. Consultez Mode haute disponibilité (cluster de stockage de secours à chaud).
Modifier la zone principale
La modification de la zone principale migre les nœuds de calcul du cluster vers la zone de destination. L'endpoint principal et les endpoints de cluster restent inchangés après l'opération, mais le vSwitch et l'adresse IP peuvent changer.
Planifiez cette opération en dehors des heures de pointe. Une ou deux connexions transitoires surviennent pendant le basculement, durant chacune environ 30 secondes. Assurez-vous que votre application peut se reconnecter automatiquement à la base de données.
Si la zone de destination n'est pas une zone secondaire actuelle, une migration des données est nécessaire. La durée de migration dépend du volume de données et peut prendre plusieurs heures pour les jeux de données volumineux. Procédez avec prudence.
Connectez-vous à la console PolarDB.
Dans le coin supérieur gauche, sélectionnez la région où le cluster est déployé.
Localisez le cluster et cliquez sur son ID.
-
En bas de la page Basic Information, cliquez sur Migrate Cluster Across Zones.
-
Dans la boîte de dialogue, configurez les paramètres suivants :
Paramètre Description Destination Zone Zone cible pour le cluster. Si cette zone est déjà secondaire, seuls les nœuds de calcul sont migrés (~5 min par nœud). Sinon, une migration des données est requise. Destination VPC VPC situé dans la zone de destination. Destination vSwitch vSwitch du VPC de destination. Si aucun vSwitch n'est disponible, créez-en un au préalable. Consultez Créer et gérer un vSwitch. Validity Period Définissez ce paramètre sur Immediately pour une exécution immédiate, ou sur Upgrade in Maintenance Window pour planifier l'opération pendant la fenêtre de maintenance. Pour consulter ou annuler une tâche planifiée, reportez-vous à Tâches planifiées. Cliquez sur OK.
Modifier la zone secondaire
La modification de la zone secondaire migre les données de la zone secondaire d'origine vers la zone de destination. La zone de destination ne peut être ni la zone principale ni la zone secondaire actuelle.
Une migration des données est systématiquement requise lors du changement de zone secondaire. La durée dépend du volume de données et peut atteindre plusieurs heures pour les jeux de données volumineux. Planifiez cette opération en dehors des heures de pointe.
Connectez-vous à la console PolarDB.
Dans le coin supérieur gauche, sélectionnez la région où le cluster est déployé.
Localisez le cluster et cliquez sur son ID.
Dans le volet de navigation de gauche, choisissez Settings and Management > Service Availability.
-
Sur la page Service Availability, cliquez sur Change Secondary Zone.
-
Dans la boîte de dialogue, sélectionnez la zone de destination et configurez le paramètre Effective Time :
Effective Immediately : exécute l'opération immédiatement.
Effective in Maintenance Window : planifie l'opération pendant la fenêtre de maintenance. Pour consulter ou annuler une tâche planifiée, reportez-vous à Tâches planifiées.
Cliquez sur OK.
Basculer vers le cluster de stockage de secours à chaud
Cette opération déclenche un basculement principal/secondaire vers le cluster de stockage de secours à chaud. Après le basculement, l'endpoint principal, l'endpoint de cluster, le vSwitch et l'adresse IP restent inchangés, mais des accès indirects peuvent survenir. Procédez avec prudence.
Évitez de basculer fréquemment entre le cluster principal et le cluster de stockage de secours à chaud. Des basculements répétés peuvent entraîner une latence de réplication élevée.
Cette opération est prise en charge uniquement pour les clusters Standard Edition et Cluster Edition. Vous pouvez basculer exclusivement vers le cluster de stockage de secours à chaud ; le basculement vers une zone non secondaire n'est pas pris en charge.
Connectez-vous à la console PolarDB.
Dans le coin supérieur gauche, sélectionnez la région où le cluster est déployé.
Localisez le cluster et cliquez sur son ID.
Dans le volet de navigation de gauche, choisissez Settings and Management > Service Availability.
Sur la page Service Availability, cliquez sur Switch Over to Hot Standby Storage Cluster.
Cliquez sur OK.
FAQ
La modification de la zone principale entraîne-t-elle une interruption de service prolongée ?
Non. La durée de migration (5 minutes par nœud de calcul, ou plusieurs heures pour la migration des données) ne correspond pas à une interruption de service. Seules une ou deux connexions transitoires surviennent lors du basculement proprement dit, durant chacune environ 30 secondes. Planifiez la modification en dehors des heures de pointe et assurez-vous que votre application se reconnecte automatiquement.
Que deviennent mes endpoints après la modification de la zone principale ?
L'endpoint principal et les endpoints de cluster restent inchangés ; les connexions existantes continuent donc de fonctionner. Le vSwitch et l'adresse IP peuvent changer, ce qui peut affecter brièvement la disponibilité. Planifiez la modification pendant une fenêtre de maintenance afin de minimiser l'impact.