Augmentation rapide du stockage de la base de données

Question

Augmentation rapide du stockage de la base de données

Julien HÉGO 0

Bonjour,

J'ai actuellement une base de données flexible qui subit une forte augmentation du stockage. Cela crée une indisponibilité sans raison apparente.
Le serveur est configuré sur Postgresql 16.

J'ai essayé de changer les paramètres pour obtenir de meilleurs journaux, mais j'obtiens une erreur dûe au paramètre "azure.allow_hostname_in_username" qui n'existe pas.

Merci d'avance pour votre aide.

Image de l’utilisateur

1 réponse

Votre réponse

Answer 1

Pratyush Vashistha 4,570 Personnel externe Microsoft Modérateur

Bonjour Julien HÉGO

Merci d'avoir contacté Microsoft QnA ! concernant la croissance inattendue de l'espace de stockage sur votre serveur Azure Database pour PostgreSQL. D'après notre expérience, l'utilisation du stockage peut augmenter en raison de plusieurs facteurs autres que la taille réelle de la base de données, tels que :

• Journaux de transactions (fichiers WAL) – Si les fichiers WAL ne sont pas archivés ou nettoyés correctement, ils peuvent s'accumuler et consommer un espace important.

• Tuples morts et paramètres d'autovacuum – Des configurations d'autovacuum inefficaces peuvent empêcher la récupération de lignes obsolètes.

• Gonflement des tables et des index – Les mises à jour et suppressions fréquentes peuvent entraîner une surcharge de stockage.

• Fichiers et journaux temporaires – Les requêtes volumineuses ou les journaux de débogage peuvent occuper de l'espace supplémentaire.

• Modifications du niveau de calcul – Le passage d'un mode extensible à un mode à usage général peut influencer le comportement du stockage en raison de caractéristiques de mise en cache et de performances différentes.

Informations complémentaires issues d'un cas réel : (https://learn.microsoft.com/en-us/answers/questions/2284624/why-is-storage-usage-increasing-consistently-and-o)

• Lorsque le client a basculé le niveau de base de données de « Extensible » à « Usage général », la base de données était fortement sollicitée (utilisation du processeur à 100 %).

• De ce fait, le jeton SAAS, un jeton d'authentification interne utilisé par Microsoft pour PostgreSQL, n'a pas été actualisé correctement.

• Comme le jeton n'a pas été actualisé, le système a enregistré les fichiers WAL (Write-Ahead Logging) en arrière-plan. Normalement, ces fichiers sont gérés automatiquement, mais l'échec de l'actualisation du jeton a empêché le nettoyage.

• Par conséquent, environ 100 Go de fichiers WAL se sont accumulés en quelques semaines.

Solution fournie par le support Microsoft :

• Effacement de tous les fichiers WAL accumulés.

• Actualisation manuelle du jeton SAAS.

Ce problème ne peut pas être résolu directement par les clients ; vous pouvez créer un ticket d'assistance à ce sujet.

Pour plus de détails et de bonnes pratiques, veuillez consulter cet article Microsoft :

https://learn.microsoft.com/en-us/answers/questions/2069089/disk-space-error-and-temp-files-management-in-azur

https://techcommunity.microsoft.com/blog/azuredbsupport/learning-from-expertise-7-where-is-my-server-storage-taken---azure-postgresql/3032964

J'espère que cela vous aidera à identifier la cause du problème et à prendre les mesures appropriées. Si vous avez besoin d'aide ou de conseils supplémentaires pour optimiser le stockage, n'hésitez pas à nous contacter. Ce fil de discussion étant en français, veuillez excuser ma grammaire, car j'utilise la fonction de traduction pour y répondre.

Veuillez accepter la réponse si elle est utile, afin d'aider les autres membres de la communauté à résoudre des problèmes similaires.

Merci

Pratyush

Julien HÉGO 0 Points de réputation

2025-08-21T08:03:54.33+00:00

