Présentation de Azure Database pour PostgreSQL

• 19 minutes

Azure Database pour PostgreSQL est disponible dans les versions multiserveur.

En tant que développeur de base de données ayant passé de nombreuses années à exécuter et gérer des installations PostgreSQL locales, vous souhaitez examiner la capacité d’Azure Database pour PostgreSQL à prendre en charge et mettre à l’échelle ses fonctionnalités.

Dans cette unité, vous allez explorer les tarifs, la prise en charge des versions, la réplication et les options de mise à l’échelle d’Azure Database pour PostgreSQL.

Azure Database pour PostgreSQL

Le service Azure Database pour PostgreSQL est une implémentation de la version Community de PostgreSQL. Le service fournit les fonctionnalités communes utilisées par les systèmes PostgreSQL classiques, notamment la prise en charge spatiale géographique et la recherche en texte intégral.

Microsoft a adapté PostgreSQL pour la plateforme Azure, et il est étroitement intégré à de nombreux services Azure. Le service Azure Database pour PostgreSQL est entièrement géré par Microsoft. Microsoft gère les mises à jour et les correctifs logiciels, et offre une SLA de 99,99 % de disponibilité. Cela signifie que vous pouvez vous concentrer uniquement sur les bases de données et les applications en cours d’exécution, à l’aide du service.

Vous pouvez déployer plusieurs bases de données dans chaque instance de ce service.

Niveaux de tarification

Lorsque vous créez une instance du service Azure Database pour PostgreSQL, vous spécifiez les ressources de calcul et de stockage que vous souhaitez allouer en sélectionnant un niveau tarifaire. Un niveau tarifaire associe le nombre de cœurs de processeurs virtuels, la quantité de stockage disponible et diverses options de sauvegarde. Plus vous allouez de ressources, plus le coût est élevé.

Le service Azure Database pour PostgreSQL utilise le stockage pour stocker les fichiers de base de données, les fichiers temporaires, les journaux de transactions et les journaux du serveur. Vous pouvez éventuellement spécifier que vous souhaitez que le stockage soit augmenté lorsque vous vous approchez de la capacité actuelle. Si vous ne sélectionnez pas cette option, les serveurs qui manquent de stockage continuent de s’exécuter, mais fonctionnent en lecture seule.

Le portail Azure regroupe les niveaux tarifaires en trois grandes catégories :

• De base, idéale pour les environnements de développement et les systèmes de petite taille, mais avec des performances en E/S variables.
• Usage général, qui fournit des performances prévisibles, jusqu’à 6 000 E/S par seconde, en fonction du nombre de cœurs de processeur et de l’espace de stockage disponible.
• Mémoire optimisée, qui utilise jusqu’à 32 cœurs de processeurs virtuels mémoire optimisés, et fournit également des performances prévisibles allant jusqu’à 6 000 E/S par seconde.

Microsoft dispose également d’une option Stockage important en préversion, qui peut approvisionner jusqu’à 16 To de stockage et prendre en charge jusqu’à 20 000 E/S par seconde.

Vous pouvez ajuster le nombre de cœurs de processeur et le stockage dont vous avez besoin. Vous pouvez augmenter ou réduire la taille des ressources de traitement. Vous ne pouvez pas diminuer le stockage, mais uniquement l’augmenter, et basculer entre les niveaux de tarification Usage général et Mémoire optimisée si nécessaire après avoir créé vos bases de données. Vous ne payez que ce dont vous avez besoin.

Le niveau tarifaire et les ressources de traitement allouées déterminent le nombre maximal de connexions simultanées prises en charge par le service. Par exemple, si vous sélectionnez le niveau tarifaire Usage général et allouez 64 cœurs virtuels, le service prend en charge 1 900 connexions simultanées. Le niveau De base, avec deux cœurs virtuels, gère jusqu’à 100 connexions simultanées. Azure lui-même requiert cinq connexions pour surveiller le serveur. Si vous dépassez le nombre de connexions disponibles, les clients recevront l’erreur irrécupérable : désolé, un trop grand nombre de clients sont déjà connectés.

Les prix peuvent varier. Visitez la page Tarification d’Azure Database pour PostgreSQL pour obtenir les informations les plus récentes.

Paramètres de serveur

Dans une installation locale de PostgreSQL, vous définissez les paramètres de configuration du serveur dans le fichier postgreSQL.conf. Utilisez Azure Database pour PostgreSQL pour modifier les paramètres de configuration via la page Paramètres du serveur. Tous les paramètres d’une installation locale de PostgreSQL ne sont pas pertinents pour Azure Database pour PostgreSQL. par conséquent, la page Paramètres du serveur répertorie uniquement les paramètres appropriés à Azure.

