Hantera MySQL Long Running Queries

Långa frågor/uttalanden/transaktioner är ibland oundvikliga i en MySQL-miljö. I vissa tillfällen kan en långvarig fråga vara en katalysator för en katastrofal händelse. Om du bryr dig om din databas måste optimering av frågeprestanda och upptäcka långvariga frågor utföras regelbundet. Saker och ting blir dock svårare när flera instanser i en grupp eller ett kluster är inblandade.

När vi hanterar flera noder är de repetitiva uppgifterna att kontrollera varje enskild nod något som vi måste undvika. ClusterControl övervakar flera aspekter av din databasserver, inklusive frågor. ClusterControl samlar all frågerelaterade information från alla noder i gruppen eller klustret för att ge en centraliserad bild av arbetsbelastningen. Just det finns ett bra sätt att förstå ditt kluster som helhet med minimal ansträngning.

I det här blogginlägget visar vi dig hur du upptäcker MySQL långvariga frågor med ClusterControl.

Varför tar en fråga längre tid?

Först och främst måste vi känna till frågans natur, om den förväntas vara en lång eller kort pågående fråga. Vissa analys- och batchoperationer är tänkta att vara långvariga frågor, så vi kan hoppa över dem tills vidare. Beroende på tabellstorleken kan det vara en långvarig operation att ändra tabellstrukturen med kommandot ALTER.

För en korttidstransaktion bör den utföras så snabbt som möjligt, vanligtvis inom några sekunder. Ju kortare desto bättre. Detta kommer med en uppsättning av bästa praxis-regler för frågor som användarna måste följa, som att använda korrekt indexering i WHERE- eller JOIN-satsen, använda rätt lagringsmotor, välja rätt datatyper, schemalägga batchoperationen under lågtrafik, ladda av analytisk /rapportera trafik till dedikerade repliker och så vidare.

Det finns ett antal saker som kan göra att en fråga tar längre tid att köra:

• Ineffektiv fråga - Använd icke-indexerade kolumner när du söker eller går med, så MySQL tar längre tid att matcha villkoret.
• Tabelllås – Tabellen är låst, med globalt lås eller explicit tabelllås när frågan försöker komma åt den.
• Deadlock - En fråga väntar på att få åtkomst till samma rader som är låsta av en annan fråga.
• Datauppsättningen passar inte in i RAM - Om din arbetsuppsättningsdata passar in i den cachen, kommer SELECT-frågor vanligtvis att vara relativt snabba.
• Suboptimala hårdvaruresurser – Detta kan vara långsamma diskar, RAID-ombyggnad, mättat nätverk etc.
• Underhåll - Att köra mysqldump kan föra in enorma mängder annars oanvänd data till buffertpoolen, och samtidigt kommer (potentiellt användbara) data som redan finns att vräkas och spolas till disken.

Listan ovan betonar att det inte bara är själva frågan som orsakar alla möjliga problem. Det finns många skäl som kräver att man tittar på olika aspekter av en MySQL-server. I vissa värre fall kan en lång pågående fråga orsaka en total tjänstavbrott som servern ned, serverkrasch och anslutningar som maxar. Om du ser att en fråga tar längre tid än vanligt att köra, undersök den.

Hur kontrollerar jag?

PROCESSLISTA

MySQL tillhandahåller ett antal inbyggda verktyg för att kontrollera den långvariga transaktionen. Först och främst kan kommandona SHOW PROCESSLIST eller SHOW FULL PROCESSLIST exponera de pågående frågorna i realtid. Här är en skärmdump av funktionen ClusterControl Running Queries, liknande kommandot SHOW FULL PROCESSLIST (men ClusterControl samlar hela processen i en vy för alla noder i klustret):

Som du kan se kan vi omedelbart se den stötande frågan direkt från utgången. Men hur ofta stirrar vi på dessa processer? Detta är bara användbart om du är medveten om den långvariga transaktionen. Annars skulle du inte veta förrän något händer - som att anslutningar hopar sig eller att servern blir långsammare än vanligt.

Långsam frågelogg

Långsam frågelogg fångar långsamma frågor (SQL-satser som tar mer än long_query_time sekunder att köra), eller frågor som inte använder index för uppslagningar (log_queries_not_using_indexes ). Den här funktionen är inte aktiverad som standard och för att aktivera den ställer du bara in följande rader och startar om MySQL-servern:

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

Den långsamma frågeloggen kan användas för att hitta frågor som tar lång tid att köra och därför är kandidater för optimering. Men att undersöka en lång långsam frågelogg kan vara en tidskrävande uppgift. Det finns verktyg för att analysera MySQL långsamma frågeloggfiler och sammanfatta deras innehåll som mysqldumpslow, pt-query-digest eller ClusterControl Top Queries.

