Note
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier les répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de changer de répertoire.
Cet article explique comment activer ou désactiver la haute disponibilité sur votre instance de serveur flexible Azure Database pour PostgreSQL à l’aide du portail Azure ou d’Azure CLI. Les informations s’appliquent si vous utilisez des instances dans la même zone ou à l’aide d’un modèle de déploiement redondant interzone.
La fonctionnalité de haute disponibilité déploie des réplicas principaux et de secours physiquement distincts. Vous pouvez provisionner les réplicas dans la même zone de disponibilité ou dans différentes zones, en fonction du modèle de déploiement que vous choisissez. Pour plus d’informations, consultez l’article sur les concepts de haute disponibilité. Vous pouvez activer la haute disponibilité pendant ou après la création de votre instance de serveur flexible Azure Database pour PostgreSQL.
Important
En avril 2024, nous avons mis à jour le modèle de facturation pour le niveau de calcul v5 avec des serveurs avec haute disponibilité. Cette modification reflète correctement les frais en tenant compte des serveurs principaux et de secours. Avant cette modification, vous avez été facturé de manière incorrecte pour le serveur principal uniquement. Si vous utilisez le niveau v5 avec des serveurs à haute disponibilité, vous voyez maintenant les quantités de facturation multipliées par 2. Cette mise à jour n’affecte pas les niveaux v4 et v3.
Activer la haute disponibilité pour les serveurs existants
Dans le portail Azure, sélectionnez votre instance de serveur flexible Azure Database pour PostgreSQL.
Dans le menu de gauche, dans la section Paramètres, sélectionnez Haute disponibilité.
L’option De résilience zonale contrôle si votre serveur est protégé entre les zones de disponibilité. Deux options s'offrent à vous :
- Activé : lorsque vous sélectionnez cette option, Azure tente de créer le serveur de secours dans une zone de disponibilité différente de celle du serveur principal. Cette option vous offre la meilleure protection contre les défaillances au niveau de la zone.
- Désactivé : la haute disponibilité n’est pas configurée.
Si la résilience zonale est activée, mais que votre région ne dispose pas de capacité pour une configuration redondante interzone, une case supplémentaire s’affiche sous l’option Activé. La sélection de ce paramètre permet de créer le serveur de secours dans la même zone que le serveur principal. Lorsque la capacité zonale devient disponible, Azure vous avertit. À ce stade, vous pouvez utiliser soit PITR, soit des réplicas en lecture pour migrer des charges de travail vers une configuration de haute disponibilité redondante interzone, afin d’assurer une résilience maximale. Accédez à la section Limitations et considérations pour en savoir plus.
Si la résilience zonale n’est pas activée, sélectionnez l’option Activé .
Lorsque vous sélectionnez l’option Activé, l’option redondance de zone est appliquée par défaut pour les régions qui prennent en charge les zones de disponibilité. Cette configuration protège contre les défaillances zonales.
Si la région n’a pas de capacité zonale, pour vous assurer que la haute disponibilité (HA) est activée dans votre région préférée, cochez la case sous l’option activée pour autoriser la création de haute disponibilité avec Same-Zone mode de la région. Cela migre automatiquement vos charges de travail vers une haute disponibilité redondante interzone dès que la capacité zonale devient disponible :
Lorsque vous avez terminé de configurer les paramètres, sélectionnez Enregistrer pour appliquer les modifications.
Une boîte de dialogue affiche l’augmentation du coût associée au déploiement du serveur de secours. Si vous décidez de continuer, sélectionnez Activer la haute disponibilité.
Un déploiement démarre. Une fois l’opération terminée, une notification indique que vous avez activé la haute disponibilité.
Désactiver la haute disponibilité
Dans le portail Azure, sélectionnez votre instance de serveur flexible Azure Database pour PostgreSQL.
Dans le menu de gauche, dans la section Paramètres, sélectionnez Haute disponibilité.
Si la haute disponibilité est activée, la case d’option Activée pour la résilience zonale est déjà sélectionnée. En outre, le mode haute disponibilité est défini sur le mode configuré et la valeur d’état de haute disponibilité est généralement saine.
Sélectionnez le bouton radio Désactivé pour désactiver la haute disponibilité.
Sélectionnez Enregistrer pour appliquer la modification.
Une boîte de dialogue affiche la réduction des coûts associée à la suppression du serveur de secours. Si vous décidez de continuer, sélectionnez Désactiver la haute disponibilité.
Un déploiement démarre. Une fois l’opération terminée, une notification indique que vous avez désactivé la haute disponibilité.
Activer la haute disponibilité lors de l’approvisionnement du serveur
Dans le portail Azure, lors de l’approvisionnement d’une nouvelle instance de serveur flexible Azure Database pour PostgreSQL, accédez à la section Critique pour l’entreprise (haute disponibilité). Sélectionnez le bouton radio Activé dans la section Résilience zonale.
- Par défaut, le serveur tente de créer le serveur de secours dans une zone de disponibilité différente avec le mode haute disponibilité Zone-Redundant pour une résilience zonale maximale.
Si la capacité zonale n’est pas disponible, vous pouvez sélectionner la case Autoriser la secours dans la même zone si la résilience zonale échoue en tant que secours. Sans sélectionner cette option, vous ne pouvez pas passer à l’étape suivante du flux de travail de création. Cela garantit que la haute disponibilité reste activée. Lorsque la capacité zonale devient disponible, Azure vous en informera et vous pourrez alors utiliser PITR ou des réplicas en lecture pour migrer les charges de travail vers une configuration de haute disponibilité redondante interzone, afin d’assurer une résilience maximale.
Une fois que vous avez activé la case à cocher, vous pouvez passer à la section Authentification sur le flux de travail de création.
Sélectionnez une zone spécifique pour le serveur principal en définissant Zone de disponibilité sur n’importe quelle valeur autre que Aucune préférence.
Lancer un basculement forcé
Suivez ces étapes pour forcer le basculement de votre serveur principal vers le serveur de secours dans Azure Database pour PostgreSQL.
Lorsque vous lancez un basculement forcé, le serveur principal tombe immédiatement en panne et déclenche un basculement vers le serveur de secours. Le lancement d’un basculement forcé est utile lorsque vous souhaitez tester la façon dont un basculement provoqué par une panne non planifiée affecterait votre charge de travail.
Important
N’effectuez pas de basculements consécutifs sans pause. Attendez au moins 15 à 20 minutes entre les basculements. Ce temps d’attente permet au nouveau serveur de secours d’être entièrement établi.
L’heure globale de l’opération de bout en bout, comme indiqué sur le portail, peut être plus longue que le temps d’arrêt réel que l’application rencontre. Vous devez mesurer le temps d’arrêt du point de vue de l’application.
Dans le portail Azure, sélectionnez votre instance de serveur flexible Azure Database pour PostgreSQL sur laquelle la haute disponibilité est activée.
Dans le menu de gauche, dans la section Paramètres, sélectionnez Haute disponibilité.
Si le mode haute disponibilité est défini sur Redondant interzone, notez les valeurs affectées à la zone de disponibilité principale et à la zone de disponibilité de secours. Elles doivent être inversées une fois l’opération de basculement terminée.
Sélectionnez Basculement forcé pour démarrer la procédure de basculement manuelle. Une boîte de dialogue vous informe du temps d’arrêt attendu jusqu’à ce que le basculement se termine. Si vous décidez de continuer, sélectionnez Démarrer le basculement forcé.
Une notification s’affiche et mentionne qu’un basculement est en cours.
Une fois le basculement effectué vers le serveur de secours, une notification vous informe de la fin.
Si le mode haute disponibilité est configuré comme redondant interzone, vérifiez que les valeurs de la Zone de disponibilité principale et de la Zone de disponibilité de secours sont désormais inversées.
Initier un basculement planifié
Suivez ces étapes pour effectuer un basculement planifié de votre serveur principal vers le serveur de secours dans Azure Database pour PostgreSQL. Le lancement de cette opération prépare le serveur de secours, puis effectue le basculement.
Cette opération de basculement fournit le moins de temps d’arrêt, car elle effectue un basculement approprié vers le serveur de secours. Il est utile pour les situations telles que le retour du serveur principal vers votre zone de disponibilité préférée après un basculement inattendu.
Important
N’effectuez pas de basculements consécutifs sans pause. Attendez au moins 15 à 20 minutes entre les basculements. Ce temps d’attente permet au nouveau serveur de secours d’être entièrement établi.
Effectuez des basculements planifiés pendant les périodes de faible activité.
L’heure globale de l’opération de bout en bout, comme indiqué sur le portail, peut être plus longue que le temps d’arrêt réel que l’application rencontre. Vous devez mesurer le temps d’arrêt du point de vue de l’application.
Dans le portail Azure, sélectionnez votre instance de serveur flexible Azure Database pour PostgreSQL sur laquelle la haute disponibilité est activée.
Dans le menu de gauche, dans la section Paramètres, sélectionnez Haute disponibilité.
Si le mode haute disponibilité est défini sur Redondant interzone, notez les valeurs affectées à la zone de disponibilité principale et à la zone de disponibilité de secours. Elles doivent être inversées une fois l’opération de basculement terminée.
Sélectionnez Basculement planifié pour démarrer la procédure de basculement manuelle. Une boîte de dialogue vous informe du temps d’arrêt attendu jusqu’à ce que le basculement se termine. Si vous décidez de continuer, sélectionnez Démarrer le basculement planifié.
Une notification s’affiche et mentionne que le basculement est en cours.
Une fois le basculement effectué vers le serveur de secours, une notification vous informe de la fin.
Si le mode haute disponibilité est configuré comme redondant interzone, vérifiez que les valeurs de la Zone de disponibilité principale et de la Zone de disponibilité de secours sont désormais inversées.
Limitations et considérations
L’activation ou la désactivation de la haute disponibilité sur une instance de serveur flexible Azure Database pour PostgreSQL ne modifie pas d’autres paramètres, notamment la configuration réseau, les paramètres de pare-feu, les paramètres du serveur ou la rétention des sauvegardes. L’activation ou la désactivation de la haute disponibilité est une opération en ligne. Elle n’affecte pas la connectivité et les opérations de votre application.
Azure Database pour PostgreSQL prend en charge la haute disponibilité avec les deux réplicas déployés dans la même zone. Cette configuration est disponible dans toutes les régions prises en charge. Toutefois, la haute disponibilité avec redondance de zone n’est disponible que dans certaines régions.
Le niveau Burstable ne prend pas en charge la haute disponibilité. Seuls les niveaux usage général et mémoire optimisée prennent en charge la haute disponibilité.
Si vous déployez un serveur dans une région qui se compose d’une seule zone de disponibilité, vous pouvez activer la haute disponibilité uniquement en mode de même zone. Si la région est améliorée à l’avenir avec plusieurs zones de disponibilité, vous pouvez déployer de nouvelles instances de serveurs flexibles Azure Database pour PostgreSQL avec une haute disponibilité configurée soit comme même zone, soit comme interdépendance de zone.
Toutefois, pour toutes les instances que vous avez déployées dans la région lorsque la région se compose d’une seule zone de disponibilité, vous ne pouvez pas activer directement la haute disponibilité en mode redondant interzone. Pour contourner ce problème, vous pouvez utiliser l’option de restauration ou l’option de réplica en lecture :
Option de restauration
- Restaurez une instance existante sur un nouveau serveur à l’aide du dernier point de restauration.
- Après avoir créé le nouveau serveur, activez la haute disponibilité avec redondance de zone.
- Après la vérification des données, vous pouvez éventuellement supprimer l’ancien serveur.
- Assurez-vous que les chaînes de connexion de vos clients sont modifiées pour pointer vers votre serveur nouvellement restauré.
Option de réplica en lecture
- Créez une réplique en lecture dans la même région que votre serveur principal.
- Effectuez la promotion du réplica en lecture pour qu’il devienne le nouveau serveur primaire.
- Pour conserver le nom d’origine, utilisez des points de terminaison virtuels ou supprimez l’ancien serveur primaire, puis créez et procédez à la promotion d’un nouveau réplica en lecture.
- Pour les utilisateurs du portail, activez la résilience zonale. Pour les outils de développement, définissez la haute disponibilité avec l’option Zone-Redundant.