Les modifications apportées aux paramètres dits dynamiques prennent effet immédiatement. Les paramètres statiques demandent un redémarrage du serveur. Le redémarrage du serveur se fait à l’aide du bouton Redémarrer depuis la page Vue d’ensemble du portail :

Haute disponibilité

Azure Database pour PostgreSQL est un service hautement disponible. Il contient des mécanismes intégrés de détection des défaillances et de basculement. Si un nœud de traitement est bloqué en raison d’un problème matériel ou logiciel, un nouveau nœud est basculé pour le remplacer. Toutes les connexions qui utilisent actuellement ce nœud sont supprimées, mais automatiquement ouvertes sur le nouveau nœud. Toutes les transactions exécutées par le nœud défaillant seront restaurées. Pour cette raison, vous devez toujours vous assurer que les clients sont configurés pour détecter et retenter les opérations ayant échoué.

Versions de PostgreSQL prises en charge

Le service Azure Database pour PostgreSQL prend actuellement en charge PostgreSQL version 11, et jusqu’à la version 9,5. Vous spécifiez la version de PostgreSQL à utiliser lorsque vous créez une instance du service. Microsoft a l’intention de mettre à jour le service au fur et à mesure que de nouvelles versions de PostgreSQL deviennent disponibles. Microsoft assure la compatibilité avec les deux versions majeures précédentes.

Azure gère automatiquement les mises à niveau de vos bases de données entre les versions mineures de PostgreSQL, mais pas les versions majeures. Par exemple, si vous avez une base de données qui utilise PostgreSQL version 10, Azure peut automatiquement mettre à niveau la base de données vers la version 10.1. Si vous souhaitez basculer vers la version 11, vous devez exporter vos données à partir des bases de données de l’instance de service actuelle, créer une nouvelle instance du service Azure Database pour PostgreSQL et importer vos données dans cette nouvelle instance.

Nœuds coordinateur et Worker

Les données sont partitionnées et distribuées entre les nœuds Worker. Le moteur de requête du coordinateur peut paralléliser les requêtes complexes, en dirigeant le traitement vers les nœuds Worker appropriés. Les nœuds Worker sont sélectionnés en fonction des partitions qui contiennent les données en cours de traitement. Le coordinateur accumule ensuite les résultats des nœuds Worker avant de les renvoyer au client. Des requêtes plus simples peuvent être effectuées à l’aide d’un seul nœud Worker. Les clients se connectent également au coordinateur et ne communiquent jamais directement avec un nœud Worker.

Vous pouvez mettre à l’échelle le nombre de nœuds Worker dans votre service, selon les besoins.

Distribution de données

Vous distribuez des données sur des nœuds Worker en créant des tables distribuées. Une table distribuée est fractionnée en partitions, et chaque partition est allouée au stockage sur un nœud Worker. Vous indiquez comment fractionner les données en définissant une colonne comme colonne de distribution. Les données sont partitionnées en fonction des valeurs des données de cette colonne. Lorsque vous concevez une table distribuée, il est important de sélectionner la colonne de distribution avec soin. Vous devez utiliser une colonne avec un grand nombre de valeurs distinctes qui seraient généralement utilisées pour regrouper des lignes connexes. Par exemple, dans une table pour un système de commerce électronique qui stocke des informations sur les commandes des clients, l’ID du client peut être une colonne de distribution raisonnable. Toutes les commandes pour un client donné sont conservées dans la même partition, mais les commandes de tous les clients sont réparties sur partitions.

Vous pouvez également créer des tables de référence. Ces tables contiennent des données de recherche, telles que les noms des villes ou des codes d’état. Une table de référence est répliquée dans son intégralité sur chaque nœud Worker. Les données d’une table de référence doivent être relativement statiques ; chaque modification nécessite la mise à jour de chaque copie de la table.

Enfin, vous pouvez créer des tables locales. Une table locale n’est pas partitionnée, mais elle est stockée sur le nœud coordinateur. Utilisez des tables locales pour contenir des tables de petite taille avec des données qui ne seront probablement pas requises par les jointures. Les noms des utilisateurs et leurs informations de connexion sont des exemples.

Répliquer des données dans Azure DB pour PostgreSQL

