Fiabilité dans Azure Database pour PostgreSQL

Azure Database pour PostgreSQL est un service de base de données entièrement managé qui vous offre un contrôle granulaire et une flexibilité sur les fonctions de gestion de base de données et les paramètres de configuration. Le service fournit des fonctionnalités de haute disponibilité et de récupération d’urgence en fonction de vos besoins.

Lorsque vous utilisez Azure, la fiabilité est une responsabilité partagée. Microsoft fournit une gamme de fonctionnalités pour prendre en charge la résilience et la récupération. Vous êtes responsable de comprendre le fonctionnement de ces fonctionnalités dans tous les services que vous utilisez et de sélectionner les fonctionnalités dont vous avez besoin pour atteindre vos objectifs métier et vos objectifs de temps d’activité.

Cet article explique comment rendre Azure Database pour PostgreSQL résilient à diverses pannes et problèmes potentiels, notamment les pannes temporaires, les pannes de zone de disponibilité, les pannes de région et la maintenance du service. Il décrit également comment utiliser des sauvegardes pour récupérer à partir d’autres types de problèmes et met en évidence des informations clés sur le contrat de niveau de service (SLA) Azure Database pour PostgreSQL.

Recommandations concernant le déploiement de production

Pour savoir comment déployer Azure Database pour PostgreSQL pour prendre en charge les exigences de fiabilité de votre solution et comment la fiabilité affecte d'autres aspects de votre architecture, consultez les meilleures pratiques relatives à l'architecture pour Azure Database pour PostgreSQL dans le framework Azure Well-Architected.

Vue d’ensemble de l’architecture de fiabilité

Cette section décrit certains des aspects importants du fonctionnement du service qui sont les plus pertinents du point de vue de la fiabilité. La section présente l’architecture logique, qui inclut certaines des ressources et fonctionnalités que vous déployez et utilisez. Il traite également de l’architecture physique, qui fournit des détails sur le fonctionnement du service sous les couvertures.

Architecture logique

Lorsque vous travaillez avec Azure Database pour PostgreSQL, vous déployez un serveur, qui représente les ressources de calcul et de stockage nécessaires pour prendre en charge les bases de données que vous déployez sur le serveur.

Vous pouvez déployer des serveurs dans plusieurs niveaux de calcul : Burstable, Usage général et Mémoire optimisée. Chaque niveau est optimisé pour différents types de charges de travail. Dans certaines régions Azure, vous pouvez déployer des serveurs avec Azure Confidential Computing.

Pour plus d’informations sur l’architecture générale des services et les modèles de déploiement, consultez Azure Database pour PostgreSQL vue d’ensemble.

Architecture physique

  • Séparation du calcul et du stockage : Azure Database pour PostgreSQL utilise une architecture de séparation de calcul et de stockage pour prendre en charge la haute disponibilité. Le moteur de base de données s’exécute sur une machine virtuelle Linux, tandis que stockage Azure contient les fichiers de données et conserve trois copies synchrones localement redondantes des fichiers de base de données pour garantir la durabilité des données.

  • Haute disponibilité : Vous pouvez activer une configuration à haute disponibilité sur votre serveur. Lorsque vous activez la configuration de haute disponibilité, le service provisionne et gère un serveur de secours chaud. Le serveur principal réplique de façon synchrone les modifications de données sur le serveur de secours pour garantir la perte de données zéro lors d’une défaillance du serveur principal.

    L’architecture sépare la couche de calcul de la couche de stockage, afin que le service puisse gérer différents types d’échecs de manière appropriée. Pour une résilience plus élevée, vous pouvez répartir les serveurs entre les zones de disponibilité.

    Diagramme montrant l’architecture à haute disponibilité, avec un serveur principal et de secours.

    Un serveur de secours est déployé dans la même configuration de machine virtuelle que le serveur principal, y compris les vCores, le stockage et les paramètres réseau.

    Vous pouvez basculer entre les serveurs en effectuant un basculement. Il existe deux types de basculement : les basculements forcés, qui sont utilisés lorsque le serveur principal échoue et les basculements planifiés, qui sont utilisés pendant certaines opérations de maintenance et dans d’autres scénarios où vous devez réduire le temps d’arrêt de l’application pendant un basculement.

    Lorsque vous effectuez des opérations telles que l’arrêt, le démarrage et le redémarrage, elles se produisent sur les serveurs de base de données principal et de secours en même temps. Les événements planifiés tels que la mise à l’échelle du calcul et la mise à l’échelle du stockage se produisent d’abord sur le serveur de secours, puis sur le serveur principal. Actuellement, le serveur ne bascule pas pour ces opérations planifiées.

    Pour plus d’informations, consultez La haute disponibilité dans Azure Database pour PostgreSQL.

  • Sauvegardes: Azure Database pour PostgreSQL crée automatiquement des sauvegardes de serveur. Pour plus d’informations, consultez Sauvegarde et restauration.