Bonjour Pratyush Vashistha,

Tout d'abord, je vous remercies pour votre réponse.

Cependant, il y a très peu de changement, d'ajout ou de suppression de données dans la base.

La charge de stockage, qui double (voir même plus, étant donné la limitation de l'espace complet) est sans raison apparente.

J'ai essayé de changer les paramètres pour obtenir de meilleurs journaux, mais j'obtiens une erreur dûe au paramètre "azure.allow_hostname_in_username" qui n'existe pas.
Pratyush Vashistha 4,570 Points de réputation Personnel externe Microsoft Modérateur

2025-08-21T08:46:14.18+00:00
Bonjour Julien HÉGO

Merci pour votre réponse rapide !

Pouvez-vous confirmer que vous utilisez bien Azure Database pour PostgreSQL - Serveur flexible et non Serveur unique (car certains paramètres diffèrent entre les deux) ?

Le paramètre serveur azure.allow_hostname_in_username est uniquement disponible pour Azure Database pour PostgreSQL - Serveur unique. Il n'existe pas sur Serveur flexible.

La documentation officielle de Serveur flexible concernant les paramètres serveur ne mentionne pas azure.allow_hostname_in_username.

Doc d'apprentissage : https://learn.microsoft.com/en-us/azure/postgresql/flexible-server/how-to-server-parameters-list-all?tabs=portal-list

Sur un serveur unique, les noms d'utilisateur étaient au format nom_utilisateur@nom_serveur. Sur un serveur flexible, la connexion se fait uniquement avec le nom d'utilisateur, conformément à la norme PostgreSQL. Ce paramètre est donc inutile et a été supprimé.

Voici quelques étapes pour activer la journalisation sur un serveur flexible :

Pour diagnostiquer votre problème de stockage, vous devez journaliser les requêtes lentes ou toutes les requêtes. Voici les paramètres à modifier sur votre serveur flexible :

Accédez à votre ressource Serveur flexible dans le portail Azure.

Dans le menu de gauche, sous « Paramètres », sélectionnez « Paramètres du serveur ». Recherchez et modifiez les paramètres suivants :

log_min_duration_statement: Il s'agit du paramètre le plus important pour votre problème. Définissez-le en millisecondes (par exemple, 5 000 pour 5 secondes) pour enregistrer toutes les requêtes dont la durée d'exécution est supérieure à cette durée. Cela vous permet d'identifier les requêtes inefficaces sans avoir à enregistrer toutes les données.

log_statement: Pour plus de détails, vous pouvez définir cette option sur ddl pour enregistrer toutes les instructions du langage de définition de données (DDL), ou sur all pour enregistrer chaque requête. Attention : définir cette option sur all sur un serveur de production peut générer des journaux volumineux, consommer de l'espace et impacter les performances.

Cliquez sur Enregistrer. Les modifications seront appliquées sans redémarrage du serveur. Vous pouvez consulter les journaux dans le panneau « Journaux du serveur » du portail Azure ou, pour une meilleure analyse, configurer les paramètres de diagnostic afin d'envoyer les journaux à un espace de travail Log Analytics.

Pour vous aider davantage, il serait utile de connaître les réponses à ces questions :

Y a-t-il eu récemment des déploiements d'applications ou des modifications des modèles d'ingestion de données qui correspondent au début de la croissance du stockage ?

Avez-vous vérifié si la croissance automatique du stockage est activée dans la configuration de votre serveur ?

Observez-vous un nombre élevé de tuples morts ou une surcharge dans les vues de surveillance telles que pg_stat_all_tables ? Le stockage peut augmenter considérablement si l'autovacuum ne suit pas le rythme.

Quels paramètres spécifiques avez-vous tenté de modifier pour améliorer la journalisation ? Le paramètre azure.allow_hostname_in_username ne fait pas partie des paramètres du serveur flexible. Avez-vous peut-être trouvé cela dans l'ancienne documentation du serveur unique ?

Avez-vous constaté une variation soudaine de la charge de travail (par exemple, des insertions en masse, des mises à jour/suppressions volumineuses ou des transactions de longue durée) qui pourrait expliquer la croissance des données/du stockage ?

Je suis sûr qu’en suivant ces étapes, vous serez en mesure d’identifier la cause première de la croissance du stockage et de stabiliser votre serveur.

Références:

Configurer les paramètres du serveur pour un serveur flexible

Journalisation dans Azure Database pour PostgreSQL - Serveur flexible

Surveillance dans Azure Database pour PostgreSQL - Serveur flexible

Documentation PostgreSQL sur VACUUM

https://learn.microsoft.com/en-us/azure/postgresql/flexible-server/overview#compare-flexible-server-and-single-server

Veuillez « Accepter comme réponse » si la réponse fournie est utile, afin que vous puissiez aider d'autres membres de la communauté à la recherche d'une solution à des problèmes similaires.

Merci

Pratyush
Julien HÉGO 0 Points de réputation

2025-08-21T09:06:21.6633333+00:00
Pratyush,

En effet, le serveur est bien un "Serveur flexible Azure Database pour PostgreSQL".

Il est cependant issu d'une migration d'un serveur de base de données non flexible (migration automatique d'Azure en octobre 2024).

Il n'y a pas eu de modification de modèles d'ingestion des données. La forte charge d'augmentation du stockage n'est que temporaire (voir le graphique partagé à la première question).

Concernant l'erreur obtenue, je ne cherche pas à ajouter ou modifier le paramètre "azure.allow_hostname_in_username". Par exemple, je viens de tenter de modifier uniquement le paramètre "log_min_duration_statement" à la valeur 5000.

Voici ce que j'ai obtenu :

{ "status": "Failed", "error": { "code": "ResourceDeploymentFailure", "message": "The resource write operation failed to complete successfully, because it reached terminal provisioning state 'Failed'.", "details": [ { "code": "ParameterNotExists", "message": "Server parameter 'azure.allow_hostname_in_username' is invalid or isn't supported in PostgreSQL version '16'." } ] } }
Pratyush Vashistha 4,570 Points de réputation Personnel externe Microsoft Modérateur

2025-08-21T09:36:30.84+00:00

Julien HÉGO,

Merci pour ces informations complémentaires cruciales. Il s'agit d'un scénario très spécifique et important. Le message d'erreur, combiné au fait qu'il s'agit d'un serveur migré, indique directement la cause première.

La cause première semble être une configuration obsolète après la migration. Vous rencontrez un problème d'incohérence d'état.

Voici ce qui s'est passé :

• Votre serveur unique d'origine comportait le paramètre azure.allow_hostname_in_username dans sa configuration.

• Lorsque le service de migration Azure a créé le nouveau serveur flexible, il a migré les données avec succès, mais il semble avoir transféré par erreur une référence « fantôme » ou « obsolète » à cet ancien paramètre, désormais invalide, dans la configuration Azure Resource Manager (ARM) sous-jacente du serveur.

• Votre nouveau serveur flexible lui-même n'utilise ni ne reconnaît ce paramètre. Cependant, l'entrée invalide est désormais bloquée dans sa configuration enregistrée.

• Lorsque vous essayez d'enregistrer une modification de paramètre de serveur (comme log_min_duration_statement), le plan de contrôle Azure tente de valider l'intégralité de la configuration de votre serveur avant d'appliquer la modification. L'entrée azure.allow_hostname_in_username est détectée, la validation échoue et l'opération est rejetée, même si la modification demandée était parfaitement valide.

En résumé, un élément résiduel de l'ancien serveur bloque toute modification de configuration sur le nouveau serveur. Il s'agit d'un cas limite pouvant survenir lors de migrations automatisées. Comme il s'agit d'un problème d'état de configuration du backend, il ne suffit pas de modifier un autre paramètre dans le portail pour le résoudre. La solution la plus fiable consiste à corriger l'état du backend.

Voici les étapes suivantes recommandées, dans l'ordre.

Étape 1 : Vous pouvez essayer de réinitialiser un paramètre via Azure CLI (facile, mais peut fonctionner). Parfois, l'utilisation d'un autre outil, comme Azure CLI, peut interagir avec l'API ARM de manière légèrement différente et corriger l'état non valide. Tout d'abord, assurez-vous qu'Azure CLI est installé et que vous êtes connecté (az login). Ensuite, essayez de définir le paramètre souhaité. bash

Définissez vos variables spécifiques

RESOURCE_GROUP="VotreNomGroupeRessource"SERVER_NAME="VotreNomServeurFlexible »

Essayez de définir le paramètre à l'aide de l'interface de ligne de commande Azure

az postgres flexible-server parameter set --resource-group $RESOURCE_GROUP --nom-serveur $SERVER_NAME --name log_min_duration_statement --value 5000

Si cette commande réussit, le problème est résolu. Si elle échoue avec le même message d'erreur, la configuration obsolète est trop profondément intégrée et vous devez passer à l'étape suivante.

Étape 2 : Ouvrir un ticket de support Microsoft (solution définitive) C'est la solution la plus directe et la plus sûre pour résoudre ce problème. L'équipe de support Azure dispose des outils back-end nécessaires pour inspecter la configuration ARM de la ressource et supprimer manuellement l'entrée de paramètre obsolète et non valide.

• Accédez au portail Azure.

• Accédez à Aide + Support et créez une nouvelle demande de support.

• Type de problème : Technique

• Service : Base de données Azure pour PostgreSQL

• Type de problème : Configuration et paramètres du serveur

• Dans la description, soyez très précis. Fournissez le résumé suivant :

Notre serveur flexible Azure Database pour PostgreSQL a été migré depuis un serveur unique. Nous ne pouvons désormais plus modifier aucun paramètre du serveur. Chaque tentative échoue avec le code d'erreur « ParameterNotExists » pour le paramètre « azure.allow_hostname_in_username », même si nous ne cherchons pas à le modifier. Cela indique qu'une configuration obsolète a été transférée du serveur unique pendant la migration. Veuillez inspecter la configuration ARM du serveur principal et supprimer l'entrée de paramètre non valide.

Une description précise permettra à l'ingénieur support de comprendre immédiatement le problème et de le résoudre rapidement, sans longs échanges.

Veuillez « Accepter comme réponse » si la réponse fournie est utile, afin que vous puissiez aider d'autres membres de la communauté à la recherche d'une solution à des problèmes similaires.

Merci

Pratyush
Pratyush Vashistha 4,570 Points de réputation Personnel externe Microsoft Modérateur

2025-08-25T01:59:45.28+00:00

Bonjour Julien HÉGO,

Je souhaite savoir si vous avez pu consulter ma réponse précédente et si elle vous a été utile. N'hésitez pas à me contacter si vous avez d'autres questions. Veuillez accepter la réponse si elle vous est utile, afin d'aider les autres membres de la communauté à résoudre des problèmes similaires.

Merci et au plaisir de vous aider !

Pratyush
Pratyush Vashistha 4,570 Points de réputation Personnel externe Microsoft Modérateur

2025-08-26T03:19:01.36+00:00

Bonjour Julien HÉGO

Nous n'avons pas eu de vos nouvelles concernant votre dernière réponse et nous vérifions simplement si vous avez trouvé une solution. Si vous avez une solution, n'hésitez pas à la partager avec la communauté ; cela peut être utile. Sinon, nous vous répondrons avec plus de détails et nous ferons tout notre possible pour vous aider.

Merci et au plaisir de vous aider !

Pratyush

Partager via

Augmentation rapide du stockage de la base de données

1 réponse

Votre réponse