Surveiller et configurer un serveur de base de données
Lorsqu’une société a migré ses bases de données locales vers Azure Database pour MySQL/PostgreSQL, elle a toujours besoin d’une méthode pour surveiller leurs performances.
En tant que développeur de base de données, vous utilisez des outils spécifiques aux bases de données et la surveillance des machines virtuelles locales. Maintenant que vos bases de données s’exécutent sur Azure, vous pouvez tirer parti du portail pour n’utiliser qu’un seul outil pour surveiller toutes les différentes bases de données.
Dans cette leçon, vous allez découvrir comment Azure Monitor peut vous aider à surveiller l’intégrité des bases de données dont vous êtes responsable. Après avoir découvert les problèmes, vous verrez comment modifier la configuration de vos bases de données pour les résoudre.
Comment utiliser Azure Monitor pour afficher l’intégrité de vos bases de données
Utilisez Azure Monitor pour suivre l’utilisation des ressources dans Azure Database pour MySQL/PostgreSQL. La page Métriques de votre serveur dans le portail Azure vous permet de créer des graphiques afin de dégager des tendances de performances et de repérer les anomalies.
Métriques pour Azure Database pour MySQL/PostgreSQL
Les métriques disponibles pour la surveillance d’un serveur sont réparties dans quatre grandes catégories :
- Métriques de stockage
- Métriques de connexion
- Métriques d’utilisation des ressources de traitement des données
- Métriques de réplication
Métriques de stockage
Les métriques de stockage suivent la taille totale de vos bases de données sur le serveur (Stockage utilisé) et la quantité d’espace de stockage actuelle sur le serveur (Limite de stockage). Dans un système actif, vous constaterez probablement que la métrique Stockage utilisé augmente au fil du temps. Si vous avez sélectionné l’option de croissance automatique pour le serveur, la métrique Limite de stockage augmente parfois à mesure que la quantité d’espace libre diminue. Du stockage supplémentaire est ajouté chaque fois que la quantité d’espace libre descend en dessous de 5 % de l’utilisation actuelle. Utilisez la métrique Pourcentage de stockage pour afficher la proportion d’espace utilisé afin de libérer de l’espace sur votre serveur.
Si votre serveur augmente régulièrement le stockage, envisagez d’attribuer plus d’espace manuellement. Pour ce faire, dans le portail Azure, sélectionnez la page Niveau tarifaire de votre serveur, puis utilisez le curseur Stockage. N’oubliez pas que vous êtes facturé pour le stockage. Ne définissez donc pas le stockage disponible sur une valeur trop élevée.
La métrique Stockage de sauvegarde utilisé indique l’espace occupé par vos sauvegardes. Cette métrique est importante en termes de coût. Vous n’êtes pas facturé pour le stockage de sauvegarde, à condition qu’il reste inférieur à la taille de l’espace de stockage alloué à votre serveur (comme spécifié par le niveau tarifaire). Si vous dépassez cette limite, vous encourrez des frais pour le stockage de sauvegarde.
Métriques de connexion
La métrique Connexions actives indique le nombre de connexions simultanées actuellement prises en charge par le serveur. Elle peut être différente du nombre d’utilisateurs simultanés, selon que vous avez configuré un type de regroupement de connexions ou non. Azure Database pour MySQL/PostgreSQL ne fournit actuellement aucune fonctionnalité de regroupement de connexions, mais vous pouvez utiliser un service proxy tel que PgBouncer* (pour PostgreSQL) pour implémenter cette fonctionnalité. Pour plus d’informations, consultez Meilleures pratiques en matière de performances d’utilisation d’Azure Database pour PostgreSQL – Regroupement de connexions
La métrique Échecs de connexion indique la fréquence à laquelle les utilisateurs ont présenté des informations d’identification non valides. Un grand nombre de ces événements sur une courte période peut indiquer une attaque par force brute.
Métriques d’utilisation des ressources de traitement des données
Ces métriques vous permettent de surveiller comment votre serveur gère la charge de travail.
La métrique Pourcentage d’UC indique l’activité de l’UC. Une utilisation élevée de l’UC n’est pas un problème, sauf si elle augmente au fil du temps. Une utilisation de l’UC supérieure à 90 % et qui augmente encore indique que votre système atteint sa capacité de traitement. Vous devez envisager une mise à l’échelle vers un niveau tarifaire avec plus de ressources.
La métrique Pourcentage de mémoire indique l’occupation de la mémoire. Azure Database pour MySQL/PostgreSQL utilise la mémoire pour mettre en cache les données et pour exécuter les processus lancés par chaque requête client. Une utilisation élevée de la mémoire n’est pas un problème tant qu’elle n’est pas excessive, généralement de plus de 95 %, en fonction de la quantité réelle de mémoire disponible. Une très faible disponibilité de la mémoire peut provoquer des échecs de connexion et ralentir les performances en raison de la fragmentation de la mémoire. Vous devez surveiller cette métrique pour déterminer si l’occupation de la mémoire augmente dans le temps et mettre à l’échelle votre serveur en conséquence.
La métrique Pourcentage d’E/S suit la quantité d’activité du disque effectuée par le serveur. Idéalement, cette valeur doit être aussi faible que possible. L’E/S de disque est une opération lente. Une valeur élevée pour cette métrique, associée à une valeur élevée de Pourcentage de mémoire, peut indiquer que le serveur ne dispose pas de ressources suffisantes pour mettre en cache les données efficacement et qu’il doit plutôt lire et écrire des données sur le stockage sur disque. Un degré d’activité d’E/S est inévitable, car vos données doivent être conservées sur le disque à un moment donné et les journaux des transactions doivent être conservés. Dans la plupart des serveurs de bases de données, cette écriture est effectuée par un processus ou un thread distinct qui s’exécute de manière asynchrone.
Les métriques Réseau entrant et Réseau sortant indiquent le volume de trafic entrant et sortant du serveur sur les connexions actives. Ces données sont limitées par la bande passante du chemin entre les applications clientes et le serveur.
Métriques de réplication
Azure Database pour PostgreSQL fournit les métriques Décalage maximal entre les réplicas et Décalage de réplica pour vous aider à déterminer comment les réplicas doivent être mis à jour. Ces métriques ne sont utiles que si vous avez configuré des réplicas en lecture seule.
La métrique Décalage maximal entre les réplicas indique le nombre d’octets du réplica le plus lent derrière le maître. Vous ne pouvez surveiller cette métrique qu’à partir du maître.
La métrique Décalage de réplica indique la durée, en secondes, depuis la réception de la dernière transaction du maître et son application à un réplica. Cette métrique n’est utile que si elle est consultée sur un réplica.
Azure Database pour MySQL comprend la métrique Décalage de la réplication en secondes. Cette métrique, que vous ne pouvez surveiller qu’à partir d’un réplica, indique le nombre de secondes de décalage du réplica par rapport au maître.
Créer des graphiques et des alertes pour surveiller les performances
La page Métriques d’un serveur dans le portail Azure vous permet de créer des graphiques de suivi des valeurs de métrique. Les métriques sont collectées toutes les minutes. Pour chaque métrique, vous spécifiez une agrégation qui détermine comment rapporter cette métrique.
- Moyenne génère une valeur moyenne pour la métrique à chaque minute
- Max indique la valeur maximale obtenue au cours de chaque minute
- Min indique la plus petite valeur
- Somme calcule le total de la métrique
- Nombre indique le nombre de fois où l’événement générant la métrique s’est produit
Toutes les agrégations ne sont pas nécessairement utiles pour chaque métrique.
L’exemple de graphique ci-dessous capture les valeurs moyennes minute par minute des métriques de pourcentage d’UC, pourcentage de mémoire, pourcentage d’E/S et de connexions actives. Vous constatez que 101 connexions actives s’exécutent simultanément. L’utilisation de l’UC et de la mémoire sont stables et le pourcentage d’E/S est égal à 0. Dans cet exemple, les applications clientes exécutent des charges de travail de lectures intensives et les données nécessaires sont mises en cache en mémoire.
Notez qu’il peut y avoir un décalage pouvant aller jusqu’à cinq minutes entre la capture des métriques et l’affichage des résultats sur un graphique.
Si une métrique indique qu’une ressource atteint un point critique, vous pouvez définir une alerte pour en informer un administrateur. L’exemple ci-dessous envoie un e-mail à un administrateur si l’utilisation de la mémoire dépasse 90 %.
Configurer les paramètres du serveur
Les serveurs MySQL et PostgreSQL natifs sont hautement configurables, car ils utilisent tous les deux des paramètres de configuration stockés dans des fichiers de paramètres. Pour PostgreSQL, ces informations sont conservées dans le fichier postgresql.conf. Pour MySQL, les données de configuration sont stockées dans différents fichiers my.cnf. Dans Azure Database pour MySQL/PostgreSQL, vous ne disposez pas d’un accès direct à ces fichiers. Au lieu de cela, vous affichez et modifiez les paramètres du serveur à l’aide du portail Azure ou d’Azure CLI.
Afficher et définir des paramètres à l’aide du portail Azure
Les paramètres de configuration du serveur sont disponibles sur la page Paramètres du serveur de votre serveur dans le portail Azure. Vous pouvez modifier les valeurs des paramètres en fonction de votre serveur. L’image ci-dessous montre la page des paramètres du serveur pour Azure Database pour PostgreSQL. La page correspondante pour Azure Database pour MySQL est similaire.
Tous les paramètres de configuration du serveur ne sont pas disponibles, car une grande partie de la configuration du serveur est contrôlée par Azure. Par exemple, les paramètres associés à l’allocation de mémoire sont manquants. De plus, Azure Database pour MySQL ne prend pas en charge le stockage ISAML Les paramètres myisam ne figurent donc pas.
Les modifications apportées aux paramètres dits dynamiques prennent effet immédiatement. Les paramètres dits statiques nécessitent un redémarrage du serveur. Vous pouvez le faire sur la page Vue d’ensemble de votre serveur.
Afficher et définir des paramètres à l’aide d’Azure CLI
Vous pouvez afficher et modifier des paramètres par programmation à l’aide des commande az mysql/postgres server configuration. Affichez les réglages de chaque paramètre de configuration avec az mysql/postgres server configuration list, et accédez à un paramètre à l’aide de az mysql/postgres server configuration show [parameter-name]. L’extrait de code ci-dessous montre un exemple pour Azure Database pour PostgreSQL :
az postgres server configuration show \
--resource-group northwindrg \
--server-name northwind101 \
--name vacuum_defer_cleanup_age
Le résultat doit ressembler à ceci :
{
"allowedValues": "0-1000000",
"dataType": "Integer",
"defaultValue": "0",
"description": "Number of transactions by which VACUUM and HOT cleanup should be deferred, if any.",
"id": "**********************",
"name": "vacuum_defer_cleanup_age",
"resourceGroup": "northwindrg",
"source": "system-default",
"type": "Microsoft.DBforPostgreSQL/servers/configurations",
"value": "0"
}
L’élément important dans la sortie est le champ valeur, qui indique le réglage actuel du paramètre.
Utilisez la commande az mysql/postgres server configuration set pour modifier la valeur d’un paramètre de configuration, comme suit :
az postgres server configuration set \
--resource-group northwindrg \
--server-name northwind101 \
--name vacuum_defer_cleanup_age \
--value 5
Si vous devez redémarrer un serveur après avoir modifié un paramètre statique, exécutez la commande az mysql/postgres server restart :
az postgres server restart \
--resource-group northwindrg \
--name northwind101