Les réplicas en lecture seule sont utiles pour gérer les charges de travail nécessitant beaucoup de lectures. Les connexions clientes peuvent être réparties entre les réplicas, ce qui simplifie la tâche sur une seule instance du service. Si vos clients se trouvent dans différentes régions du monde, vous utilisez la réplication entre les régions pour positionner les données à proximité de chaque ensemble de clients et réduire la latence.

Vous pouvez également utiliser des réplicas dans le cadre d’un plan d’urgence pour la récupération d’urgence. Si le serveur maître n’est plus disponible, vous pouvez toujours vous connecter à un réplica.

Établissement d’un réplica

Un réplica en lecture seule contient une copie des bases de données contenues dans le serveur d’origine, appelé maître. Vous utilisez le portail Azure ou Azure CLI pour créer un réplica du maître.

Lorsque vous créez un réplica en lecture seule, Azure crée une nouvelle instance du service Azure Database pour PostgreSQL, puis copie les bases de données du serveur maître vers le nouveau serveur. Le réplica s’exécute en mode lecture seule. Toute tentative de modification des données échouera.

Retard du réplica

La réplication n’est pas synchrone et toute modification apportée aux données dans le serveur maître peut prendre un certain temps pour apparaître dans les réplicas. Les applications clientes qui se connectent aux réplicas doivent être en mesure de faire face à ce niveau de cohérence éventuelle. Azure Monitor vous permet de suivre le décalage horaire de la réplication en utilisant le décalage maximal entre les réplicas et les métriques de retard de réplica.

Gestion et surveillance

Vous pouvez utiliser des outils familiers tels que pgAdmin pour vous connecter à Azure Database pour PostgreSQL afin de gérer et de surveiller vos bases de données. Toutefois, certaines fonctionnalités axées sur le serveur, par exemple sa sauvegarde et sa restauration, ne sont pas disponibles, car le serveur est managé et entretenu par Microsoft.

Outils Azure pour la supervision d’Azure Database pour PostgreSQL

Azure fournit un ensemble complet de services qui vous permettent de surveiller les performances des serveurs et des bases de données, et de résoudre les problèmes. Ces services vous permettent de voir comment PostgreSQL utilise les ressources Azure que vous avez allouées. Ces informations vous permettent d’évaluer si vous devez mettre à l’échelle votre système, modifier la structure des tables et des index dans vos bases de données et visualiser les statistiques d’exécution et d’autres événements. Les services disponibles incluent :

• Azure Monitor. La base de données Azure pour PostgreSQL fournit des métriques qui vous permettent de suivre des éléments tels que l’utilisation du processeur et du stockage, les taux d’E/S, l’occupation de la mémoire, le nombre de connexions actives et le décalage de réplication :

  

• Journaux d’activité du serveur. Azure rend les journaux disponibles pour chaque serveur PostgreSQL. Vous les téléchargez à partir du portail Azure :

  

• Magasin des requêtes et Query Performance Insight. Azure Database pour PostgreSQL enregistre des informations relatives aux requêtes exécutées sur les bases de données du serveur, puis les enregistrent dans une base de données nommée azure_sys, selon le schéma query_store. Vous pouvez interroger la vue query_store.qs_view pour afficher les informations. Par défaut, Azure Database pour PostgreSQL ne capture pas d’informations sur les requêtes, car il impose une faible surcharge, mais vous pouvez activer le suivi en définissant la propriété de serveur pg_qs. query_capture_mode sur All ou Top.

  

  Vous configurez également le magasin des requêtes pour capturer des informations sur les requêtes qui consacrent du temps à attendre. Une requête peut être obligée d’attendre qu’une autre requête libère un verrou sur une table, ou parce que la requête effectue un grand nombre d’E/S ou que la quantité de mémoire disponible est faible. Ces informations s’affichent dans la vue query_store. runtime_stats_view.

  Si vous préférez visualiser ces statistiques plutôt que d’exécuter des instructions SQL, utilisez Query Performance Insight dans le portail Azure :

  

• Recommandations sur les performances. L’utilitaire Recommandations sur les performances, également disponible dans le portail Azure, examine les requêtes exécutées par vos applications. Il examine également les structures de la base de données et recommande la manière d’organiser vos données, et indique si vous devez envisager d’ajouter ou de supprimer des index.

Connectivité client

Azure Database pour PostgreSQL s’exécute derrière un pare-feu. Pour accéder à votre service et à votre base de données, vous devez ajouter une règle de pare-feu pour les plages d’adresses IP à partir desquelles vos clients se connectent. Si vous avez besoin d’accéder au service à partir d’Azure (par exemple, une application exécutée à l’aide d’Azure App services), vous devez également activer l’accès aux services Azure.

