Problèmes liés à une utilisation élevée du disque

Cette page décrit les problèmes connus liés à une utilisation élevée du disque et propose une aide pour la résolution des problèmes.

Voici les problèmes connus liés à une utilisation élevée du disque :

• Utilisation élevée des fichiers Temporary_files dans MySQL 8.0 et versions ultérieures.
• Utilisation élevée des fichiers Others dans MySQL 8.0 et versions antérieures.

La consommation de fichiers temporaires est classée dans les fichiers tmp_data dans les versions antérieures à MySQL 8.0.

Métrique de répartition du stockage MySQL

La métrique principale utilisée pour surveiller l'utilisation détaillée du disque est cloudsql.googleapis.com/database/disk/bytes_used_by_data_type. Cette métrique fournit une répartition de l'utilisation du disque de l'instance par type de données, comme suit :

Type de données	Définition
Binlog	Stockage utilisé par les journaux binaires MySQL, essentiels pour la récupération à un moment précis et la réplication.
Cloudsql_mysql_audit_log	Stockage utilisé par le journal d'audit Cloud SQL MySQL.
Data	Inclut les espaces de table InnoDB principaux (fichiers .ibd) et l'espace de table système (ibdata1).
General_log	Stockage utilisé par le journal de requêtes général.
General_tablespace	Stockage utilisé par l'espace de table système InnoDB, composé des fichiers ibdata*.
Last_sys_tablespace	Stockage utilisé par le dernier espace de table.
Others	Inclut les fichiers système internes.
Redo_log	Stockage consommé par les journaux de restauration InnoDB utilisés pour la récupération après plantage.
Relaylog	Stockage utilisé par les journaux de relais sur une instance répliquée lors de la réplication.
Slow_log	Stockage utilisé par le journal de requêtes lentes s'il est activé et stocké sur le disque.
Temporary files	Stockage explicitement suivi pour les fichiers temporaires créés par MySQL.
Temporary_space	Stockage utilisé par les fichiers temporaires du système d'exploitation dans le répertoire /tmp.
Tmp_data	Données temporaires créées par MySQL lors d'opérations telles que le tri et la jointure.
Undo_log	Stockage utilisé par les journaux d'annulation.

Localiser les fichiers dans les catégories Temporary_files et Others

Les requêtes de longue durée (telles que les opérations JOIN, ORDER BY ou GROUP BY complexes) créent des fichiers temporaires volumineux dans le répertoire MySQL.

Pour les instances MySQL utilisant des versions de maintenance publiées à partir d'avril 2026, ces fichiers temporaires sont explicitement signalés dans la catégorie Temporary_files.

Dans les versions antérieures, les fichiers temporaires sont signalés dans la catégorie Others.

Remarque : La création de rapports Temporary_files précis pour MySQL 8.0 a été introduite pour la première fois dans la version r20260320.00_00. Vous pouvez vérifier la version de maintenance dans la Google Cloud console, sur la page Présentation de l'instance Cloud SQL, dans la section Maintenance.

Résoudre les problèmes liés à une utilisation élevée du disque

Pour résoudre les problèmes liés à une utilisation élevée du disque causée par des fichiers temporaires volumineux, procédez comme suit :

1. Identifiez les requêtes actives de longue durée.
2. Atténuation immédiate.
3. Utilisez les insights sur les requêtes.
4. Effectuez une analyse rétrospective.
5. Optimisez les requêtes.
6. Configurez la surveillance et les alertes.

Identifier les requêtes actives de longue durée

Les problèmes liés à une utilisation élevée du disque sont le plus souvent causés par des requêtes de longue durée (telles que les opérations JOIN, ORDER BY ou GROUP BY complexes) qui créent des fichiers temporaires volumineux dans le répertoire MySQL. Ces fichiers temporaires sont classés dans les catégories Temporary_files ou Others.

