États de thread Aurora MySQL

Voici quelques états de thread courants pour Aurora MySQL.

checking permissions

Le thread vérifie si le serveur dispose des privilèges requis pour exécuter l'instruction.

checking query cache for query

Le serveur vérifie si la requête actuelle est présente dans le cache de requête.

cleaned up

Il s'agit de l'état final d'une connexion dont la tâche est terminée, mais qui n'a pas été fermée par le client. La meilleure solution consiste à fermer explicitement la connexion dans le code. Vous pouvez également définir une valeur inférieure pour wait_timeout dans votre groupe de paramètres.

closing tables

Le thread vide les données de table modifiées sur le disque et ferme les tables utilisées. Si l'opération se prolonge, vérifiez les métriques de consommation de bande passante réseau par rapport à la bande passante réseau de classe d'instance. Vérifiez également que les valeurs des paramètres pour table_open_cacheet table_definition_cache permettent d'ouvrir simultanément un nombre suffisant de tables pour éviter au moteur de devoir ouvrir et fermer fréquemment les tables. Ces paramètres ont une incidence sur la consommation de mémoire sur l'instance.

converting HEAP to MyISAM

La requête convertit une table temporaire de table en mémoire à table sur disque. Cette conversion est nécessaire car les tables temporaires créées par MySQL au cours des étapes intermédiaires du traitement des requêtes sont devenues trop volumineuses pour la mémoire. Vérifiez les valeurs de tmp_table_size et max_heap_table_size. Dans les versions ultérieures, ce nom d'état de thread estconverting HEAP to ondisk.

converting HEAP to ondisk

Le thread convertit une table temporaire interne de table en mémoire à table sur disque.

copy to tmp table

Le thread traite une instruction ALTER TABLE. Cet état intervient après la création de la table avec la nouvelle structure, mais avant que des lignes n'y soient copiées. En présence d'un thread dans cet état, vous pouvez utiliser le schéma de performance pour obtenir des informations relatives à la progression de l'opération de copie.

creating sort index

Aurora MySQL effectue un tri, car il n'est pas en mesure d'utiliser un index existant pour satisfaire la clause ORDER BY ou GROUP BY d'une requête. Pour de plus amples informations, veuillez consulter creating sort index.

creating table

Le thread crée une table permanente ou temporaire.

delayed commit ok done

Dans Aurora MySQL, une validation asynchrone a reçu un accusé de réception et est terminée.

delayed commit ok initiated

Le thread Aurora MySQL a démarré le processus de validation asynchrone, mais attend l'accusé de réception. Il s'agit généralement du moment auquel une transaction est validée.

delayed send ok done

Un thread de travail Aurora MySQL lié à une connexion peut être libéré lorsqu'une réponse est envoyée au client. Le thread peut entamer d'autres tâches. L'état delayed send ok signifie que l'accusé de réception asynchrone adressé au client est terminé.

delayed send ok initiated

Un thread de travail Aurora MySQL a envoyé une réponse de manière asynchrone à un client et est désormais libre pour d'autres connexions. La transaction a lancé un processus de validation asynchrone qui n'a pas encore été confirmé.

executing

Le thread a commencé à exécuter une instruction.

freeing items

Le thread a exécuté une commande. La libération de certains éléments durant cet état implique le cache de requête. Cet état est généralement suivi d'un nettoyage.

init

Cet état intervient avant l'initialisation des instructions ALTER TABLE, DELETE, INSERT, SELECT ou UPDATE. Les actions correspondant à cet état incluent le vidage du journal binaire ou du journal InnoDB, et le nettoyage du cache de requête.

master has sent all binlog to slave

Le nœud primaire a terminé sa part de la réplication. Le thread attend l'exécution d'autres requêtes pour pouvoir écrire dans le journal binaire (binlog).

opening tables

Le thread essaie d'ouvrir une table. Cette opération est rapide, sauf si une instruction ALTER TABLE ou LOCK TABLEdoit se terminer, ou si elle dépasse la valeur de table_open_cache.