Résilience aux erreurs temporaires

Les erreurs temporaires sont des défaillances courtes et intermittentes dans les composants. Elles se produisent fréquemment dans un environnement distribué comme le cloud, et font partie intégrante des opérations ordinaires. Les erreurs temporaires se corrigent après une courte période de temps. Il est important que vos applications puissent gérer les erreurs temporaires, généralement en réessayant les requêtes affectées.

Toutes les applications hébergées dans le cloud doivent suivre les instructions de gestion des erreurs temporaires Azure lorsqu’elles communiquent avec toutes les API, bases de données et autres composants hébergés dans le cloud. Pour plus d’informations, consultez Recommandations pour la gestion des erreurs temporaires.

Vos applications doivent gérer les erreurs de connectivité temporaires qui peuvent se produire pendant la maintenance, les opérations de mise à l’échelle ou les interruptions réseau. Suivez ces recommandations :

  • Lorsque votre application rencontre des erreurs temporaires, réessayez l’opération à l’aide d’un backoff exponentiel. Augmentez le délai entre les nouvelles tentatives et limitez le nombre de tentatives. Si l’opération échoue toujours après les nouvelles tentatives maximales, traitez-la comme une défaillance.

  • Si possible, utilisez des bibliothèques clientes (également appelées pilotes) qui gèrent automatiquement les nouvelles tentatives.

  • Les erreurs temporaires qui se produisent pendant les opérations d’écriture nécessitent une considération plus minutieuse. Envisagez d’effectuer vos opérations d’écriture idempotentes afin qu’elles puissent être exécutées en toute sécurité plusieurs fois.

Pour plus d’informations, consultez Gestion des erreurs de connectivité temporaires dans Azure Database pour PostgreSQL.

Résilience aux échecs de zone de disponibilité

Les zones de disponibilité sont des groupes physiquement distincts de centres de données au sein d’une région Azure. Lorsqu'une zone tombe en panne, les services peuvent basculer vers l'une des zones restantes.

Sélectionnez votre type de prise en charge de zone de disponibilité via la configuration de haute disponibilité. Lorsque vous activez la haute disponibilité, le service déploie un serveur de secours en même temps que votre serveur principal. Ce modèle de haute disponibilité permet de s’assurer que les données validées ne sont jamais perdues pendant les défaillances. Quel que soit le modèle de déploiement à haute disponibilité que votre serveur utilise, il valide de façon synchrone les données sur les serveurs principaux et de secours. Si une interruption se produit sur le serveur principal, le serveur bascule automatiquement vers le serveur de secours.

Chaque zone de disponibilité stocke les fichiers de données et les journaux de transactions en écriture anticipée (WAL) sur des disques managés Premium avec stockage localement redondant (LRS), assurant automatiquement le stockage de trois copies des données dans chaque zone.

Azure Database pour PostgreSQL prend en charge deux types de configuration de zone de disponibilité lorsque vous utilisez la haute disponibilité :

  • Haute disponibilité redondante interzone : La redondance de zone offre le niveau de résilience de zone le plus élevé en déployant un serveur principal dans une zone de disponibilité et un serveur de secours dans une autre zone de disponibilité. Le serveur de secours utilise la configuration de calcul, de stockage et de réseau similaire à celle du serveur principal. Une configuration redondante interzone permet d’isoler physiquement l’ensemble de la pile entre le serveur principal et le serveur de secours.

    Vous pouvez sélectionner les zones de disponibilité des serveurs principaux et de secours ou laisser Microsoft les choisir.

    Nous vous recommandons de déployer des déploiements redondants interzone pour les serveurs de production.

    Diagramme d’une configuration d’Azure Database pour PostgreSQL avec redondance interzone.

    Les opérations d’écriture peuvent rencontrer une faible augmentation de la latence de validation, car le service réplique de façon synchrone les données sur le serveur de secours. L’impact varie en fonction de la charge de travail, de la référence SKU sélectionnée et de la région.

  • Haute disponibilité zonale (même zone) : Les serveurs principaux et de secours utilisent la même zone de disponibilité. Si une interruption se produit sur le serveur principal, mais que la zone est toujours saine, le serveur bascule automatiquement vers le serveur de secours. Un déploiement zonal vous offre une haute disponibilité dans une seule zone de disponibilité. Il vous protège contre les défaillances au niveau du nœud et permet également de réduire les temps d’arrêt de l’application pendant les événements de temps d’arrêt planifiés et non planifiés. Toutefois, elle ne protège pas contre une panne dans cette zone.

    Schéma montrant une configuration zonale d’Azure Database pour PostgreSQL.

    La haute disponibilité zonale (même zone) est disponible uniquement dans les situations suivantes :

    • La région ne prend pas en charge les zones de disponibilité. La région fonctionne efficacement comme une seule zone, de sorte que la seule configuration à haute disponibilité que vous pouvez sélectionner est la même zone.
    • Si une région ne dispose pas d’une capacité suffisante pour un déploiement redondant interzone, le service peut initialement placer les deux serveurs dans la même zone de disponibilité, puis les migrer automatiquement vers des zones distinctes lorsque la capacité devient disponible. Cette option est disponible lorsque vous utilisez le portail Azure ou Azure CLI pour déployer un serveur. Pour plus d’informations, consultez Configurer les options Critique pour l’entreprise (haute disponibilité).

    Le placement des serveurs dans la même zone peut réduire la latence d’écriture pour les applications que vous déployez dans la même zone.

    Lorsque les serveurs se trouvent dans la même zone, la latence d’écriture pour les applications que vous déployez dans la même zone peut être réduite.

