Stati del thread Aurora MySQL

Di seguito sono riportati alcuni tra gli stati di thread più frequenti di Aurora MySQL.

Verifica delle autorizzazioni

Il thread sta verificando se il server dispone dei privilegi necessari per eseguire l'istruzione.

controllo della cache delle query per la query

Il server sta verificando se la query corrente è presente nella cache delle query.

ripulito

Questo è lo stato finale di una connessione il cui lavoro è completo ma che non è stato chiuso dal client. La soluzione migliore è chiudere esplicitamente la connessione nel codice. Oppure puoi impostare un valore inferiore per wait_timeout nel gruppo di parametri.

chiusura tabelle

Il thread sta scaricando i dati della tabella modificati su disco e chiude le tabelle utilizzate. Se non si tratta di un'operazione rapida, verificare le metriche di consumo della larghezza di banda di rete rispetto alla larghezza di banda di rete della classe di istanza. Inoltre, verificare che i valori dei parametri per table_open_cachee table_definition_cache il parametro consentano di aprire contemporaneamente una quantità sufficiente di tabelle in modo che il motore non debba aprire e chiudere frequentemente le tabelle. Questi parametri influenzano il consumo di memoria sull'istanza.

conversione da HEAP a myISAM

La query sta convertendo una tabella temporanea da memoria a su disco. Questa conversione è necessaria perché le tabelle temporanee create da MySQL nelle fasi intermedie dell'elaborazione delle query sono diventate troppo grandi per la memoria. Verifica i valori di tmp_table_size e max_heap_table_size. Nelle versioni successive, il nome dello stato del thread è converting HEAP to ondisk.

conversione di HEAP in ondisk

Il thread sta convertendo una tabella temporanea interna da una tabella in memoria a una tabella su disco.

copia nella tabella tmp

Il thread sta elaborando un'istruzione ALTER TABLE. Questo stato si verifica dopo che la tabella con la nuova struttura è stata creata ma prima che le righe vengano copiate. Per un thread in questo stato, è possibile utilizzare lo schema delle prestazioni per ottenere informazioni sullo stato di avanzamento dell'operazione di copia.

creazione di indice di ordinamento

Aurora MySQL sta eseguendo un ordinamento perché non può utilizzare un indice esistente per soddisfare la clausola ORDER BY o GROUP BY di una query. Per ulteriori informazioni, consulta creazione di indice di ordinamento.

Creazione di tabelle

Il thread sta creando una tabella permanente o temporanea.

commit ritardato ok fatto

Un commit asincrono in Aurora MySQL ha ricevuto un riconoscimento ed è completo.

ritardato commit ok avviato

Il thread Aurora MySQL ha avviato il processo di commit asincrono ma è in attesa di un riconoscimento. Di solito questo è il tempo di commit autentico di una transazione.

invio ritardato ok fatto

Un thread di lavoro Aurora MySQL collegato a una connessione può essere liberato mentre viene inviata una risposta al client. Il thread può iniziare altri lavori. Lo stato delayed send ok significa che la conferma asincrona al client è stata completata.

invio ritardato ok avviato

Un thread di lavoro Aurora MySQL ha inviato una risposta asincrona a un client ed è ora libero di lavorare per altre connessioni. La transazione ha avviato un processo di commit asincrono che non è ancora stato riconosciuto.

executing

Il thread ha iniziato a eseguire un'istruzione.

liberazione elementi

Il thread ha eseguito un comando. Alcuni liberazioni degli elementi eseguiti durante questo stato coinvolgono la cache delle query. Questo stato è solitamente seguito dalla pulizia.

init

Questo stato si verifica prima dell'inizializzazione di ALTER TABLE,DELETE,INSERT,SELECT, oppure istruzioni UPDATE. Le azioni in questo stato includono lo svuotamento del log binario o del log InnoDB e alcune operazioni di pulizia della cache delle query.

master ha inviato tutti i binlog a slave

Il nodo primario ha terminato la sua parte della replica. Il thread è in attesa di eseguire altre query in modo che possa scrivere nel log binario (binlog).

apertura tabella

Il thread sta tentando di aprire una tabella. Questa operazione è veloce a meno che un'istruzione ALTER TABLE o LOCK TABLE debba finire o superare il valore di table_open_cache.

Ottimizzazione

Il server sta eseguendo le ottimizzazioni iniziali per una query.

