Haute disponibilité dans Azure Database pour PostgreSQL – Serveur unique

  • Article

S’APPLIQUE À : Azure Database pour PostgreSQL – Serveur unique versions

Important

Azure Database pour PostgreSQL - Serveur unique est en voie de mise hors service. Nous vous recommandons vivement de procéder à une mise à niveau vers Azure Database pour PostgreSQL – Serveur flexible. Pour plus d’informations sur la migration vers Azure Database pour PostgreSQL – Serveur flexible, consultez Qu’en est-il du serveur unique Azure Database pour PostgreSQL ?.

Le service Azure Database pour PostgreSQL – Serveur unique offre un niveau élevé de disponibilité de durée de bon fonctionnement de temps d’activité, financièrement garanti par un contrat de niveau de service (SLA). Azure Database pour PostgreSQL offre une haute disponibilité pendant des événements planifiés, comme les opérations de mise à l’échelle du calcul initiées par l’utilisateur, ainsi que pendant des événements non planifiés, comme les défaillances de matériel, de logiciels ou de réseau sous-jacents. Le service Azure Database pour PostgreSQL peut rapidement récupérer de la plupart des circonstances critiques, ce qui garantit pratiquement une absence totale de temps d’arrêt.

Azure Database pour PostgreSQL convient pour l’exécution de bases de données stratégiques nécessitant une durée de bon fonctionnement longue. Reposant sur l’architecture Azure, le service intègre des fonctionnalités de haute disponibilité, de redondance et de résilience pour réduire les temps d’arrêt de base de données dus à des interruptions planifiées et non planifiées, sans que vous ayez à configurer des composants supplémentaires.

Composants dans Azure Database pour PostgreSQL – Serveur unique

Composant Description
Serveur de base de données PostgreSQL Azure Database pour PostgreSQL offre des fonctionnalités de sécurité, d’isolement, de protection des ressources et de redémarrage rapide pour les serveurs de base de données. Ces fonctionnalités facilitent des opérations telles que la mise à l’échelle et la récupération du serveur de base de données après une panne en quelques secondes.
Les modifications de données dans le serveur de base de données se produisent généralement dans le contexte d’une transaction de base de données. Toutes les modifications de base de données sont enregistrées de façon synchrone sous la forme de journaux WAL (write-ahead log) sur le service Stockage Azure qui est attaché au serveur de base de données. Au cours de processus de point de contrôle de base de données, les pages de données de la mémoire du serveur de base de données sont également vidées dans le stockage.
Stockage à distance Les fichiers de données physiques PostgreSQL et les fichiers WAL sont tous stockés sur le service Stockage Azure qui est architecturé pour stocker trois copies des données à l’intérieur d’une région afin de garantir la redondance, la disponibilité et la fiabilité des données. La couche de stockage est également indépendante du serveur de base de données. Elle peut être détachée d’un serveur de base de données défaillant et être rattachée à un nouveau serveur de base de données dans un délai de quelques secondes. En outre, le service Stockage Azure surveille constamment les erreurs de stockage. Toute altération de bloc détectée est automatiquement corrigée par l’instanciation d’une nouvelle copie du stockage.
Passerelle La passerelle agit comme un proxy de base de données, achemine toutes les connexions clientes vers le serveur de base de données.

Réduction des temps d’arrêt planifiés

Le service Azure Database pour PostgreSQL est architecturé pour offrir une haute disponibilité pendant les opérations planifiées nécessitant un temps d’arrêt.

Capture d'écran de Mise à l'échelle élastique dans Azure PostgreSQL.

  1. Mettre à l’échelle des serveurs de base de données PostgreSQL en quelques secondes.
  2. La passerelle qui agit en tant que proxy pour router le client se connecte au serveur de base de données approprié.
  3. La montée en puissance du stockage peut être effectuée sans temps d’arrêt. Le stockage étendu permet d’effectuer rapidement les opérations de détachement/rattachement après le basculement. Voici quelques scénarios de maintenance planifiée :
Scénario Description
Mise à l’échelle du calcul Quand l’utilisateur effectue une opération de mise à l’échelle du calcul, un nouveau serveur de base de données est approvisionné à l’aide de la configuration de calcul mise à l’échelle. Sur l’ancien serveur de base de données, les points de contrôle actifs sont autorisés à cesser d’opérer, les connexions clientes sont vidées, toutes les transactions non validées sont annulées, puis le serveur est arrêté. Le stockage est ensuite détaché de l’ancien serveur de base de données et attaché au nouveau. Quand l’application cliente retente la connexion ou tente d’établir une nouvelle connexion, la passerelle dirige la demande de connexion vers le nouveau serveur de base de données.
Augmentation du stockage L’augmentation du stockage est une opération en ligne qui n’interrompt pas le serveur de base de données.
Déploiement de nouveaux logiciels (Azure) Le déploiement de nouvelles fonctionnalités ou la corrections de bogues se produisent automatiquement dans le cadre de la maintenance planifiée du service. Pour plus d’informations, consultez la documentation et visitez votre portail.
Mises à niveau de version secondaire Le service Azure Database pour PostgreSQL opère automatiquement la mise à niveau des serveurs de base de données vers la version mineure déterminée par Azure. Cela se produit dans le cadre de la maintenance planifiée du service. L’opération entraîne un bref temps d’arrêt de quelques secondes, et le serveur de base de données est automatiquement redémarré avec la nouvelle version mineure. Pour plus d’informations, consultez la documentation et visitez votre portail.

Réduction des temps d’arrêt non planifiés