Si vous configurez votre serveur sans haute disponibilité, il s’exécute sur un seul serveur. Si ce serveur ou sa zone tombe en panne, votre serveur n’est pas disponible. Pour plus d’informations, consultez Configurations sans zones de disponibilité.

Exigences

  • Prise en charge des régions : Azure Database pour PostgreSQL prend en charge les configurations de zone de disponibilité différemment entre les régions Azure. Pour obtenir la liste complète des régions, ainsi que les types de prise en charge des zones de disponibilité et toutes les considérations spécifiques pour chaque région, consultez Azure régions.

  • Niveau de calcul : Le tableau suivant répertorie la prise en charge du niveau de calcul pour chaque type de prise en charge de zone de disponibilité :

    Niveau de calcul Redondance de zone Zonal (même zone)
    Burstable Non pris en charge Non pris en charge
    General Purpose Soutenu Soutenu
    Mémoire optimisée Soutenu Soutenu

  • Niveau de service : Les deux types de haute disponibilité nécessitent des niveaux usage général ou mémoire optimisée.

Considérations

Capacité de la région : Si une région ne dispose pas d’une capacité suffisante pour un déploiement redondant interzone, le service peut initialement placer les deux serveurs dans la même zone de disponibilité et les migrer automatiquement vers des zones distinctes lorsque la capacité devient disponible. Cette option est disponible lorsque vous utilisez le portail Azure ou Azure CLI pour déployer un serveur. Pour plus d’informations, consultez Configurer les options Critique pour l’entreprise (haute disponibilité).

Coûts

Lorsque vous activez la haute disponibilité, un serveur de secours est créé et facturé au même taux que le serveur principal. La configuration de la zone de disponibilité n’affecte pas le coût. Il n’y a pas de frais pour la réplication des données dans ou entre les zones de disponibilité. Selon votre volume de stockage de sauvegarde, vous pouvez également être facturé pour le stockage de sauvegarde. Pour obtenir des informations de tarification détaillées, consultez la tarification d’Azure Database pour PostgreSQL.

Configurez la prise en charge des zones de disponibilité

Pour configurer la prise en charge des zones de disponibilité pour un serveur, configurez les paramètres de haute disponibilité.

  • Créez un serveur redondant interzone : Pour savoir comment créer un serveur avec une haute disponibilité et une redondance de zone activée, consultez Démarrage rapide : Créer un serveur Azure Database pour PostgreSQL.

  • Modifiez la configuration de la zone de disponibilité pour les serveurs existants : Modifiez la configuration de la zone de disponibilité pour les serveurs existants en modifiant les paramètres de haute disponibilité. Pour obtenir des instructions détaillées, consultez Activer la haute disponibilité pour les serveurs existants.

    Vous ne pouvez pas modifier la zone utilisée pour le serveur principal ou de secours. Vous devez recréer le serveur.

    Conseil / Astuce

    Nous vous recommandons d’attendre que l’activité du serveur soit faible avant de modifier la configuration de haute disponibilité.

  • Désactivez la haute disponibilité : La désactivation de la haute disponibilité supprime le serveur de secours, de sorte que votre serveur n’est pas résilient aux pannes dans sa zone de disponibilité. Pour plus d’informations, consultez Désactiver la haute disponibilité.

Comportement lorsque toutes les zones sont saines