preparazione

Questo stato si verifica durante l'ottimizzazione delle query.

fine query

Questo stato si verifica dopo l'elaborazione di una query ma prima dello stato di liberazione degli elementi.

rimozione di duplicati

Aurora MySQL non è riuscita a ottimizzare un'operazione DISTINCT nella fase iniziale di una query. Aurora MySQL deve rimuovere tutte le righe duplicate prima di inviare il risultato al client.

ricerca di righe per l'aggiornamento

Il thread sta trovando tutte le righe corrispondenti prima di aggiornarle. Questa fase è necessaria se il UPDATE sta cambiando l'indice utilizzato dal motore per trovare le righe.

invio dell'evento binlog a slave

Il thread ha letto un evento dal log binario e lo sta inviando alla replica.

invio di risultati memorizzati nella cache al client

Il server sta prendendo il risultato di una query dalla cache delle query e la invia al client.

Invio dei dati

Il thread sta leggendo ed elaborando le righe per un'istruzione SELECT ma non ha ancora iniziato a inviare dati al client. Il processo sta identificando quali pagine contengono i risultati necessari per soddisfare la query. Per ulteriori informazioni, consulta invio dei dati.

invio al client

Il server sta scrivendo un pacchetto sul client. Nelle versioni precedenti di MySQL, questo evento di attesa è stato etichettato writing to net.

avvio in corso

Questa è la prima fase all'inizio dell'esecuzione dell'istruzione.

statistics

Il server sta calcolando le statistiche per sviluppare un piano di esecuzione delle query. Se un thread è in questo stato per un lungo periodo, il server è probabilmente associato a disco durante l'esecuzione di altri lavori.

archiviazione dei risultati nella cache delle query

Il server sta memorizzando il risultato di una query nella cache delle query.

blocco del sistema

Il thread ha chiamato mysql_lock_tables, ma lo stato del thread non è stato aggiornato dalla chiamata. Questo stato generale si verifica per molte ragioni.

update

Il thread si sta preparando per iniziare ad aggiornare la tabella.

aggiornamento

Il thread sta cercando righe e le sta aggiornando.

blocco utente

Il thread ha emesso una chiamata GET_LOCK. Il thread ha richiesto un blocco consultivo e lo sta aspettando o sta pianificando di richiederlo.

in attesa di ulteriori aggiornamenti

Il nodo primario ha terminato la sua parte della replica. Il thread è in attesa di eseguire altre query in modo che possa scrivere nel log binario (binlog).

in attesa del blocco dei metadati dello schema

Questa è un'attesa per un blocco dei metadati.

in attesa del blocco dei metadati della funzione memorizzata

Questa è un'attesa per un blocco dei metadati.

in attesa del blocco dei metadati della procedura archiviata

Questa è un'attesa per un blocco dei metadati.

in attesa dello scarico della tabella

Il thread sta eseguendo FLUSH TABLES e sta aspettando che tutti i thread chiudano le loro tabelle. Oppure il thread ha ricevuto una notifica che la struttura sottostante per una tabella è cambiata, quindi deve riaprire la tabella per ottenere la nuova struttura. Per riaprire la tabella, il thread deve attendere che tutti gli altri thread abbiano chiuso la tabella. Questa notifica avviene se un altro thread ha utilizzato una delle seguenti istruzioni sulla tabella: FLUSH TABLES,ALTER TABLE,RENAME TABLE,REPAIR TABLE,ANALYZE TABLE, oppure OPTIMIZE TABLE.

in attesa di blocco a livello tabella

Una sessione tiene un blocco su un tavolo mentre un'altra sessione tenta di acquisire lo stesso blocco sulla stessa tabella.

in attesa del blocco dei metadati della tabella

Aurora MySQL utilizza il blocco dei metadati per gestire l'accesso simultaneo agli oggetti del database e garantire la coerenza dei dati. In questo evento di attesa, una sessione tiene un blocco di metadati su una tabella mentre un'altra sessione tenta di acquisire lo stesso blocco sulla stessa tabella. Quando lo schema delle prestazioni è abilitato, questo stato del thread viene segnalato come evento di attesa synch/cond/sql/MDL_context::COND_wait_status.

scrittura su rete

Il server sta scrivendo un pacchetto sulla rete. Nelle versioni successive di MySQL, questo evento di attesa è etichettato Sending to client.