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 décrit la haute disponibilité dans Azure Database pour PostgreSQL, qui inclut les zones de disponibilité et la récupération interrégion et la continuité des activités. Pour obtenir une vue d’ensemble plus détaillée de la fiabilité dans Azure, consultez Fiabilité Azure.
Azure Database pour PostgreSQL prend en charge la haute disponibilité en approvisionnant un réplica principal et un réplica de secours physiquement distincts dans la même zone de disponibilité (zonal) ou entre les zones de disponibilité (redondant interzone). Ce modèle de haute disponibilité est conçu pour s’assurer que les données validées ne sont jamais perdues pendant les défaillances. Dans une configuration HA (haute disponibilité), les données sont validées de manière synchrone sur le serveur primaire et le serveur de secours. Le modèle est conçu pour que la base de données ne devienne pas un point de défaillance unique dans votre architecture logicielle. Si vous souhaitez en savoir plus sur la haute disponibilité et la prise en charge des zones de disponibilité, consultez Prise en charge des zones de disponibilité.
Prise en charge des zones de disponibilité
Les zones de disponibilité sont des groupes physiquement distincts de centres de données au sein de chaque région Azure. Lorsqu'une zone tombe en panne, les services peuvent basculer vers l'une des zones restantes.
Azure Database pour PostgreSQL prend en charge les modèles redondants interzone et zonaux pour les configurations de haute disponibilité. Les deux configurations de haute disponibilité permettent une fonctionnalité de basculement automatique sans perte de données pendant les événements planifiés et non planifiés.
Redondant interzone. La haute disponibilité redondante interzone déploie un réplica de secours dans une zone différente avec une fonctionnalité de basculement automatique. La redondance de zone fournit le niveau de disponibilité le plus élevé, mais vous devez configurer la redondance des applications entre les zones. Pour cette raison. choisissez la redondance de zone quand vous voulez une protection en cas de défaillances au niveau des zones de disponibilité et quand la latence entre les zones de disponibilité est acceptable. Bien qu'il puisse y avoir un certain impact sur la latence des écritures et des validations en raison de la réplication synchrone, cela n'affecte pas les requêtes de lecture. Cet impact est spécifique à vos charges de travail, au type de référence SKU que vous sélectionnez et à la région.
Vous pouvez choisir la région et les zones de disponibilité pour le serveur principal et le serveur de secours. Le serveur réplica de secours est approvisionné dans la zone de disponibilité choisie dans la même région, avec une configuration de calcul, de stockage et de réseau similaire à celle du serveur principal. Les fichiers de données et les fichiers journaux des transactions (journaux d’activité en écriture anticipée, également appelés WAL) sont stockés sur un stockage localement redondant (LRS) dans chaque zone de disponibilité, stockant automatiquement trois copies de données. Une configuration redondante interzone permet d’isoler physiquement l’ensemble de la pile entre le serveur principal et le serveur de secours.
L’option redondante interzone est disponible uniquement dans les régions qui prennent en charge les zones de disponibilité.
La redondance interzone n’est pas prise en charge pour :
Niveau de calcul burstable
Régions avec disponibilité à zone unique
Zonal. Choisissez un déploiement zonal quand vous voulez obtenir le niveau de disponibilité le plus élevé au sein d’une même zone de disponibilité avec la latence réseau la plus faible. Vous pouvez choisir la région et la zone de disponibilité pour déployer votre serveur de base de données primaire. Un serveur réplica de secours est automatiquement provisionné et géré dans la même zone de disponibilité, avec une configuration de calcul, de stockage et de réseau similaire à celle du serveur principal. Une configuration zonale protège vos bases de données contre les défaillances au niveau du nœud, et permet de réduire les temps d’arrêt d’applications pendant les temps d’arrêt planifiés et non planifiés. Les données du serveur primaire sont répliquées vers le serveur réplica de secours en mode synchrone. en cas d’interruption du serveur principal, le serveur bascule automatiquement vers le réplica de secours.
L’option de déploiement zonal est disponible dans toutes les régions Azure où vous pouvez déployer le serveur flexible.
Note
Les modèles de déploiement redondant interzone et zonal se comportent de la même façon d’un point de vue architectural. Les différentes discussions des sections suivantes s’appliquent aux deux, sauf indication contraire.
Configurer la résilience zonale dans le portail
Vous pouvez configurer la haute disponibilité de deux façons : la haute disponibilité redondante interzone, qui place le serveur de secours dans une zone de disponibilité différente pour une résilience maximale, ou la haute disponibilité de même zone, qui déploie le serveur de secours dans la même zone que le serveur principal pour réduire la latence.
Pour simplifier la configuration et garantir la résilience zonale, le portail fournit une option de résilience zonale avec deux cases d’option : activé et désactivé. Sélectionner 'Activé' tente de créer le serveur de secours dans une autre zone de disponibilité (mode haute disponibilité redondant interzone). Si la région ne prend pas en charge la haute disponibilité redondante interzone, vous pouvez cocher la case de remplacement (mise en évidence dans l'image suivante) pour activer la haute disponibilité de même zone à la place.
Lorsque vous cochez la case de secours, le système crée le serveur de secours dans la même zone. Si la capacité zonale devient disponible ultérieurement, Azure vous avertit afin que vous puissiez choisir de migrer vers une configuration haute disponibilité redondante interzone à l’aide de PITR ou de réplicas en lecture. Si vous ne cochez pas la case et que la capacité zonale n’est pas disponible, l’activation de HA échoue. Cette conception applique la haute disponibilité redondante interzone comme valeur par défaut tout en fournissant un fallback contrôlé pour la haute disponibilité de même zone, ce qui garantit que les charges de travail obtiennent finalement une résilience complète de zone sans intervention manuelle.
Fonctionnalités de haute disponibilité
Un réplica de secours est déployé dans la même configuration de machine virtuelle, y compris les vCores, le stockage et les paramètres réseau, comme le serveur principal.
Vous pouvez ajouter la prise en charge des zones de disponibilité pour un serveur de base de données existant.
Vous pouvez supprimer le réplica de secours en désactivant la haute disponibilité.
Vous pouvez choisir les zones de disponibilité pour vos serveurs de base de données primaire et de secours pour la disponibilité redondante interzone.
Les opérations comme l’arrêt, le démarrage et le redémarrage sont effectuées simultanément sur le serveur de base de données principal et sur le serveur de base de données de secours.
Dans les modèles redondants interzone et zonaux, le serveur de base de données principal effectue régulièrement des sauvegardes automatiques. En même temps, la réplique de secours archive en permanence les journaux des transactions dans le stockage de sauvegarde. Si la région prend en charge les zones de disponibilité, les données de sauvegarde sont stockées sur un stockage redondant interzone (ZRS). Dans les régions qui ne prennent pas en charge les zones de disponibilité, les données de sauvegarde sont stockées sur un stockage localement redondant (LRS).
Les clients se connectent toujours au nom d’hôte du serveur de base de données primaire.
Toute modification apportée aux paramètres du serveur sont également appliquées au réplica de secours.
Vous pouvez redémarrer le serveur pour récupérer les modifications de paramètre de serveur statique.
Les activités de maintenance périodiques, telles que les mises à niveau de versions mineures, se produisent d’abord au niveau du serveur de secours. Pour réduire les temps d’arrêt, le serveur en attente est promu en serveur principal afin de permettre la continuité des charges de travail pendant l'application des tâches de maintenance sur le nœud restant.
Note
Pour garantir que les fonctions de haute disponibilité fonctionnent correctement, configurez les valeurs des paramètres max_replication_slots et max_wal_senders du serveur. La haute disponibilité en nécessite quatre de chaque pour gérer des basculements et des mises à niveau fluides. Pour une configuration à haute disponibilité avec cinq réplicas en lecture et 12 emplacements de réplication logique, définissez les valeurs des paramètres max_replication_slots et max_wal_senders sur 21. Cette configuration est nécessaire, car chaque réplica de lecture et chaque emplacement de réplication logique en nécessite un de chaque, plus les quatre nécessaires pour que la haute disponibilité fonctionne correctement. Pour plus d’informations sur les paramètres max_replication_slots et max_wal_senders, reportez-vous à la documentation.
Surveiller l’intégrité de la haute disponibilité
La surveillance de l’état d’intégrité haute disponibilité dans Azure Database pour PostgreSQL fournit une vue d’ensemble continue de l’intégrité et de la préparation des instances compatibles haute disponibilité. Cette fonctionnalité de surveillance applique l’infrastructure Resource Health Check (RHC) d’Azure pour détecter et alerter sur les problèmes susceptibles d’affecter votre base de données, qu'il s'agisse de sa préparation au basculement ou de sa disponibilité totale. En évaluant les métriques clés telles que l’état de la connexion, l’état du basculement et l’intégrité de la réplication des données, le monitoring de l’état d’intégrité de la haute disponibilité (HA) permet de résoudre les problèmes de manière proactive, tout en garantissant une durée de bon fonctionnement et des performances optimales pour votre base de données.
Utilisez la surveillance de l’état de santé H.A. pour :
- Obtenir des insights en temps réel sur l’intégrité des réplicas principaux et de secours, avec des indicateurs d’état qui révèlent les problèmes potentiels, par exemple une dégradation des performances ou un blocage du réseau.
- Configurez des alertes pour les notifications en temps opportun sur les modifications apportées à l’état de la haute disponibilité, afin de pouvoir prendre des mesures immédiates pour résoudre les perturbations potentielles.
- Optimiser la préparation au basculement en identifiant et en résolvant les problèmes avant qu’ils n’impactent les opérations de base de données.
Pour obtenir un guide détaillé sur la configuration et l’interprétation des statuts d’intégrité pour la haute disponibilité (HA), consultez la surveillance de l’état d’intégrité HA pour Azure Database for PostgreSQL.
Limitations liées à la haute disponibilité
En raison de la réplication synchrone vers le serveur de secours, en particulier avec une configuration redondante interzone, les applications peuvent rencontrer une latence d’écriture et de validation élevée.
Vous ne pouvez pas utiliser le réplica de secours pour les requêtes en lecture.
Selon la charge de travail et l’activité sur le serveur principal, le processus de basculement peut prendre plus de 120 secondes, car le serveur de secours doit être rétabli avant qu'il puisse être promu.
Le serveur de secours récupère généralement les fichiers WAL à 40 Mo/s. Pour les versions plus volumineuses, ce taux peut augmenter jusqu’à 200 Mo/s. Si votre charge de travail dépasse cette limite, il se peut que la récupération soit plus longue pendant le basculement ou après avoir établi un nouveau serveur de secours.
Le redémarrage du serveur de base de données primaire redémarre également le réplica de secours.
Vous ne pouvez pas configurer de réplica de secours supplémentaire.
Vous ne pouvez pas planifier les tâches de gestion initiées par le client pendant la fenêtre de maintenance managée.
Les événements planifiés tels que l'informatique et le stockage à grande échelle se produisent d’abord sur le serveur de secours, puis sur le serveur principal. Actuellement, le serveur n’est pas basculé pour ces opérations planifiées.
Si vous configurez le décodage logique ou la réplication logique sur un serveur flexible compatible haute disponibilité :
- Dans PostgreSQL 16 et versions antérieures, les emplacements de réplication logique ne sont pas conservés sur le serveur de secours après un basculement par défaut.
- Pour garantir que la réplication logique continue de fonctionner après le basculement, vous devez activer l’extension
pg_failover_slotset configurer les paramètres de prise en charge tels quehot_standby_feedback = on. - À compter de PostgreSQL 17, la synchronisation d’emplacements est prise en charge en mode natif. Si vous activez les configurations PostgreSQL correctes (
sync_replication_slots, ),hot_standby_feedbackles emplacements de réplication logique sont conservés automatiquement après le basculement et aucune extension n’est requise. - Pour connaître les étapes d’installation et les prérequis, reportez-vous à la documentation de l’extension PG_Failover_Slots .
La configuration des zones de disponibilité entre un réseau virtuel et un accès public avec des points de terminaison privés n’est pas prise en charge. Vous devez configurer des zones de disponibilité au sein d’un réseau virtuel (réparties entre les zones de disponibilité au sein d’une région) ou l’accès public avec des points de terminaison privés.
Vous ne pouvez configurer des zones de disponibilité qu’au sein d’une seule région. Vous ne pouvez pas configurer les zones de disponibilité entre les régions.
Accord de Niveau de Service (SLA)
Le modèle zonal offre un temps de disponibilité selon un SLA d'environ 99.95%.
Le modèle de redondance de zone assure une disponibilité de SLA de 99,99% environ.
Créer une base de données Azure pour PostgreSQL avec une zone de disponibilité activée
Pour savoir comment créer une base de données Azure pour PostgreSQL pour la haute disponibilité avec des zones de disponibilité, consultez Démarrage rapide : Créer une base de données Azure pour PostgreSQL dans le portail Azure.
Redéploiement et migration des zones de disponibilité
Pour savoir comment activer ou désactiver la configuration de haute disponibilité dans votre serveur flexible dans les modèles de déploiement redondant interzone et zonal, consultez Gérer la haute disponibilité dans le serveur flexible.
Composants haute disponibilité et flux de travail
Fin de la transaction
Une transaction d’application déclenche une écriture et une validation qui se connecte d’abord au WAL sur le serveur principal. Le serveur principal transmet ces fichiers journaux vers le serveur de secours avec le protocole de streaming Postgres. Lorsque le stockage du serveur de secours conserve les journaux d’activité, le serveur primaire reconnaît l’achèvement de l’écriture. L’application valide sa transaction uniquement après cet accusé de réception. Ce aller-retour supplémentaire ajoute une latence à votre application. Le pourcentage d’impact dépend de l’application. Ce processus d’accusé de réception n’attend pas que les journaux soient appliqués au serveur de secours. Le serveur de secours reste en mode de récupération jusqu’à ce qu’il soit promu.
Bilan de santé
La surveillance de l'état de santé du serveur flexible vérifie régulièrement l’intégrité du serveur principal et du serveur de secours. Après plusieurs pings, si la surveillance de l’état du système détecte qu’un serveur maître n’est pas accessible, le service lance un basculement automatique vers le serveur secondaire. L’algorithme de surveillance de la santé utilise plusieurs points de données pour éviter les faux positifs.
Modes de basculement
Le serveur flexible prend en charge deux modes de basculement : Basculement planifié et Basculement non planifié. Dans les deux modes, une fois la réplication rompue, le serveur de secours exécute la récupération avant la promotion en tant que serveur principal et s’ouvre pour lecture/écriture. Avec les entrées DNS automatiques mises à jour avec le nouveau point de terminaison de serveur principal, les applications peuvent se connecter au serveur à l’aide du même point de terminaison. Un nouveau serveur de secours est établi en arrière-plan, pour que votre application maintienne la connectivité.
État de haute disponibilité
Le système surveille en permanence l’intégrité des serveurs principaux et de secours. Il prend les mesures appropriées pour résoudre les problèmes, notamment le déclenchement d’un basculement vers le serveur de secours. Le tableau suivant répertorie les états de haute disponibilité possibles :
| État | Description |
|---|---|
| Initialisation | Le processus de création d’un serveur de secours est en cours. |
| Réplication des données | Une fois le serveur de secours créé, il rattrape le serveur primaire. |
| Healthy | La réplication est dans un état stable et intègre. |
| Basculement | Le serveur de base de données est en cours de basculement vers le serveur de secours. |
| Suppression du serveur de secours | Lors du processus de suppression du serveur de secours. |
| Non activé | La haute disponibilité n’est pas activée. |
Note
Vous pouvez activer la haute disponibilité pendant la création du serveur ou ultérieurement. Si vous activez ou désactivez la haute disponibilité pendant la phase de post-création, faites-le lorsque l’activité du serveur principal est faible.
Opérations à l’état stable
Les applications clientes PostgreSQL se connectent au serveur principal à l’aide du nom du serveur de base de données. Le serveur principal sert directement les lectures d’application. En même temps, l’application reçoit la confirmation des validations et écrit uniquement une fois que les données du journal sont persistantes sur le serveur primaire et le réplica de secours. En raison de cet aller-retour supplémentaire, les applications peuvent s’attendre à une latence élevée pour les écritures et les commits. Vous pouvez superviser l’intégrité de la haute disponibilité sur le portail.
- Les clients se connectent au serveur flexible et effectuent des opérations d’écriture.
- Les modifications sont répliquées sur le site de secours.
- Le serveur primaire reçoit un accusé de réception.
- Les écritures et les validations font l’objet d’un accusé de réception.
Restauration à un instant dans le passé des serveurs à haute disponibilité
Pour les serveurs flexibles configurés avec une haute disponibilité, le système réplique les données de journal en temps réel sur le serveur de secours. Toutes les erreurs utilisateur sur le serveur principal, telles qu'une suppression accidentelle d'une table ou des mises à jour de données incorrectes, sont répliquées sur le réplica de secours. Par conséquent, vous ne pouvez pas utiliser le mode de veille pour récupérer de telles erreurs logiques. Pour effectuer une récupération à partir de ces erreurs, vous devez effectuer une restauration à un point dans le temps à partir de la sauvegarde. En utilisant la fonctionnalité de restauration à un point dans le temps d’un serveur flexible, vous pouvez effectuer une restauration jusqu’au moment où l’erreur s’est produite. Un nouveau serveur de base de données est restauré en tant que serveur flexible dans une seule zone avec un nouveau nom de serveur fourni par l’utilisateur pour les bases de données configurées avec une haute disponibilité. Vous pouvez utiliser le serveur restauré pour plusieurs cas d’usage :
Utilisez le serveur restauré pour la production et éventuellement activer la haute disponibilité avec un réplica de secours sur la même zone ou une autre zone dans la même région.
Si vous voulez restaurer un objet, exportez-le à partir du serveur de base de données restauré et importez-le sur votre serveur de base de données de production.
Si vous voulez cloner votre serveur de base de données à des fins de test et de développement, ou si vous voulez effectuer une restauration pour n’importe quelle autre raison, vous pouvez effectuer une restauration à un instant dans le passé.
Pour savoir comment effectuer une restauration à un instant dans le passé d’un serveur flexible, consultez Restauration à un instant dans le passé d’un serveur flexible.
Prise en charge du basculement
Basculement planifié
Les événements de temps d’arrêt planifiés incluent des mises à jour logicielles périodiques planifiées Azure et des mises à niveau de version mineure. Vous pouvez également utiliser un basculement planifié pour renvoyer le serveur primaire à une zone de disponibilité préférée. Lorsque vous configurez la haute disponibilité, ces opérations s’appliquent d’abord au réplica de secours, tandis que les applications continuent d’accéder au serveur principal. Une fois que le processus a mis à jour le réplica de secours, il vide les connexions du serveur primaire et déclenche un basculement qui active le réplica de secours comme serveur primaire, avec le même nom de serveur de base de données. Les applications clientes se reconnectent avec le même nom de serveur de base de données au nouveau serveur principal et peuvent reprendre leurs opérations. Le processus établit un nouveau serveur de secours dans la même zone que l’ancien serveur principal.
Pour d’autres opérations initiées par l’utilisateur, telles que le scale-compute ou le scale-storage, le processus applique d’abord les modifications sur le serveur de secours, puis sur le serveur principal. À l'heure actuelle, le service ne bascule pas vers le mode de veille. Par conséquent, pendant que l’opération de mise à l’échelle s’exécute sur le serveur principal, les applications rencontrent un court temps d’arrêt.
Vous pouvez également utiliser cette fonctionnalité pour basculer vers le serveur de secours avec un temps d’arrêt réduit. Par exemple, votre serveur principal peut se trouver dans une zone de disponibilité différente de celle de l’application après un basculement non planifié. Vous souhaitez ramener le serveur primaire à la zone précédente pour qu’il se trouve sur la même zone que votre application.
Lorsque vous exécutez cette fonctionnalité, le processus prépare d’abord le serveur de secours pour s’assurer qu’il rattrape les transactions récentes, ce qui permet à l’application de continuer à effectuer des lectures et des écritures. Le processus active le serveur de veille et interrompt les connexions au serveur principal. Votre application peut continuer à écrire dans le serveur principal pendant que le processus établit un nouveau serveur de secours en arrière-plan. Le tableau suivant décrit les étapes impliquées dans le basculement planifié :
| Step | Description | Temps d’arrêt de l’application attendu ? |
|---|---|---|
| 1 | Attendez que le serveur de secours rattrape le serveur principal. | Non |
| 2 | Le système de surveillance interne lance le flux de travail de basculement. | Non |
| 3 | Les écritures de l’application sont bloquées quand le serveur de secours est proche du numéro séquentiel dans le journal (LSN) du serveur primaire. | Oui |
| 4 | Le serveur de secours est promu en tant que serveur indépendant. | Oui |
| 5 | L’enregistrement DNS est mis à jour avec l’adresse IP du nouveau serveur de secours. | Oui |
| 6 | L'application se reconnecte et reprend sa lecture et son écriture avec un nouveau principal. | Non |
| 7 | Un nouveau serveur de secours est établi dans une autre zone. | Non |
| 8 | Le serveur de secours commence à récupérer les journaux (à partir du Stockage Blob Azure) qu’il a manqués pendant la période nécessaire à son établissement. | Non |
| 9 | Un état stable entre le serveur primaire et le serveur de secours est établi. | Non |
| 10 | Le processus de basculement planifié est terminé. | Non |
Le temps d’arrêt de l’application démarre à l’étape 3 et peut reprendre l’opération après l’étape 5. Les autres étapes se produisent en arrière-plan sans impact sur les écritures et les commits de l’application.
Conseil / Astuce
Avec un serveur flexible, vous pouvez éventuellement planifier des activités de maintenance initiées par Azure en choisissant une fenêtre de 60 minutes sur une journée de votre préférence lorsque les activités sur les bases de données sont censées être faibles. Les tâches de maintenance Azure telles que la mise à jour corrective ou les mises à niveau de version mineures se produisent pendant cette fenêtre. Si vous ne choisissez pas de fenêtre personnalisée, le système alloue une fenêtre d’une heure entre 11 h et 17 h à l’heure locale de votre serveur. Ces activités de maintenance initiées par Azure s’exécutent également sur la réplique en attente des serveurs adaptables configurés avec des zones de disponibilité.
Pour obtenir la liste des événements de temps d’arrêt planifiés possibles, consultez Événements de temps d’arrêt planifiés.
Basculement non planifié
Les temps d’arrêt non planifiés peuvent se produire suite à des interruptions imprévues, telles que des pannes matérielles sous-jacentes, des problèmes réseau et des bogues logiciels. Si le serveur de base de données configuré avec une haute disponibilité tombe de façon inattendue, le processus active le réplica de secours et les clients peuvent reprendre leurs opérations. Si vous ne configurez pas la haute disponibilité et que la tentative de redémarrage échoue, le processus provisionne automatiquement un nouveau serveur de base de données. Bien qu’un temps d’arrêt non planifié ne puisse pas être évité, un serveur flexible permet d’atténuer le temps d’arrêt en effectuant automatiquement des opérations de récupération sans nécessiter d’intervention humaine.
Pour plus d’informations sur les basculements non planifiés et les temps d’arrêt, y compris les scénarios possibles, consultez Atténuation des temps d’arrêt non planifiés.
Test de basculement (basculement forcé)
Avec un basculement forcé, vous pouvez simuler un scénario de panne non planifiée tout en exécutant votre charge de travail de production et observer le temps d’arrêt de votre application. Vous pouvez également utiliser un basculement forcé lorsque votre serveur primaire ne répond plus.
Un basculement forcé arrête le serveur primaire et lance le flux de travail de basculement dans lequel l’opération de promotion du serveur de secours est effectuée. Une fois que le serveur de secours a terminé le processus de récupération jusqu’aux dernières données validées, il est promu en tant que serveur primaire. Les enregistrements DNS sont mis à jour et votre application peut se connecter au serveur primaire promu. Votre application peut continuer à écrire sur le serveur primaire, tandis qu’un nouveau serveur de secours est établi en arrière-plan, ce qui n’a pas d’impact sur la durée de bon fonctionnement.
Le tableau suivant décrit les étapes pendant le basculement forcé :
| Step | Description | Temps d’arrêt de l’application attendu ? |
|---|---|---|
| 1 | Le serveur principal s’arrête peu après la réception de la demande de basculement. | Oui |
| 2 | L’application subit un temps d’arrêt au moment où le serveur principal est arrêté. | Oui |
| 3 | Le système de surveillance interne détecte la défaillance et lance un basculement vers le serveur de secours. | Oui |
| 4 | Le serveur de secours passe en mode de récupération avant d’être promu entièrement en tant que serveur indépendant. | Oui |
| 5 | Le processus de basculement attend la fin de la récupération de secours. | Oui |
| 6 | Une fois le serveur actif, le processus met à jour l’enregistrement DNS avec le même nom d’hôte, mais utilise l’adresse IP du serveur de secours. | Oui |
| 7 | L’application peut se reconnecter au nouveau serveur principal et reprendre son fonctionnement. | Non |
| 8 | Un serveur de secours est étable dans la zone préférée. | Non |
| 9 | Le serveur de secours commence à récupérer les journaux (à partir du Stockage Blob Azure) qu’il a manqués pendant la période nécessaire à son établissement. | Non |
| 10 | Un état stable entre le serveur primaire et le serveur de secours est établi. | Non |
| 11 | Le processus de basculement forcé est terminé. | Non |
Le temps d’arrêt de l’application démarre après l’étape 1 et se poursuit jusqu’à la fin de l’étape 6. Les autres étapes s’exécutent en arrière-plan sans affecter les écritures et validations de l’application.
Important
Le processus de basculement de bout en bout comprend (a) le basculement vers le serveur de secours après défaillance du serveur primaire et (b) l’établissement d’un nouveau serveur de secours dans un état stable. Votre application subissant un temps d’arrêt jusqu’à la fin du basculement vers le serveur de secours, mesurez le temps d’arrêt du point de vue de votre application/client au lieu du processus de basculement global de bout en bout.
Considérations relatives à l’exécution de basculements forcés
Le temps d’opération de bout en bout global peut être plus long que le temps d’arrêt réel rencontré par l’application.
Important
Observez toujours temps d’arrêt du point de vue de l’application.
N’effectuez pas de basculements consécutifs sans pause. Attendez au moins 15 à 20 minutes entre chaque basculement, ce qui permet au nouveau serveur de secours d’être entièrement établi.
Effectuez un basculement de service forcé pendant une période de faible activité pour réduire les temps d'indisponibilité.
Meilleures pratiques pour les statistiques PostgreSQL après basculement
Après un basculement PostgreSQL, la gestion des performances optimales de la base de données implique de comprendre les rôles distincts de pg_statistic et les tables pg_stat_* . La pg_statistic table stocke les statistiques d’optimiseur, qui sont cruciales pour le planificateur de requêtes. Ces statistiques comprennent la distribution des données dans les tables et restent intactes après un basculement, ce qui permet au planificateur de requêtes de continuer à optimiser efficacement l'exécution des requêtes sur la base d'informations historiques et précises sur la distribution des données.
En revanche, les tables pg_stat_*, qui enregistrent des statistiques d’activité telles que le nombre d’analyses, de tuples lus et de mises à jour, sont réinitialisées lors du basculement. Un exemple de cette table est pg_stat_user_tables, qui suit l’activité pour les tables définies par l’utilisateur. Cette réinitialisation reflète précisément l’état opérationnel du nouveau serveur primaire, mais elle implique aussi la perte des métriques d’activité historiques susceptibles d’informer le processus d’auto-nettoyage et autres efficacités opérationnelles.
Compte tenu de cette distinction, exécutez ANALYZE après un basculement PostgreSQL. Cette action met à jour les tables pg_stat_*, par exemple pg_stat_user_tables, avec de nouvelles statistiques d’activité, aidant le processus de nettoyage automatique et garantissant que les performances de la base de données restent optimales dans son nouveau rôle. Cette étape proactive permet de combler le fossé entre la préservation des statistiques essentielles de l'optimiseur et l'actualisation des mesures d'activité pour les aligner sur l'état actuel de la base de données.
Expérience en cas de défaillance de zone
Zonal : Pour effectuer une récupération à partir d’une défaillance au niveau de la zone, vous pouvez effectuer une restauration à un point dans le temps à l’aide de la sauvegarde. Vous pouvez choisir un point de restauration personnalisé avec la dernière heure pour restaurer les données les plus récentes. Un nouveau serveur flexible sera déployé dans une autre zone non affectée. Le temps que prend la restauration dépend de la sauvegarde précédente et du volume des journaux des transactions à récupérer.
Pour plus d’informations sur la restauration à un instant dans le passé, consultez Sauvegarde et restauration dans Azure Database pour PostgreSQL Serveur flexible.
Redondant interzone : un serveur flexible est automatiquement basculé sur le serveur de secours dans un délai de 60 à 120 secondes sans perte de données.
Configurations sans zones de disponibilité
Bien que cela ne soit pas recommandé, vous pouvez configurer votre serveur flexible sans haute disponibilité activée. Pour les serveurs flexibles configurés sans haute disponibilité, le service fournit un stockage localement redondant avec trois copies de données, une sauvegarde redondante interzone (dans les régions où il est pris en charge) et une résilience de serveur intégrée pour redémarrer automatiquement un serveur bloqué et déplacer le serveur vers un autre nœud physique. Cette configuration offre d'un SLA de disponibilité de 99,9%. Pendant les événements de basculement planifiés ou non planifiés, si le serveur tombe en panne, le service maintient la disponibilité des serveurs à l’aide de la procédure automatisée suivante :
- Une nouvelle machine virtuelle de calcul Linux est approvisionnée.
- Le stockage contenant les fichiers de données est mappé avec la nouvelle machine virtuelle.
- Le moteur de base de données PostgreSQL est mis en ligne sur la nouvelle machine virtuelle.
L’image suivante montre la transition entre la machine virtuelle et l’échec du stockage.
Récupération d’urgence et continuité d’activité inter-région
Si une catastrophe à l’échelle régionale se produit, Azure peut offrir une protection contre les catastrophes régionales ou géographiques importantes en utilisant une autre région pour la reprise après sinistre. Pour plus d’informations sur l’architecture de récupération d’urgence Azure, consultez Architecture de récupération d’urgence Azure à Azure.
Le serveur flexible fournit des fonctionnalités qui protègent les données et atténuent les temps d’arrêt de vos bases de données stratégiques pendant les événements de temps d’arrêt planifiés et non planifiés. S’appuyant sur l’infrastructure Azure qui offre une résilience et une disponibilité robustes, le serveur flexible intègre des fonctionnalités de continuité d’activité qui offrent une protection contre les pannes, qui répondent aux exigences de temps de récupération et réduisent les risques de perte de données. Lorsque vous concevez vos applications, tenez compte de la tolérance de temps d’arrêt - l’objectif de temps de récupération (RTO) et l’exposition à la perte de données - l’objectif de point de récupération (RPO). Par exemple, votre base de données vitale pour l’entreprise impose une durée de bon fonctionnement plus stricte qu’une base de données de test.
Récupération d’urgence dans la zone géographique multi-région
Sauvegarde et restauration géoredondantes
La sauvegarde et la restauration géoredondantes vous permettent de restaurer votre serveur dans une autre région en cas de sinistre. Il fournit également une durabilité d’au moins 99,99999999999999 % (16 chiffres neuf) des objets de sauvegarde sur un an.
Vous ne pouvez configurer la sauvegarde géoredondante que lorsque vous créez le serveur. Lorsque vous configurez le serveur avec une sauvegarde géoredondante, les données de sauvegarde et les journaux des transactions sont copiés de manière asynchrone dans la région jumelée via la réplication de stockage.
Pour plus d’informations sur la sauvegarde et la restauration géo-redondantes, consultez sauvegarde et restauration géo-redondantes.
Réplicas en lecture
Des réplicas en lecture interrégion peuvent être déployés pour protéger vos bases de données contre les défaillances au niveau de la région. Les réplicas en lecture sont mis à jour de manière asynchrone en utilisant la technologie de réplication physique de PostgreSQL et peuvent présenter un décalage avec le serveur primaire. Les niveaux de calcul à usage général et à mémoire optimisée prennent en charge les réplicas en lecture.
Pour plus d’informations sur les fonctionnalités et considérations relatives aux réplicas en lecture, consultez Réplicas en lecture.
Détection, notification et gestion des pannes
Si vous configurez votre serveur avec une sauvegarde géoredondante, vous pouvez effectuer une géorestauration dans la région jumelée. Un nouveau serveur est approvisionné et récupéré jusqu’aux dernières données disponibles copiées dans cette région.
Vous pouvez également utiliser des réplicas en lecture interrégionaux. Si une panne de région se produit, vous pouvez effectuer une opération de récupération d’urgence en faisant de votre réplica en lecture un serveur en lecture-écriture autonome. Le RPO est censé être jusqu’à 5 minutes (perte de données possible), sauf en cas de défaillance régionale grave où le RPO peut être équivalent au décalage de réplication au moment de l’échec.
Pour plus d’informations sur l’atténuation des temps d’arrêt non planifiés et la récupération après une catastrophe régionale, consultez Atténuation des temps d’arrêt non planifiés.