Cette section décrit ce que vous devez attendre lorsque vous configurez des serveurs avec la prise en charge de la haute disponibilité et de la zone de disponibilité, et toutes les zones de disponibilité sont opérationnelles.

  • Opération interzone : Les applications clientes PostgreSQL se connectent au serveur principal à l’aide du nom du serveur de base de données. Azure Database pour PostgreSQL utilise une configuration active-passive où le serveur principal de la zone de disponibilité principale gère toutes les connexions et requêtes de base de données. Le serveur de secours ne sert pas le trafic client pendant les opérations normales.

  • Réplication des données interzones : Le serveur principal réplique de manière synchrone les modifications apportées au serveur de secours. Les transactions ne sont pas considérées comme terminées tant que le serveur principal et le serveur de secours n'ont pas reconnu l'écriture.

    Lorsqu’une application écrit et valide des données, PostgreSQL enregistre d’abord la modification dans le wal sur le serveur principal. Le serveur principal diffuse ces journaux vers le serveur de secours à l’aide du protocole de streaming PostgreSQL. Une fois que le serveur de secours stocke durablement le wal, le serveur principal confirme l’écriture. L’application valide sa transaction uniquement après cet accusé de réception. Ce processus d’accusé de réception n’attend pas que les journaux soient appliqués au serveur de secours.

    Les effets de la réplication sont différents en fonction de la configuration de la zone de disponibilité utilisée par votre serveur :

    • Redondant interzone : Étant donné que les serveurs se trouvent dans des zones distinctes, cette approche garantit aucune perte de données lors d’une défaillance de zone. Cette situation est également parfois appelée atteindre un objectif de point de récupération (RPO) de zéro pour les défaillances de zone.

      Toutefois, la réplication interzone peut introduire une faible latence supplémentaire. L’impact de la latence dépend de l’application. Pour la plupart des applications, la latence supplémentaire est négligeable.

    • Zonal : étant donné que les deux serveurs se trouvent dans la même zone, aucun trafic n’est répliqué entre les zones.

    Note

    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 de mises à jour de données incorrectes, sont répliquées sur le serveur de secours. Vous ne pouvez pas recourir au serveur de secours pour vous remettre de ce type d’erreurs ; vous devez effectuer une restauration à un instant donné à partir de la sauvegarde. Pour plus d’informations, consultez Sauvegarde et restauration.

Comportement lors d’une défaillance de zone

Cette section décrit à quoi vous attendre lorsque vous configurez des serveurs avec la haute disponibilité et la prise en charge des zones de disponibilité, et qu’une zone de disponibilité tombe en panne.

  • Détection et réponse : Azure vérifie régulièrement l’intégrité des serveurs principaux et 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.

    Si une zone de disponibilité échoue, le comportement est différent en fonction de la configuration de la zone de disponibilité utilisée par votre serveur :

    • Redondant entre zones : Azure Database pour PostgreSQL détecte automatiquement les pannes de zone de disponibilité. Pour afficher les types d’état possibles de la haute disponibilité, consultez Surveillance de l’état d’intégrité de la haute disponibilité (HA). En cas d’échec d’une zone, Azure lance un basculement forcé vers le serveur de secours sans que vous deviez prendre des mesures.

    • Zonale: Si la zone de disponibilité qui héberge un serveur zonal devient indisponible, les serveurs principaux et de secours ne sont pas disponibles. Dans ce scénario, le service ne fournit pas de basculement automatique. Vous êtes responsable de la détection de la panne de zone et de l’exécution d’actions de récupération, telles que la restauration de sauvegardes redondantes interzone sur un serveur distinct dans une autre zone de disponibilité ou région.

  • Notification: 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 à haute disponibilité. La fonctionnalité de supervision est basée sur Azure Resource Health et peut détecter et alerter sur tous les problèmes susceptibles d’affecter la préparation à la bascule ou la disponibilité globale de votre base de données. Évaluez les métriques clés telles que l’état de connexion, l’état de basculement et l’intégrité de la réplication des données pour permettre la résolution proactive des problèmes et aider à maintenir le temps d’activité et les performances de votre base de données.

    Pour obtenir un guide détaillé sur la configuration et l’interprétation des états de santé de la haute disponibilité (HA), consultez Surveillance des états de santé de la haute disponibilité (HA).

  • Demandes actives : Lorsqu’une zone de disponibilité devient indisponible, toutes les demandes en cours adressées aux serveurs de la zone concernée peuvent être arrêtées. Les applications doivent réessayer ces demandes. Si vos clients gèrent les erreurs temporaires de manière appropriée en réessayant après une courte période de temps, ils évitent généralement un impact significatif.

  • Perte de données attendue : La quantité de perte de données dépend de la configuration de la zone de disponibilité utilisée par votre serveur.

    • Redondant interzone : Perte de données nulle est attendue pendant le basculement de zone grâce à la réplication synchrone entre le serveur principal et le serveur de secours dans différentes zones.

    • Zonale: Les données sur les serveurs de la zone affectée ne sont pas disponibles jusqu'à ce que la zone soit restaurée.

  • Temps d’arrêt attendu : La quantité de temps d’arrêt dépend de la configuration de la zone de disponibilité utilisée par votre serveur.

    • Redondant interzone : Le basculement se termine généralement en 60 à 120 secondes. Si vos clients gèrent les erreurs temporaires de manière appropriée en réessayant après une courte période de temps, ils évitent généralement un impact significatif.

    • Zonale: Les serveurs d’une zone affectée ne sont pas disponibles tant que la zone de disponibilité n’est pas récupérée.

  • Redistribution: Le comportement de réacheminement du trafic dépend de la configuration de la zone de disponibilité utilisée par votre serveur.

    • Redondant interzone : Après le basculement, le serveur de secours précédent devient le nouveau serveur principal et commence à accepter de nouvelles connexions. Azure établit automatiquement un nouveau serveur de secours dans la zone primaire d’origine après sa récupération. Pour des détails complets, consultez Basculement forcé.

    • Zonale: Lorsqu’une zone n’est pas disponible, votre serveur n’est pas disponible. Si vous disposez d’un serveur distinct que vous avez créé à l’avance dans une autre zone de disponibilité ou région, vous êtes responsable de la réacheminement du trafic vers ce serveur.

