Solutions to a full instance caused by the general query log - ApsaraDB RDS

Le journal des requêtes générales enregistre chaque instruction SQL exécutée sur votre instance : requêtes, insertions, mises à jour et suppressions. Sur une instance très sollicitée, ce journal peut croître rapidement et provoquer un épuisement de l'espace de stockage, des conflits de verrouillage ainsi qu'un allongement des temps de récupération après incident.

ApsaraDB RDS pour MySQL stocke par défaut le journal des requêtes générales au format TABLE . Les journaux stockés au format FILE ne peuvent pas être interrogés ni téléchargés, car vous n'avez pas d'accès direct au système de fichiers de l'instance. Le paramètre log_output contrôle le format de sortie du journal des requêtes générales et du journal des requêtes lentes. Étant donné que RDS utilise un mécanisme de rotation qui exige le format TABLE pour les journaux des requêtes lentes, le journal des requêtes générales doit également utiliser le format TABLE .

Paramètres de journalisation en bref

Paramètre	Valeur par défaut	Description
`general_log`	`OFF`	Active ou désactive le journal des requêtes générales
`log_output`	`TABLE`	Format de sortie. `TABLE` écrit dans `mysql.general_log` ; `FILE` écrit dans le système de fichiers (téléchargement non pris en charge sur RDS)
`general_log_size` (lecture seule)	—	Métrique de surveillance indiquant la taille actuelle de la table du journal des requêtes générales

Pourquoi le journal des requêtes générales consomme-t-il tout mon espace de stockage ?

Sur une instance à fort trafic, ou dont le journal n'a pas été purgé depuis longtemps, le journal des requêtes générales augmente sans limite. Pour vérifier s'il est en cause, consultez l'utilisation du stockage de l'instance et recherchez une valeur élevée pour general_log_size .

Pour libérer de l'espace de stockage, suivez les étapes décrites dans la rubrique Purger le journal des requêtes générales .

Pourquoi observez-vous de nombreuses connexions dans l'état « Waiting for table level lock » ?

Effectuez un diagnostic en exécutant SHOW PROCESSLIST ou en interrogeant la table innodb_trx . Si de nombreuses connexions affichent l'état Waiting for table level lock parallèlement à un nombre élevé de connexions et une forte utilisation du CPU, le journal des requêtes générales est probablement la cause du problème.

Étant donné que le journal est stocké sous forme de table, les threads y écrivent séquentiellement. Chaque écriture acquiert un verrou de métadonnées (MDL) et un verrou au niveau de la table. En cas de volume d'écriture important, ces verrous s'accumulent en file d'attente et bloquent les autres connexions.

Désactivez le journal des requêtes générales pour mettre fin aux nouveaux conflits de verrouillage, puis purgez la table du journal. Consultez la section Purger le journal des requêtes générales .

Pourquoi la récupération de mon instance prend-elle beaucoup de temps après un arrêt inattendu ?

Lorsqu'une instance s'arrête de manière inattendue, une marque de plantage est définie pour le journal des requêtes générales. Au redémarrage suivant, MySQL déclenche un processus de récupération automatique pour la table du journal. Plus la table est volumineuse, plus la récupération est longue. Pendant cette période, l'instance est indisponible, ce qui allonge votre objectif de temps de reprise (RTO).

Maintenir le journal des requêtes générales désactivé lors des opérations normales et purger régulièrement la table du journal permet de garder la table de petite taille et d'accélérer la récupération.

Purger le journal des requêtes générales

Désactivez le journal des requêtes générales : définissez le paramètre general_log sur OFF . Cela empêche l'écriture de nouvelles entrées dans le journal. Pour obtenir des instructions, consultez la rubrique Définir les paramètres de l'instance .
Connectez-vous à l'instance à l'aide d'un compte privilégié, puis exécutez la commande suivante :
```
TRUNCATE TABLE mysql.general_log;
```
Une fois la commande terminée, vérifiez le résultat sur la page de surveillance de l'instance : la valeur general_log_size devrait chuter près de zéro.

La commande TRUNCATE TABLE mysql.general_log n'est pas prise en charge sur les instances ApsaraDB RDS pour MySQL 5.6. Contactez le support technique pour purger le journal sur MySQL 5.6.

Bonnes pratiques

Maintenez le journal des requêtes générales désactivé pendant les opérations normales. Activez-le uniquement temporairement à des fins de débogage ou de dépannage, puis purgez-le et désactivez-le immédiatement après.

Pour l'analyse et l'audit continus des instructions SQL, utilisez l'une des alternatives suivantes :

**(Recommandé) SQL Explorer et Audit** : enregistre et analyse automatiquement les instructions SQL exécutées. Les données d'audit sont stockées dans Database Autonomy Service (DAS) ; cela ne consomme pas d'espace de stockage sur l'instance RDS et n'affecte pas les performances de l'instance.
Journal des requêtes générales temporaire : activez temporairement le journal des requêtes générales, interrogez la table du journal, puis désactivez et purgez le journal une fois l'opération terminée :
```
SELECT * FROM mysql.general_log;
```

Étapes suivantes

Étendre manuellement l'espace de stockage de l'instance
Activer l'extension automatique du stockage : le système étend automatiquement le stockage lorsque l'utilisation atteint le seuil que vous avez configuré