Fiabilité dans Azure Database pour PostgreSQL

Azure Database pour PostgreSQL est un service de base de données entièrement managé conçu pour vous offrir un contrôle et une flexibilité granulaires 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 certaines informations clés sur le contrat de niveau de service Azure Database pour PostgreSQL (SLA).

Recommandations concernant le déploiement de production

Pour en savoir plus sur le déploiement d’Azure Database pour PostgreSQL pour prendre en charge les exigences de fiabilité de votre solution et sur la façon dont la fiabilité affecte d’autres aspects de votre architecture, consultez les meilleures pratiques d’architecture pour Azure Database pour PostgreSQL dans Azure Well-Architected Framework.

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 requises pour prendre en charge votre serveur de base de données. Vous déployez une ou plusieurs bases de données sur le serveur.

Les serveurs peuvent être déployés dans plusieurs niveaux de calcul : Burstable, Usage général et Mémoire optimisée, chacun d’eux étant 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 Qu’est-ce qu’Azure Database pour PostgreSQL ?.

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 les fichiers de données sont stockés dans le stockage Azure, qui conserve trois copies synchrones localement redondantes des fichiers de base de données pour garantir la durabilité des données.

• Haute disponibilité : Vous pouvez éventuellement activer une configuration de haute disponibilité sur votre serveur. Lorsque vous activez la configuration de haute disponibilité, le service provisionne et gère un serveur de secours chaud. Les modifications de données sur le serveur principal sont répliquées de manière synchrone 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, ce qui permet au service de 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é.

  

  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.

  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. 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 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.

Vous pouvez sélectionner votre type de support de zone de disponibilité via la configuration de haute disponibilité. L’activation de la haute disponibilité 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, les données sont validées de manière synchrone 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.

Les fichiers de données et les journaux d’activité en écriture anticipée (WAL) sont stockés sur des disques managés Premium au sein de chaque zone de disponibilité, avec un stockage localement redondant (LRS) qui stocke automatiquement trois copies de 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 une configuration de calcul, de stockage et de réseau similaire au 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.

  

  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 vous aide également à 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.

  

  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 en tant que zone unique, et la seule configuration de 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é 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é).

  Étant donné que les serveurs se trouvent dans la même zone, il peut réduire la latence d’écriture pour les applications que vous déployez dans la même zone.

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 de la région : Le support par Azure Database pour PostgreSQL des configurations de zone de disponibilité varie selon 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 relatives à cette région, consultez les régions Azure.

• 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 tarifaire	Zone-redundant	Zonal (même zone)
  Burstable	Non pris en charge	Soutenu
  General Purpose	Soutenu	Soutenu
  Mémoire optimisée	Soutenu	Soutenu

• Niveau de service : La redondance de zone nécessite des niveaux usage général ou mémoire optimisée.

  Les déploiements zonaux (de même zone) sont pris en charge sur tous les niveaux tarifaires.

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é, le 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, vous 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 une base de données Azure pour PostgreSQL dans le portail Azure.

• Modifiez la configuration de la zone de disponibilité pour les serveurs existants : Vous pouvez modifier 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 une fois qu’ils ont été créés. Vous devez recréer le serveur.

  Conseil / Astuce

  Il est judicieux 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 qu’il faut attendre lorsque les serveurs sont configurés avec la prise en charge de la haute disponibilité et de la zone de disponibilité et que 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ù toutes les connexions et requêtes de base de données sont gérées par le serveur principal dans la zone de disponibilité principale. Le serveur de secours ne sert pas le trafic client pendant les opérations normales.

• Réplication des données interzones : Les modifications apportées aux données sont répliquées de manière synchrone entre les serveurs principaux et 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.

  L'écriture déclenchée par une transaction d'application et le premier journal est validé dans le 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, le serveur principal reconnaît l’achèvement de 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, et pour la plupart des applications, il 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. Par conséquent, vous ne pouvez pas utiliser le mode veille pour récupérer de ces erreurs, et vous devez effectuer une restauration ponctuelle à partir de la sauvegarde. Pour plus d’informations, consultez Sauvegarde et restauration.

Comportement lors d’une défaillance de zone

Cette section décrit ce qu’il faut attendre lorsque les serveurs sont configurés avec la prise en charge de la haute disponibilité et de la zone de disponibilité et qu’il existe une panne de zone de disponibilité.