Récupération de la zone

Le comportement de récupération de zone dépend de la configuration de la zone de disponibilité utilisée par votre serveur.

  • Redondant interzone : Lorsque la zone de disponibilité récupère, Azure Database pour PostgreSQL reconstruit automatiquement le serveur de secours dans la zone récupérée et synchronise celui-ci avec le serveur principal actuel. La zone récupérée sert ensuite d’emplacement de secours. Pour éviter toute interruption inutile, le service ne déplace pas automatiquement le rôle principal vers la zone d’origine. Vous pouvez lancer manuellement un basculement planifié si vous souhaitez retourner le serveur principal dans la zone d’origine.

  • Zonale: Une fois la zone saine, les serveurs de la zone sont à nouveau disponibles. Vous êtes responsable des procédures de récupération de zone et de la synchronisation des données dont vos charges de travail ont besoin.

Tester les pannes de zone

Les options de test des défaillances de zone dépendent de la configuration de la zone de disponibilité utilisée par votre instance.

  • Redondant interzone : Vous pouvez tester la résilience de votre application au basculement en lançant un basculement forcé. Un basculement forcé vous permet de simuler un scénario de panne non planifié lors de l’exécution de votre charge de travail et d’observer le temps d’arrêt de votre application. Nous vous recommandons d’exécuter des simulations dans un environnement hors production ou à un moment calme. Pour obtenir davantage d’informations, consultez Lancer un basculement forcé.

  • Zonale: Bien que vous ne puissiez pas simuler une panne de zone complète, vous pouvez simuler l’indisponibilité de votre serveur d’une manière similaire à une panne de zone. Pour plus d’informations, consultez Arrêter le calcul d’un serveur.

Résilience aux défaillances à l’échelle de la région

Azure Database pour PostgreSQL prend en charge les réplicas en lecture interrégions, que vous pouvez utiliser pour gérer une copie synchronisée de votre base de données dans une autre région pour accélérer la récupération.

Vous pouvez également utiliser des sauvegardes géoredondantes, dans les régions prises en charge, pour fournir une récupération interrégion. Toutefois, les sauvegardes impliquent généralement plus de temps d’arrêt et de perte de données que la réplication. Pour plus d’informations, consultez Sauvegarde et restauration.

Réplicas de lecture inter-régions

Vous pouvez déployer des réplicas de lecture pour protéger vos bases de données contre les défaillances au niveau régional. Chaque réplica en lecture est un serveur distinct d'Azure Database pour PostgreSQL. Lorsque vous placez un réplica de lecture dans une deuxième région Azure, votre serveur de base de données peut assurer une résilience face à un problème touchant toute la région. Vous pouvez déployer jusqu’à cinq réplicas en lecture, qui peuvent éventuellement se trouver dans différentes régions Azure. La technologie de réplication physique de PostgreSQL met à jour les réplicas de lecture de manière asynchrone, et ils peuvent accuser un retard par rapport au primaire. Les réplicas en lecture inter-régions peuvent éventuellement servir des charges de travail en lecture seule afin de réduire la latence des applications distribuées globalement ou de décharger le trafic de lecture à partir du serveur principal. Pour plus d’informations sur les fonctionnalités et considérations relatives aux réplicas en lecture, consultez Réplicas en lecture.

Les points de terminaison virtuels fournissent des points de terminaison en lecture-écriture et en lecture seule et redirigent automatiquement le trafic lorsque une réplique est promue, ce qui aide à minimiser les temps d'arrêt lors des événements de basculement. Nous vous recommandons vivement d’utiliser des points de terminaison virtuels avec des répliques de lecture multi-régions pour améliorer la résilience des applications. Pour plus d’informations, consultez les points de terminaison virtuels des réplications en lecture dans Azure Database pour PostgreSQL.

Schéma montrant un serveur principal dans une région et une réplique de lecture dans une seconde région.