Des temps d’arrêt non planifiés peuvent se produire suite à des défaillances imprévues telles qu’un échec matériel sous-jacent, des problèmes de mise en réseau et des bogues logiciels. Si le serveur de base de données tombe en panne de façon inattendue, un nouveau serveur de base de données est automatiquement approvisionné en quelques secondes. Le stockage étendu est automatiquement attaché au nouveau serveur de base de données. Le moteur PostgreSQL effectue l’opération de récupération à l’aide des fichiers WAL et de base de données, puis ouvre le serveur de base de données pour permettre aux clients de se connecter. Les transactions non validées sont perdues et doivent être retentées par l’application. Bien qu’il ne soit pas possible d’éviter un temps d’arrêt non planifié, le service Azure Database pour PostgreSQL réduit les temps d’arrêt en effectuant automatiquement des opérations de récupération au niveau du serveur de base de données et des couches de stockage, sans intervention humaine.

Capture d'écran de la haute disponibilité dans Azure PostgreSQL.

  1. Serveurs Azure PostgreSQL avec fonctionnalités de mise à l’échelle rapide.
  2. Passerelle faisant office de proxy pour router les connexions client vers le serveur de base de données approprié.
  3. Stockage Azure avec trois copies pour la fiabilité, la disponibilité et la redondance.
  4. Le stockage étendu permet également d’effectuer rapidement les opérations de détachement/rattachement après le basculement du serveur.

Temps d’arrêt non planifié : scénarios d’échec et récupération du service

Voici quelques scénarios d’échec et comment le service Azure Database pour PostgreSQL récupère automatiquement :

Scénario Récupération automatique
Panne du serveur de base de données En cas d’arrêt du serveur de base de données en raison d’une erreur matérielle sous-jacente, les connexions actives sont abandonnées et toutes les transactions en cours interrompues. Un nouveau serveur de base de données est déployé automatiquement, et le stockage de données étendu est attaché au nouveau serveur de base de données. Une fois la récupération de la base de données terminée, les clients peuvent se connecter au nouveau serveur de base de données via la passerelle.

Le temps de récupération (RTO) dépend de différents facteurs, dont l’activité au moment de l’erreur, telle qu’une transaction de grande ampleur, et le volume de la récupération à effectuer pendant le processus de démarrage du serveur de base de données.

Des applications utilisant les bases de données PostgreSQL doivent être créées de manière à détecter et à retenter les connexions abandonnées et les transactions ayant échoué. Quand l’application effectue une nouvelle tentative, la passerelle redirige en toute transparence la connexion vers le serveur de base de données nouvellement créé.
Échec de stockage Les applications ne détectent aucun impact des problèmes liés au stockage, tels qu’une défaillance de disque ou une corruption de bloc physique. Les données étant stockées dans trois copies, leur copie est servie par le stockage survivant. Les altérations de bloc sont corrigées automatiquement. En cas de perte d’une copie des données, une nouvelle est automatiquement créée.
Défaillance du calcul Les échecs de calcul sont rares. En cas de défaillance d'un calculateur, un nouveau conteneur de calcul est provisionné et le stockage des fichiers de données y est mappé, le moteur de base de données PostgreSQL est alors mis en ligne sur le nouveau conteneur et le service de passerelle assure un basculement transparent sans qu'il soit nécessaire de modifier l'application. Notez également que la couche de calcul a intégré la résilience de la zone de disponibilité et qu’un nouveau calcul est généré dans une zone de disponibilité différente en cas d’échec de calcul AZ.

Voici quelques scénarios d’échec qui nécessitent une action de l’utilisateur pour la récupération :

Scénario Plan de récupération
Panne de région Une défaillance de région est un événement rare. Toutefois, si vous avez besoin d’une protection contre une défaillance de région, vous pouvez configurer un ou plusieurs réplicas en lecture dans d’autres régions à des fins de récupération d’urgence (pour plus d’informations, consultez cet article sur la création et la gestion des réplicas en lecture). En cas de défaillance au niveau d’une région, vous pouvez promouvoir manuellement le réplica en lecture configuré sur l’autre région comme serveur de base de données de production.
Défaillance de zone de disponibilité L’échec d’une zone de disponibilité est également un événement rare. Toutefois, si vous avez besoin d’une protection contre un échec de zone de disponibilité, vous pouvez configurer un ou plusieurs réplicas de lecture ou envisager d’utiliser notre offre Serveur flexible qui fournit une haute disponibilité redondante dans une zone.
Erreurs logiques/de l’utilisateur La récupération d’erreurs de l’utilisateur, telles qu’une suppression accidentelle de tables ou une mise à jour incorrecte de données, implique l’exécution d’une récupération jusqu’à une date et heure (PITR), en restaurant et récupérant les données jusqu’au moment où l’erreur s’est produite.

Si vous ne souhaitez restaurer qu’un sous-ensemble de bases de données ou de tables spécifiques plutôt que toutes les bases de données du serveur de base de données, vous pouvez restaurer celui-ci dans une nouvelle instance, exporter les tables via l’utilitaire pg_dump, puis vous servir de l’utilitaire pg_restore pour restaurer ces tables dans votre base de données.

Résumé

Le service Azure Database pour PostgreSQL offre une fonctionnalité de redémarrage rapide des serveurs de base de données, un stockage redondant et un routage efficace à partir de la passerelle. Pour renforcer la protection des données, vous pouvez configurer des sauvegardes à géo-répliquer et déployer un ou plusieurs réplicas en lecture dans d’autres régions. Avec ses fonctionnalités de haute disponibilité intégrées, Azure Database pour PostgreSQL protège vos bases de données contre les pannes les plus courantes, et offre un contrat de niveau de service de 99,99 % de temps d’activité adossé à une garantie financière. Toutes ces fonctionnalités de disponibilité et de fiabilité permettent à Azure d’être la plateforme idéale pour l’exécution de vos applications stratégiques.

Étapes suivantes