ClusterControl Top Queries sammanfattar den långsamma frågan med två metoder - MySQL långsam frågelogg eller Performance Schema:

Du kan enkelt se en sammanfattning av de normaliserade uttalandesammandragen, sorterade utifrån ett antal kriterier:

• Värd
• Förekomster
• Total körningstid
• Maximal körningstid
• Genomsnittlig körningstid
• Standardavvikelsetid

Vi har behandlat den här funktionen i detalj i det här blogginlägget, Hur man använder ClusterControl Query Monitor för MySQL, MariaDB och Percona Server.

Prestandaschema

Performance Schema är ett utmärkt verktyg tillgängligt för att övervaka MySQL Servers interna funktioner och exekveringsdetaljer på en lägre nivå. Följande tabeller i Performance Schema kan användas för att hitta långsamma frågor:

• events_statements_current
• 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 och högre inkluderar sys-schemat, en uppsättning objekt som hjälper DBA:er och utvecklare att tolka data som samlats in av Performance Schema till en mer lättförståelig form. Sys-schemaobjekt kan användas för typiska justeringar och diagnoser.

ClusterControl tillhandahåller rådgivare, som är miniprogram som du kan skriva med ClusterControl DSL (liknande JavaScript) för att utöka ClusterControls övervakningsfunktioner anpassade efter dina behov. Det finns ett antal skript inkluderade baserat på Performance Schema som du kan använda för att övervaka frågeprestanda som I/O-vänta, låsa väntetid och så vidare. Till exempel under Manage -> Developer Studio , gå till s9s -> mysql -> p_s -> top_tables_by_iowait.js och klicka på knappen "Kompilera och kör". Du bör se utdata under fliken Meddelanden för topp 10 tabeller sorterade efter I/O-vänta per server:

Det finns ett antal skript som du kan använda för att förstå lågnivåinformation var och varför långsamheten inträffar som top_tables_by_lockwait.js , top_accessed_db_files.js och så vidare.

ClusterControl - Upptäcker och varnar vid långvariga frågor

Med ClusterControl får du ytterligare kraftfulla funktioner som du inte hittar i standardinstallationen av MySQL. ClusterControl kan konfigureras för att proaktivt övervaka de pågående processerna och larma och skicka meddelande till användaren om lång frågetröskel överskrids. Detta kan konfigureras genom att använda Runtime Configuration under Inställningar:

För pre1.7.1, standardvärdet för query_monitor_alert_long_running_query är falskt. Vi uppmuntrar användaren att aktivera detta genom att ställa in det på 1 (true). För att göra det beständigt, lägg till följande rad i /etc/cmon.d/cmon_X.cnf:

query_monitor_alert_long_running_query=1
query_monitor_long_running_query_ms=30000

Alla ändringar som görs i Runtime Configuration tillämpas omedelbart och ingen omstart krävs. Du kommer att se något liknande under avsnittet Larm om en fråga överskrider 30 000 ms (30 sekunder) tröskelvärden:

Om du konfigurerar e-postmottagarens inställningar som "Levera" för DbComponent plus CRITICAL allvarlighetsgradskategorin (som visas i följande skärmdump):

Du bör få en kopia av detta larm i din e-post. Annars kan den vidarebefordras manuellt genom att klicka på knappen "Skicka e-post".

Dessutom kan du filtrera bort alla typer av processlistresurser som matchar vissa kriterier med reguljärt uttryck (regex). Om du till exempel vill att ClusterControl ska upptäcka långa pågående frågor för tre MySQL-användare som kallas 'sbtest', 'myshop' och 'db_user1', bör följande göra:

Alla ändringar som görs i Runtime Configuration tillämpas omedelbart och ingen omstart krävs.

Dessutom kommer ClusterControl att lista ut alla dödlägestransaktioner tillsammans med InnoDB-statusen när det hände under Prestanda -> Transaktionslogg :

Den här funktionen är inte aktiverad som standard, eftersom detektering av dödläge kommer att påverka CPU-användning på databasnoder. För att aktivera det, markera helt enkelt kryssrutan "Aktivera transaktionslogg" och ange det intervall du vill ha. För att göra det beständigt, lägg till variabel med värde i sekunder inuti /etc/cmon.d/cmon_X.cnf:

db_deadlock_check_interval=30

På samma sätt, om du vill kolla in InnoDB-statusen, gå helt enkelt till Prestanda -> InnoDB-status , och välj MySQL-servern från rullgardinsmenyn. Till exempel:

Där går vi - all nödvändig information är lätt att hämta med ett par klick.

Sammanfattning

Långvariga transaktioner kan leda till prestandaförsämring, server nere, maxade anslutningar och dödlägen. Med ClusterControl kan du upptäcka långvariga frågor direkt från användargränssnittet, utan att behöva undersöka varenda MySQL-nod i klustret.