Si votre région primaire échoue, vous pouvez déclencher une promotion afin que votre réplique secondaire devienne la réplique principale. Différents types de basculement peuvent être appropriés en fonction de la façon dont vous utilisez des réplicas en lecture. Lorsque vous utilisez des réplicas en lecture pour assurer la résilience aux défaillances de région, vous utilisez généralement l’approche de promotion vers le serveur principal , qui met à jour votre point de terminaison virtuel. Pendant une panne de région, vous devez effectuer une promotion forcée, ce qui peut entraîner une certaine perte de données pour toutes les données non répliquées. Dans les scénarios planifiés où la région primaire est saine, vous pouvez choisir d’effectuer une promotion planifiée pour éviter la perte de données. Pour plus d’informations, consultez Promouvoir les réplicas de lecture dans Azure Database pour PostgreSQL.

Schéma montrant un réplica en lecture dans une deuxième région Azure qui a été promu en réplica principal.

Note

Cette section récapitule quelques informations importantes sur la façon dont les réplicas en lecture peuvent prendre en charge la résilience aux défaillances à l’échelle de la région. Vous pouvez également utiliser des réplicas en lecture pour améliorer les performances et prendre en charge un grand nombre d'utilisateurs répartis géographiquement. Pour plus d’informations, consultez Réplications en lecture seule.

Exigences

  • Prise en charge de la région : Vous pouvez créer des réplicas de lecture interrégionales dans n’importe quelle région qui prend en charge Azure Database pour PostgreSQL. Vous n'êtes pas limité à Azure régions jumelées.

  • Niveaux de calcul : Les niveaux de calcul à usage général et optimisés pour la mémoire prennent en charge les réplicas de lecture. Le niveau Burstable ne prend pas en charge les réplicas en lecture.

Considérations

  • Différences de configuration : Les réplicas en lecture peuvent ne pas hériter de tous les paramètres de configuration du serveur principal. Planifiez la configuration des paramètres nécessaires après le basculement. Votre serveur principal et vos réplicas doivent être symétriques, ce qui signifie qu’ils doivent avoir les mêmes niveaux, tailles de stockage et valeurs pour certains paramètres. Pendant les défaillances de région, l’exigence du serveur symétrique peut être annulée pour les promotions forcées, mais il est recommandé d’avoir une configuration symétrique dans la mesure du possible pour éviter des problèmes inattendus. Pour plus d’informations, consultez Gestion de la configuration.

  • Surveillance du décalage de réplication : Le processus de réplication asynchrone implique un décalage de réplication, qui peut varier en fonction de nombreux facteurs. Lorsque le décalage de réplication est élevé, votre serveur peut rencontrer des problèmes. Il est important de surveiller le décalage de réplication afin de pouvoir atténuer les problèmes avant qu’ils ne s'aggravent. Pour plus d’informations, consultez Surveiller la réplication.

  • Haute disponibilité : Les réplicas en lecture ne peuvent pas avoir la haute disponibilité activée et quand ils sont promus, ils n’ont pas non plus de haute disponibilité. Vous êtes responsable de configurer la haute disponibilité après avoir promu une réplique.

Pour d’autres facteurs concernant le processus de promotion à prendre en compte, consultez Points à considérer.

Coûts

Les réplicas en lecture entraînent des coûts de calcul et de stockage, ainsi que des frais de transfert de données inter-régions pour la réplication. Pour plus d’informations sur la tarification, consultez la tarification d’Azure Database pour PostgreSQL et la tarification de la bande passante.

Configurer la prise en charge de la multirégion

Comportement lorsque toutes les régions sont saines

Cette section décrit à quoi s'attendre lorsque votre serveur est configuré avec un réplica de lecture situé dans une autre région et un point de terminaison virtuel, et que toutes les régions sont opérationnelles :

  • Routage du trafic entre les régions : Dans les opérations normales, votre point de terminaison virtuel dirige le trafic pour le point de terminaison en lecture-écriture vers le serveur principal de la région primaire. Si vous utilisez également le point de terminaison virtuel en lecture seule, il dirige le trafic vers le réplica que vous avez configuré.

  • Réplication des données entre les régions : Les réplicas en lecture inter-régions utilisent la réplication asynchrone pour réduire l’impact sur les performances du serveur principal. La quantité de décalage de réplication dépend de nombreux facteurs, notamment la charge d’écriture et la latence entre le serveur principal et les réplicas. Le décalage de réplication est généralement d’au moins plusieurs minutes, mais il peut être plus long. Pour plus d’informations, consultez Surveiller la réplication.

Comportement lors d’une défaillance de région

