MariaDB
 sql >> Database >  >> RDS >> MariaDB

Gestire le query MySQL di lunga durata

Query/dichiarazioni/transazioni di lunga durata sono talvolta inevitabili in un ambiente MySQL. In alcune occasioni, una query di lunga durata potrebbe essere un catalizzatore di un evento disastroso. Se ti interessa il tuo database, l'ottimizzazione delle prestazioni delle query e il rilevamento delle query a esecuzione prolungata devono essere eseguiti regolarmente. Tuttavia, le cose si complicano quando sono coinvolte più istanze in un gruppo o in un cluster.

Quando si ha a che fare con più nodi, le attività ripetitive per controllare ogni singolo nodo sono qualcosa che dobbiamo evitare. ClusterControl monitora molteplici aspetti del server di database, incluse le query. ClusterControl aggrega tutte le informazioni relative alle query da tutti i nodi del gruppo o del cluster per fornire una visualizzazione centralizzata del carico di lavoro. Proprio lì c'è un ottimo modo per comprendere il tuo cluster nel suo insieme con il minimo sforzo.

In questo post del blog, ti mostriamo come rilevare le query MySQL a esecuzione prolungata utilizzando ClusterControl.

Perché una query richiede più tempo?

Prima di tutto, dobbiamo conoscere la natura della query, se si prevede che sia una query di lunga durata o di breve durata. Alcune operazioni analitiche e batch dovrebbero essere query di lunga durata, quindi per ora possiamo saltarle. Inoltre, a seconda delle dimensioni della tabella, la modifica della struttura della tabella con il comando ALTER può essere un'operazione di lunga durata.

Per una transazione di breve durata, dovrebbe essere eseguita il più velocemente possibile, di solito in una manciata di secondi. Più corto è, meglio è. Questo viene fornito con una serie di regole di best practice per le query che gli utenti devono seguire, come utilizzare l'indicizzazione corretta nell'istruzione WHERE o JOIN, utilizzare il motore di archiviazione corretto, selezionare i tipi di dati appropriati, pianificare l'operazione batch durante le ore non di punta, scaricare dati analitici /segnalazione del traffico a repliche dedicate e così via.

Ci sono una serie di cose che possono far sì che una query richieda più tempo per l'esecuzione:

  • Query inefficiente:utilizza colonne non indicizzate durante la ricerca o l'unione, quindi MySQL impiega più tempo per soddisfare la condizione.
  • Blocco tabella:la tabella è bloccata, tramite blocco globale o blocco tabella esplicito quando la query tenta di accedervi.
  • Deadlock:una query è in attesa di accedere alle stesse righe bloccate da un'altra query.
  • Il set di dati non si adatta alla RAM:se i dati del tuo set di lavoro rientrano in quella cache, le query SELECT saranno generalmente relativamente veloci.
  • Risorse hardware non ottimali:potrebbero essere dischi lenti, ricostruzione RAID, rete saturata ecc.
  • Operazione di manutenzione - L'esecuzione di mysqldump può portare enormi quantità di dati altrimenti inutilizzati nel pool di buffer e allo stesso tempo i dati (potenzialmente utili) già presenti verranno eliminati e scaricati su disco.

L'elenco di cui sopra sottolinea che non è solo la query stessa a causare tutti i tipi di problemi. Ci sono molte ragioni che richiedono di esaminare diversi aspetti di un server MySQL. In uno scenario peggiore, una query di lunga durata potrebbe causare un'interruzione totale del servizio come server inattivo, arresto anomalo del server e esaurimento delle connessioni. Se vedi che una query impiega più tempo del solito per essere eseguita, esaminala.

Come controllare?

ELENCO PROCESSO