optimizing

Le serveur effectue des optimisations initiales pour une requête.

preparing

Cet état intervient lors de l'optimisation des requêtes.

query end

Cet état intervient après le traitement d'une requête, mais avant l'état de libération des éléments.

removing duplicates

Aurora MySQL n'a pas pu optimiser une opération DISTINCT au début d'une requête. Aurora MySQL doit supprimer toutes les lignes dupliquées avant d'envoyer le résultat au client.

searching rows for update

Le thread recherche toutes les lignes correspondantes avant de les mettre à jour. Cette étape est nécessaire si la UPDATE modifie l'index utilisé par le moteur pour trouver les lignes.

sending binlog event to slave

Le thread lit un événement à partir du journal binaire et l'envoie au réplica.

sending cached result to client

Le serveur extrait le résultat d'une requête du cache de requête et l'envoie au client.

sending data

Le thread lit et traite les lignes d'une instruction SELECT, mais n'a pas encore commencé à envoyer des données au client. Le processus consiste à identifier les pages qui contiennent les résultats nécessaires pour satisfaire la requête. Pour de plus amples informations, veuillez consulter envoi de données.

sending to client

Le serveur écrit un paquet sur le client. Dans les versions antérieures de MySQL, cet événement d'attente était labélisé writing to net.

starting

Il s'agit de la première étape intervenant au début de l'exécution de l'instruction.

statistics

Le serveur calcule des statistiques pour développer un plan d'exécution des requêtes. Si un thread perdure dans cet état, le serveur est probablement lié au disque pendant qu'il effectue d'autres tâches.

storing result in query cache

Le serveur stocke le résultat d'une requête dans le cache de requête.

system lock

Le thread a appelé mysql_lock_tables, mais l'état du thread n'a pas été mis à jour depuis l'appel. Cet état général intervient pour de nombreuses raisons.

mise à jour

Le thread se prépare à commencer à mettre à jour la table.

updating

Le thread recherche des lignes et les met à jour.

user lock

Le thread a émis un appel GET_LOCK. Le thread a demandé un verrou consultatif et l'attend, ou envisage de le demander.

waiting for more updates

Le nœud primaire a terminé sa part de la réplication. Le thread attend l'exécution d'autres requêtes pour pouvoir écrire dans le journal binaire (binlog).

waiting for schema metadata lock

Il s'agit de l'attente d'un verrou de métadonnées.

waiting for stored function metadata lock

Il s'agit de l'attente d'un verrou de métadonnées.

waiting for stored procedure metadata lock

Il s'agit de l'attente d'un verrou de métadonnées.

waiting for table flush

Le thread exécute FLUSH TABLES et attend que tous les threads de ferment leurs tables. Ou bien, le thread a reçu une notification indiquant que la structure sous-jacente d'une table a changé et qu'il lui faut rouvrir cette table pour obtenir la nouvelle structure. Pour rouvrir cette table, le thread doit attendre que tous les autres threads l'aient fermée. Cette notification intervient si un autre thread a utilisé une des instructions suivantes sur la table : FLUSH TABLES, ALTER TABLE, RENAME TABLE, REPAIR TABLE, ANALYZE TABLE ou OPTIMIZE TABLE.

waiting for table level lock

Une session maintient un verrou sur une table tandis qu'une autre tente d'acquérir le même verrou sur la même table.

waiting for table metadata lock

Aurora MySQL utilise le verrouillage des métadonnées pour gérer l'accès simultané aux objets de base de données et assurer la cohérence des données. Dans cet événement d'attente, une session maintient un verrou de métadonnées sur une table tandis qu'une autre tente d'acquérir le même verrou sur la même table. Lorsque le schéma de performance est activé, cet état de thread est signalé en tant qu'événement d'attente synch/cond/sql/MDL_context::COND_wait_status.

writing to net

Le serveur écrit un paquet sur le réseau. Dans les versions ultérieures de MySQL, cet événement d'attente est labélisé Sending to client.