Cette section décrit ce à quoi s'attendre lorsque votre serveur est configuré avec un réplica en lecture dans une autre région et un point de terminaison virtuel, et qu'il y a une panne dans la région principale :

  • Détection et réponse : Vous êtes responsable de la détection d’une panne dans la région primaire et de la promotion manuelle d’une réplique en lecture pour devenir le nouveau serveur principal. Lors d’une panne de région, vous devez effectuer une promotion forcée, ce qui entraîne la perte de toutes les données non répliquées.

    Important

    Vous êtes responsable du déclenchement de la promotion. Azure ne promeut pas automatiquement les répliques en lecture, même s’il y a un échec de région.

    Pour obtenir des étapes détaillées pour initier une promotion, consultez Basculer le réplica de lecture en principal.

  • Notification: Microsoft ne vous avertit pas automatiquement lorsqu’une région est en panne. Toutefois, vous pouvez utiliser Azure Service Health pour comprendre l’intégrité globale du service, y compris les défaillances de région, et vous pouvez configurer des alertes Service Health pour vous avertir des problèmes.

  • Demandes actives : Le processus de promotion supprime toutes les connexions actives à la région primaire. Une fois le processus de promotion terminé, les applications doivent réessayer de se connecter à la réplique promue.

  • Perte de données attendue : Lors d’une panne de région, vous devez effectuer une promotion forcée, ce qui entraîne la perte permanente de toutes les données non répliquées.

    La quantité de perte de données dépend du décalage de réplication au moment de la panne. Le décalage de réplication est généralement d’au moins plusieurs minutes, mais il peut être plus long. Pour plus d’informations, consultez Surveiller la réplication.

  • Temps d’arrêt attendu : La promotion forcée se termine généralement dans les 1 à 3 minutes suivant le déclenchement. Les applications peuvent également avoir besoin de se reconnecter au point de terminaison approprié. Les points de terminaison virtuels sont mis à jour dans le cadre du processus de promotion forcé. Les applications doivent respecter la durée de vie (TTL) des enregistrements DNS du point de terminaison pour s’assurer qu’elles se reconnectent rapidement au réplica correct une fois la promotion terminée.

  • Réacheminement du trafic : Le point de terminaison virtuel du serveur redirige automatiquement le trafic d’application vers le nouveau réplica principal.

    Note

    Une fois qu’une réplique en lecture est promue serveur principal, la configuration de haute disponibilité n’est pas activée. Vous devez activer manuellement la configuration de haute disponibilité ou l’ajouter à vos propres processus d’automatisation.

Récupération de région

Lorsque vous utilisez des points de terminaison virtuels, une fois la région primaire récupérée, l’ancien serveur principal est automatiquement configuré en tant que réplica de lecture. Vous pouvez effectuer une autre promotion pour renvoyer les opérations principales à votre région primaire préférée.

Tester les défaillances régionales

Testez régulièrement les procédures de promotion de réplica en lecture pour vous assurer que vos processus sont valides et que les fonctionnalités répondent aux exigences de votre objectif de délai de récupération (RTO) et de l’objectif de point de récupération (RPO).

Vous pouvez promouvoir un réplica en lecture pour devenir le serveur principal à tout moment, même lorsque toutes les régions sont saines. Pour les tests :

  • Vous pouvez effectuer des tests de promotion forcés. Nous vous recommandons d’effectuer ces tests dans un environnement hors production, car cela peut entraîner une perte de données. Le test de promotion forcée permet de simuler le comportement observé en cas de panne de région.
  • Pour les scénarios de maintenance planifiée ou de test dans lesquels vous souhaitez éviter la perte de données, utilisez plutôt une promotion planifiée. Toutefois, la promotion planifiée suit un processus différent de celui de la promotion lors d’une panne de région, de sorte qu’elle peut ne pas refléter le comportement pendant une panne de région réelle.

Pour obtenir des instructions pas à pas, consultez Basculer vers le réplica en lecture vers le réplica principal.

Dans le cadre de votre stratégie de récupération d’urgence, exécutez régulièrement des exercices de récupération complète. Ces exercices doivent inclure la validation des données, les tests de fonctionnalités d’application et les procédures de restauration documentées.

Sauvegarde et restauration