MySQL fornisce una serie di strumenti integrati per controllare le transazioni di lunga durata. Innanzitutto, i comandi SHOW PROCESSLIST o SHOW FULL PROCESSLIST possono esporre le query in esecuzione in tempo reale. Ecco uno screenshot della funzione ClusterControl Esecuzione query, simile al comando SHOW FULL PROCESSLIST (ma ClusterControl aggrega tutto il processo in un'unica vista per tutti i nodi del cluster):

Come puoi vedere, possiamo vedere immediatamente la query offensiva subito dall'output. Ma quante volte fissiamo quei processi? Questo è utile solo se sei a conoscenza della transazione di lunga durata. Altrimenti, non lo sapresti fino a quando non succede qualcosa, ad esempio le connessioni si stanno accumulando o il server sta diventando più lento del solito.

Registro query lento

Il registro delle query lente acquisisce le query lente (istruzioni SQL che richiedono più di long_query_time secondi di esecuzione) o query che non utilizzano gli indici per le ricerche (log_queries_not_using_indexes ). Questa funzionalità non è abilitata per impostazione predefinita e per abilitarla è sufficiente impostare le seguenti righe e riavviare il server MySQL:

[mysqld]
slow_query_log=1
long_query_time=0.1
log_queries_not_using_indexes=1

Il registro delle query lente può essere utilizzato per trovare query che richiedono molto tempo per essere eseguite e sono quindi candidate all'ottimizzazione. Tuttavia, l'esame di un log di query lungo e lento può richiedere molto tempo. Esistono strumenti per analizzare i file di registro delle query lente MySQL e riassumerne il contenuto come mysqldumpslow, pt-query-digest o ClusterControl Top Query.

ClusterControl Top Query riepiloga la query lenta utilizzando due metodi:il log delle query lente MySQL o lo schema delle prestazioni:

È possibile visualizzare facilmente un riepilogo dei riassunti di istruzioni normalizzati, ordinati in base a una serie di criteri:

  • Ospite
  • Ricorrenze
  • Tempo di esecuzione totale
  • Tempo massimo di esecuzione
  • Tempo medio di esecuzione
  • Tempo di deviazione standard

Abbiamo trattato questa funzionalità in dettaglio in questo post del blog, Come utilizzare ClusterControl Query Monitor per MySQL, MariaDB e Percona Server.

Schema delle prestazioni

Performance Schema è un ottimo strumento disponibile per il monitoraggio degli interni di MySQL Server e dei dettagli di esecuzione a un livello inferiore. Le seguenti tabelle in Performance Schema possono essere utilizzate per trovare query lente:

  • eventi_dichiarazioni_corrente
  • events_statements_history
  • events_statements_history_long
  • events_statements_summary_by_digest
  • events_statements_summary_by_user_by_event_name
  • events_statements_summary_by_host_by_event_name

MySQL 5.7.7 e versioni successive includono lo schema sys, un insieme di oggetti che aiuta i DBA e gli sviluppatori a interpretare i dati raccolti dal Performance Schema in una forma più facilmente comprensibile. Gli oggetti Sys schema possono essere utilizzati per i tipici casi d'uso di ottimizzazione e diagnosi.

ClusterControl fornisce advisor, che sono mini-programmi che è possibile scrivere utilizzando ClusterControl DSL (simile a JavaScript) per estendere le capacità di monitoraggio di ClusterControl personalizzate in base alle proprie esigenze. Esistono numerosi script inclusi in base allo schema delle prestazioni che è possibile utilizzare per monitorare le prestazioni delle query come l'attesa di I/O, il tempo di attesa del blocco e così via. Ad esempio in Gestisci -> Developer Studio , vai su s9s -> mysql -> p_s -> top_tables_by_iowait.js e fare clic sul pulsante "Compila ed esegui". Dovresti vedere l'output nella scheda Messaggi per le prime 10 tabelle ordinate per attesa I/O per server:

Esistono numerosi script che puoi utilizzare per comprendere informazioni di basso livello dove e perché si verifica la lentezza, come top_tables_by_lockwait.js , top_accessed_db_files.js e così via.

ClusterControl:rilevamento e avviso in caso di query di lunga durata

Con ClusterControl, otterrai potenti funzionalità aggiuntive che non troverai nell'installazione standard di MySQL. ClusterControl può essere configurato per monitorare in modo proattivo i processi in esecuzione, generare un allarme e inviare una notifica all'utente se viene superata la soglia di query lunga. Questo può essere configurato utilizzando la configurazione di runtime in Impostazioni:

Per la versione precedente alla 1.7.1, il valore predefinito per query_monitor_alert_long_running_query è falso. Incoraggiamo l'utente ad abilitarlo impostandolo su 1 (true). Per renderlo persistente, aggiungi la seguente riga in /etc/cmon.d/cmon_X.cnf:

query_monitor_alert_long_running_query=1
query_monitor_long_running_query_ms=30000

Eventuali modifiche apportate alla configurazione di runtime vengono applicate immediatamente e non è necessario riavviare. Vedrai qualcosa di simile nella sezione Allarmi se una query supera le soglie di 30000 ms (30 secondi):

Se configuri le impostazioni del destinatario della posta come "Deliver" per la categoria di gravità DbComponent plus CRITICAL (come mostrato nella schermata seguente):

Dovresti ricevere una copia di questo allarme nella tua e-mail. In caso contrario, può essere inoltrato manualmente facendo clic sul pulsante "Invia email".

Inoltre, puoi filtrare qualsiasi tipo di risorsa processlist che soddisfa determinati criteri con l'espressione regolare (regex). Ad esempio, se si desidera che ClusterControl rilevi query a esecuzione prolungata per tre utenti MySQL denominate 'sbtest', 'myshop' e 'db_user1', è necessario eseguire le seguenti operazioni:

Eventuali modifiche apportate alla configurazione di runtime vengono applicate immediatamente e non è necessario riavviare.

Inoltre, ClusterControl elencherà tutte le transazioni deadlock insieme allo stato di InnoDB quando si verificava in Prestazioni -> Registro transazioni :

Questa funzione non è abilitata per impostazione predefinita, poiché il rilevamento del deadlock influirà sull'utilizzo della CPU sui nodi del database. Per abilitarlo, spunta semplicemente la casella di controllo "Abilita registro transazioni" e specifica l'intervallo che desideri. Per renderlo persistente, aggiungi una variabile con valore in secondi all'interno di /etc/cmon.d/cmon_X.cnf:

db_deadlock_check_interval=30

Allo stesso modo, se vuoi controllare lo stato di InnoDB, vai semplicemente su Prestazioni -> Stato di InnoDB e scegli il server MySQL dal menu a discesa. Ad esempio:

Ecco fatto:tutte le informazioni richieste sono facilmente recuperabili in un paio di clic.

Riepilogo

Transazioni di lunga durata potrebbero portare a un degrado delle prestazioni, al mancato funzionamento del server, all'esaurimento delle connessioni e ai deadlock. Con ClusterControl, puoi rilevare query con esecuzione prolungata direttamente dall'interfaccia utente, senza la necessità di esaminare ogni singolo nodo MySQL nel cluster.