Les instances MySQL avec de nouvelles versions de maintenance (version r20260320.00_00 et versions ultérieures) comportent la table INFORMATION_SCHEMA.CLOUDSQL_OPEN_TEMP_FILES, qui affiche les fichiers temporaires créés par les requêtes de longue durée et qui sont dissociés (c'est-à-dire que les fichiers existent, mais ne sont pas liés au processus MySQL) par MySQL.

Remarque : Les tables temporaires explicites, c'est-à-dire les tables créées manuellement à l'aide de la commande CREATE TEMPORARY TABLE sont gérées dans l'espace de table temporaire InnoDB et ne sont pas capturées dans la table INFORMATION_SCHEMA.CLOUDSQL_OPEN_TEMP_FILES.

Utilisez la requête suivante pour obtenir la requête active de longue durée :

SELECT
otf.fd, otf.size, p.id, p.info, p.user
FROM
 INFORMATION_SCHEMA.CLOUDSQL_OPEN_TEMP_FILES otf
LEFT JOIN
performance_schema.processlist p
ON
otf.SESSION_ID = p.ID;

Exemple de résultat :

+----+------------+------+----------------------------------+------+
| fd | size       | id   | info                             | user |
+----+------------+------+----------------------------------+------+
| 39 | 1670750208 |    8 | select * from t1 order by rand() | root |
| 40 | 1670750208 |    8 | select * from t1 order by rand() | root |
+----+------------+------+----------------------------------+------+
2 rows in set (0.00 sec)

Pour les instances avec les versions de maintenance r20260320.00_00 et antérieures, utilisez la requête suivante pour obtenir la requête active de longue durée :

SHOW FULL PROCESSLIST;

Dans le résultat, recherchez les opérations qui utilisent généralement des fichiers temporaires sur disque :

• Opérations JOIN volumineuses, en particulier sans index appropriés.
• Opérations ORDER BY ou GROUP BY complexes sur des ensembles de résultats volumineux.
• Opérations ALTER TABLE volumineuses.

Atténuation immédiate

Si une requête en cours d'exécution est identifiée comme la source de la consommation de disque lors de l'enquête, vous pouvez l'arrêter pour libérer l'espace de fichier temporaire associé.

Pour arrêter la requête, exécutez la commande suivante :

KILL PROCESS_ID;

Remplacez PROCESS_ID par l'ID de processus de la requête :

• Pour les versions de maintenance r20260320 ou ultérieures, vous pouvez récupérer la PROCESS_ID valeur via la SESSION_ID colonne de la INFORMATION_SCHEMA.CLOUDSQL_OPEN_TEMP_FILES table.

• Pour les versions antérieures (version r20260117 ou antérieure) , vous pouvez récupérer la PROCESS_ID valeur à partir du résultat de l'SHOW FULL PROCESSLIST opération.

Une fois qu'une requête responsable d'une consommation de disque élevée via des fichiers temporaires est arrêtée, l'enregistrement de ces modifications dans les métriques d'utilisation du disque peut prendre jusqu'à cinq minutes environ.

Utiliser les insights sur les requêtes

Nous vous recommandons d'utiliser les insights sur les requêtes pour identifier et affiner les requêtes lentes.

Pour en savoir plus, consultez la page Utiliser Insights sur les requêtes pour améliorer les performances des requêtes.

Effectuer une analyse rétrospective

Une fois le pic d'utilisation passé, vous pouvez analyser les données historiques pour identifier la cause à l'aide des éléments suivants :

• Insights sur les requêtes. Recherchez les requêtes qui ont pu créer des fichiers temporaires volumineux. Examinez les requêtes listées par récapitulatif des requêtes (y compris les métriques telles que la durée moyenne d'exécution, le nombre de requêtes et le nombre moyen de lignes analysées et renvoyées).

• Slow_log. Activez Slow_log et définissez long_query_time sur un seuil approprié. Ce journal capture les requêtes de longue durée à des fins d'analyse et d'optimisation.

• General_log. Vérifiez General_log (s'il est activé) pour les requêtes enregistrées pendant la fenêtre d'incident qui comportent des opérations JOIN ou SORT susceptibles d'avoir généré des fichiers temporaires volumineux. Sinon, vous pouvez activer General_log et capturer la requête lors du prochain événement de ce type.

  Remarque : L'activation de ce journal peut avoir un impact rapide sur les performances et le stockage en raison de sa verbosité.

• Métriques Cloud Monitoring Examinez les métriques suivantes :

  • cloudsql.googleapis.com/database/mysql/tmp_disk_tables_created_count: suit le nombre de tables temporaires créées sur le disque, qui sont souvent à l'origine de fichiers volumineux non liés.
  • cloudsql.googleapis.com/database/mysql/handler_operations_count: suit l'augmentation du nombre d'opérations à ce moment-là.
  • cloudsql.googleapis.com/database/mysql/innodb/active_trx_total_time: suit les transactions actives pendant une période plus longue.

  Une augmentation de ces métriques coïncidant avec le pic d'utilisation du disque suggère fortement que les requêtes générant des tables temporaires volumineuses en sont la cause principale.

• Historique des transactions. Examinez les métriques suivantes :

  • cloudsql.googleapis.com/database/mysql/innodb/history_list_length metric: une longueur de liste d'historique élevée peut être causée par des transactions de longue durée bloquant la purge des journaux d'annulation, ce qui peut également contribuer à des problèmes d'utilisation du disque.
  • cloudsql.googleapis.com/database/mysql/innodb/active_trx_longest_time: transactions de longue durée pendant la période d'utilisation élevée du disque.

Optimiser les requêtes

Une fois que l'analyse des journaux a identifié les requêtes spécifiques à l'origine des pics de métriques, vous pouvez les optimiser ou les réécrire pour minimiser la génération de fichiers temporaires volumineux.

Pour optimiser une requête, vous pouvez procéder comme suit :

• Ajoutez des index appropriés.
• Refactorisez les jointures complexes ou les opérations de tri.

Pour en savoir plus, consultez la section Ajustement des requêtes.

Configurer la surveillance et les alertes

Pour éviter de futurs incidents causés par une utilisation incontrôlée du disque, en particulier en raison de fichiers temporaires générés par des requêtes de longue durée, mettez en œuvre une surveillance et des alertes proactives à l'aide de Monitoring.

Vous pouvez créer des alertes pour les métriques qui indiquent une consommation élevée de ressources ou des modèles de requêtes connus pour générer des fichiers temporaires volumineux.

Nom de la métrique	Description	Seuil d'alerte recommandé
cloudsql.googleapis.com/database/disk/utilization	Pourcentage d'espace disque alloué utilisé. Cette métrique surveille l'utilisation globale de la capacité du disque.	> 80% (soutenu sur 5 minutes)
cloudsql.googleapis.com/database/disk/bytes_used	Nombre total d'octets d'espace disque utilisés par l'instance de base de données. Cette métrique suit la croissance absolue de la consommation de disque.	Surveillez la métrique database/disk/quota.

Pour savoir comment configurer des alertes et une surveillance pour les métriques Cloud SQL, consultez la présentation des alertes et la section Surveiller les instances Cloud SQL.