Azure Database pour PostgreSQL sauvegarde automatiquement vos données. Ces sauvegardes fournissent des fonctionnalités de récupération à un point dans le temps et vous aident à vous protéger contre l’altération accidentelle et la suppression de données. Microsoft gère entièrement les sauvegardes. Ils n’interrompent pas la disponibilité du serveur et incluent des sauvegardes complètes et des sauvegardes de journal des transactions.

  • Stockage de sauvegarde : Si vous déployez le serveur dans une région avec des zones de disponibilité, le service stocke les sauvegardes dans le stockage redondant interzone (ZRS), quelle que soit la configuration de haute disponibilité du serveur. Pour les serveurs déployés dans des régions sans zones de disponibilité, le service stocke les sauvegardes dans le stockage localement redondant (LRS).

    Dans les régions Azure associées par paires, vous pouvez configurer le stockage de sauvegarde géoredondant lors de la création du serveur afin de répliquer les sauvegardes vers la région Azure appariée pour une protection supplémentaire contre les pannes régionales. Le service réplique les sauvegardes de manière asynchrone.

    La période de rétention de sauvegarde par défaut est de sept jours, mais vous pouvez étendre la rétention jusqu’à 35 jours. Vous pouvez également utiliser Sauvegarde Azure pour le stockage à long terme des sauvegardes manuelles pendant jusqu’à 10 ans. Toutes les sauvegardes sont chiffrées.

  • Restaurer: La récupération dans le temps vous permet de restaurer votre base de données à tout moment dans la période de rétention de sauvegarde. Le processus de restauration crée un serveur de base de données avec un nouveau nom de serveur fourni par l’utilisateur. Vous pouvez utiliser le nouveau serveur as-is ou copier des données à partir de celui-ci.

    Lorsque vous restaurez une sauvegarde géoredondante, vous créez un serveur dans la région jumelée.

    Cette fonctionnalité est utile pour récupérer des modifications accidentelles des données, des erreurs d’application ou des scénarios de test.

Pour la plupart des solutions, vous ne devez pas vous appuyer exclusivement sur les sauvegardes. Utilisez plutôt les autres fonctionnalités décrites dans ce guide pour prendre en charge vos exigences de résilience. Toutefois, les sauvegardes protègent contre certains risques que d’autres approches ne le font pas. Pour plus d’informations, consultez Que sont la redondance, la réplication et la sauvegarde ?.

Pour plus d’informations, consultez Sauvegarde et restauration dans Azure Database pour PostgreSQL.

Résilience à la maintenance du service

Azure Database pour PostgreSQL gère automatiquement les tâches de maintenance critiques, notamment la mise à jour corrective du matériel sous-jacent, du système d’exploitation et du moteur de base de données. Le service inclut des mises à jour de sécurité, des mises à jour logicielles et des mises à niveau de versions mineures dans le cadre de la maintenance planifiée.

Pour vous assurer que votre serveur reste disponible pendant les fenêtres de maintenance, suivez les recommandations suivantes :

  • Activer la haute disponibilité : Pendant la maintenance, le serveur peut avoir besoin de redémarrer dans le cadre du processus de mise à jour. Si vous activez la haute disponibilité, les opérations de maintenance utilisent généralement des mises à jour propagées pour réduire les temps d’arrêt. Les activités de maintenance périodiques telles que les mises à niveau de version mineures sont effectuées d'abord sur la réplique de secours. Pour réduire les temps d’arrêt, le nœud de secours devient le nœud principal afin que les charges de travail continuent de s’exécuter sur le nœud promu pendant que les tâches de maintenance sont effectuées sur l’autre nœud. Ce séquencement s’applique si votre serveur utilise une haute disponibilité redondante interzone ou zonale.

    Pour les serveurs sans haute disponibilité activée, attendez-vous à un bref temps d’arrêt pendant les opérations de maintenance. Avec la haute disponibilité activée, les opérations de maintenance se terminent généralement avec un temps d’arrêt minimal ou aucun temps d’arrêt.

  • Configurer des fenêtres de maintenance personnalisées : Vous pouvez configurer la planification de maintenance pour qu’elle soit gérée par le système ou définir une fenêtre de maintenance personnalisée pour réduire l’impact sur vos opérations métier. Planifiez la maintenance pendant les périodes de faible activité pour réduire l’impact de l’entreprise. Pour plus d’informations, consultez Planification de la maintenance.

  • Implémentez la logique de nouvelle tentative : Assurez-vous que vos applications peuvent gérer de brèves interruptions de connectivité qui peuvent se produire pendant les redémarrages de maintenance. Pour rendre vos applications résilientes à ces types de problèmes, consultez les conseils de résilience aux erreurs temporaires .

Contrat de niveau de service

Le contrat de niveau de service (SLA) pour les services Azure décrit la disponibilité attendue de chaque service et les conditions que votre solution doit respecter pour atteindre cette attente de disponibilité. Pour plus d’informations, consultez les SLA pour les services en ligne.

Azure Database pour PostgreSQL fournit des contrats SLA de disponibilité différents, en fonction de la configuration du serveur :

  • Les serveurs configurés avec une disponibilité élevée redondante par zone offrent un SLA de disponibilité de 99,99 %.
  • Les serveurs configurés avec une haute disponibilité zonale proposent un SLA de disponibilité de 99,95 %.
  • Les serveurs configurés sans haute disponibilité offrent un accord de niveau de service (SLA) de disponibilité de 99,9 %.

Contenu connexe

  • Last updated on