• 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.

  En cas de défaillance de zone, 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 de haute disponibilité possibles, consultez les types d’état haute disponibilité. 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 compatibles 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, afin d’activer la résolution des problèmes proactifs et de maintenir la durée de fonctionnement et les performances de votre 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.

• 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 précréé 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. Le service ne déplace pas automatiquement le rôle principal vers la zone d’origine pour éviter toute interruption inutile. 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 silencieux. 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 de la même façon que ce qui se passe lors d’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.

Si votre région primaire échoue, vous pouvez déclencher une promotion afin que votre réplique secondaire devienne la réplique principale. Il existe différents types de basculement que vous pouvez déclencher 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.

Note

Cette section récapitule certaines des 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 restreint aux régions associées Azure.

• 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 d’un certain nombre de facteurs. Lorsque le décalage de réplication est très é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 des considérations supplémentaires qui s’appliquent au processus de promotion, consultez Promouvoir les réplicas en lecture dans Azure Database pour PostgreSQL - Considérations.

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 entre 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 multirégion

• Créer une réplique en lecture : Pour savoir comment créer une réplique en lecture, consultez Créer une réplique en lecture. Les réplicas peuvent être configurés une fois le serveur principal créé, tant que le serveur principal est en cours d’exécution et accessible.

  Pour créer un point de terminaison virtuel, consultez Créer des points de terminaison virtuels.

• Supprimez un réplica en lecture : Pour savoir comment supprimer un réplica en lecture, consultez Supprimer un réplica en lecture.

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 read-only endpoint du endpoint virtuel, il dirige le trafic vers le replica que vous configurez.

• 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 d’un certain nombre de 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 beaucoup 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 : Toutes les connexions actives à la région primaire sont supprimées. Les applications doivent réessayer d’établir des connexions au réplica promu une fois le processus de promotion terminé.

• 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 beaucoup 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’un réplica en lecture est promu comme 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 des répliques de lecture pour vous assurer que vos processus sont valides et que les fonctionnalités satisfont à vos exigences en matière de RTO et de 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. N’oubliez pas que la promotion planifiée suit un processus différent de celui de la promotion lors d’une panne de région.

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 effectue automatiquement des sauvegardes qui fournissent des fonctionnalités de récupération dans le temps et vous protègent contre l’altération accidentelle et la suppression de données. Les sauvegardes sont entièrement gérées par Microsoft, n’interrompent pas la disponibilité du serveur et incluent des sauvegardes complètes et des sauvegardes de journal des transactions.

• Stockage de sauvegarde : Si le serveur est configuré avec une haute disponibilité redondante interzone, les sauvegardes sont stockées dans un stockage redondant interzone (ZRS). Pour les serveurs configurés sans haute disponibilité ou avec une haute disponibilité zonale (à zone unique), les sauvegardes sont stockées dans un stockage localement redondant (LRS).

  Dans les régions Azure avec des paires, vous pouvez configurer le stockage de sauvegarde géoredondant (GRS) au moment de la création du serveur pour répliquer des sauvegardes vers la région jumelée Azure pour une protection supplémentaire contre les défaillances de région. Les sauvegardes sont répliquées de manière asynchrone.

  La période de rétention de sauvegarde par défaut est de 7 jours, avec la possibilité d’é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, à partir duquel vous pouvez ensuite utiliser as-is ou copier des données.

  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 doit peut-être être redémarré dans le cadre du processus de mise à jour. Si la haute disponibilité est activée, 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 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. 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 commerciales. 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 :

• Serveurs configurés avec une haute disponibilité redondante interzone.
• Serveurs configurés avec une haute disponibilité zonale (à zone unique).
• Serveurs configurés sans haute disponibilité.

Contenu connexe

• Fiabilité d'Azure
• Meilleures pratiques d’architecture pour Azure Database pour PostgreSQL
• Vue d’ensemble de la continuité d’activité avec Azure Database pour PostgreSQL
• Récupération d’urgence géographique dans Azure Database pour PostgreSQL
• Accélérateur de solution de résilience Azure Database pour PostgreSQL - Scripts Terraform pour implémenter la plupart des principes de résilience et de récupération décrits dans cet article.