Configurer le pare-feu

Le moyen le plus simple de configurer le pare-feu est d’utiliser les paramètres Sécurité de la connexion de votre service sur le portail Azure. Ajoutez une règle pour chaque plage d’adresses IP de client. Cette page vous permet aussi d’appliquer des connexions SSL à votre service.

Cliquez sur Ajouter une adresse IP de client dans la barre d’outils pour ajouter l’adresse IP de votre ordinateur de bureau.

Si vous avez configuré des réplicas en lecture seule, vous devez ajouter une règle de pare-feu à chacun d’eux afin de les rendre accessibles aux clients.

Bibliothèques de connexions clientes

Si vous écrivez vos propres applications clientes, vous devez utiliser le pilote de base de données approprié pour vous connecter à une base de données PostgreSQL. La plupart de ces bibliothèques sont dépendantes du langage de programmation. Elles sont gérées par des tiers indépendants. Azure Database pour PostgreSQL prend en charge les bibliothèques clientes pour Python, PHP, Node.js, Java, Ruby, Go, C# (.NET), ODBC, C et C++.

Logique de nouvelle tentative du client

Comme mentionné précédemment, certains événements, tels que le basculement pendant la récupération haute disponibilité et la mise à l’échelle des ressources du processeur, peuvent entraîner une perte de la connectivité. Toutes les transactions en cours sont restaurées. Azure Database pour PostgreSQL redirige automatiquement un client connecté vers un nœud Worker, mais toutes les opérations effectuées par le client à ce moment-là renverront une erreur. Vous devez considérer cette occurrence comme une exception temporaire. Votre code d’application doit être préparé à intercepter ces exceptions et à les réessayer.

Fonctionnalités PostgreSQL dans Azure Database pour PostgreSQL

Azure Database pour PostgreSQL prend en charge la plupart des fonctionnalités couramment utilisées par les bases de données PostgreSQL, mais il existe des exceptions. Si vous avez besoin d’une fonctionnalité non prise en charge, vous devrez peut-être retravailler votre base de données et votre code d’application pour supprimer cette dépendance, ou envisagez d’exécuter PostgreSQL sur une machine virtuelle. Dans ce dernier cas, vous devrez assumer la responsabilité de la gestion et de la maintenance du serveur.

Extensions prises en charge dans Azure Database pour PostgreSQL

La plupart des fonctionnalités PostgreSQL sont encapsulées dans les extensions. Les extensions sont des packages d’objets SQL et de code stockés sur le serveur ; elles peuvent être chargées dans une base de données à l’aide de la commande CREATE EXTENSION. La base de données Azure pour PostgreSQL fournit actuellement de nombreuses extensions couramment utilisées pour :

• Types de données
• Fonctions
• Recherche en texte intégral
• Index (bloom, btree_gist, and btree_gin)
• Langage plpgsql
• PostGIS
• Nombreuses fonctions d’administration

Vous utilisez les packages dblink et postgres_fdw pour connecter un serveur PostgreSQL à un autre, ce qui permet au code d’un serveur d’accéder aux données contenues dans un autre. Dans Azure Database pour PostgreSQL, vous pouvez vous connecter uniquement entre des serveurs créés à l’aide d’Azure Database pour PostgreSQL. Vous ne pouvez pas créer de connexions sortantes vers des serveurs PostgreSQL hébergés ailleurs, par exemple en local ou sur une machine virtuelle.

SELECT * FROM pg_available_extensions;

La base de données Azure pour PostgreSQL comprend la base de données TimescaleDB comme extension facultative. Cette base de données contient des fonctions analytiques orientées temporelles et d’autres fonctionnalités qui prennent en charge les charges de travail de série chronologique. Pour utiliser cette base de données, sélectionnez l’option TIMESCALEDB dans le paramètre shared_preload_libraries Server, puis redémarrez le serveur.

Prise en charge linguistique des procédures stockées et des déclencheurs

La prise en charge de langues autres que plpgsql vous oblige généralement à compiler votre procédure stockée ou votre code de déclencheur séparément, et à charger la bibliothèque compilée sur le serveur. Principalement pour des raisons de sécurité, vous ne pouvez pas le faire avec Azure Database pour PostgreSQL. Si vous avez écrit du code dans d’autres langues, vous devez le porter sur plpgsql.