Fastställa skalningsbehov för Azure Database for MySQL-server
När det gäller storleksändring av beräkningsresurser bör du överväga om befintlig och prognostiserad användning ligger väl inom kapaciteten. Du kan hämta nödvändig information genom att övervaka grundläggande prestandamått, till exempel CPU- och RAM-användning. Det kan vara möjligt att använda den långsamma frågeloggen för att identifiera och optimera frågor som fungerar dåligt och åtgärda prestandaproblemet utan att skala beräkningsstorleken. Du bör också övervaka I/O-prestanda för att se till att databasläsningar och skrivningar inte är en flaskhals för prestanda. Ett annat alternativ för att effektivt öka den tillgängliga kapaciteten i huvuddatabasen är att etablera en läsreplik för att flytta frågebelastningen.
Övervaka databasprestandamått
Azure Portal visar åtkomst till ett antal mått som du kan använda för att övervaka databasprestanda. Du kan till exempel visualisera cpu-procentandelen som används av en flexibel server.
När processoranvändningen närmar sig 100 % försämras databasprestandan kraftigt. Om processoranvändningen på den flexibla servern är konsekvent över 50 % kan du därför överväga att öka beräkningsstorleken.
Du kan visa dina prestandamått i arbetsboken övervakningsöversikt. Utför följande steg för att komma åt översiktsarbetsboken:
I Azure Portal går du till den vänstra rutan under Övervakning för din flexibla Azure Database for MySQL-serverinstans och väljer Arbetsböcker.
Välj arbetsboken Översikt. Du ser diagram som visar anslutningar, cpu- och minnesanvändning och andra mått, som i följande skärmbild.
Förutom att analysera dessa mått kan du visa serverdiagnostik för att få insikter om prestanda på panelen Loggar på din flexibla server.
Förutom dessa mått och loggar kan du även övervaka loggen för långsamma frågor för att samla in information om långvariga frågor. Den här informationen kan avslöja befintliga långsamma frågor för optimering, och du kan konfigurera aviseringar för att omedelbart identifiera framtida regressioner för frågeprestanda för minskning.
Om du vill aktivera funktionen Långsam frågelogg går du till sidan som är associerad med din flexibla server, väljer Serverloggar och markerar sedan kryssrutorna "Aktivera" och "Långsamma frågeloggar".
När långsam frågeloggning har aktiverats kan du visa insikter om frågeprestanda med hjälp av logganalys eller visualiseringsarbetsböcker. Om du vill få åtkomst till insikter om frågeprestanda följer du samma steg som ovan men väljer Query Performance Insights i stället för Översikt.
Du ser flera visualiseringar, inklusive de fem längsta frågorna eller en sammanfattning av långsamma frågor, som du ser i följande skärmbild.
Justera serverprestandaparametrar
Du kan konfigurera MySQL-serverparametrar för att optimera prestanda baserat på din övervakning. Du kan till exempel öka värdet innodb_buffer_pool_size
för för att behålla mer tabelldata i minnet och spara på diskläsningar. Du kan öka innodb_log_file_size
för att minska buffertpoolens kontrollpunktsutspolningsaktivitet, på bekostnad av långsammare kraschåterställning.
Om du upptäcker att programanslutningar är i kö och serverbelastningen är acceptabel kan du öka antalet maximala anslutningar för att tillåta mer parallellitet.
Om du vill ändra serverparametrar går du till Azure Portal för din flexibla MySQL-server och går till avsnittet Serverparametrar. Ange parameternamnet i sökfältet eller bläddra igenom serverparametrarna Överst eller Alla som stöds.
Utforska och aktivera funktionen Autoskala IOPS
Azure Database for MySQL har två sätt att allokera disk-I/O-kapacitet: företablerad jämfört med "autoskalad" IOPS (I/O-åtgärder per sekund).
Företablerad IOPS kan vara att föredra när databasbelastningen är förutsägbar och inte toppar. Servern hämtar ett basantal etablerade IOPS och du kan allokera ytterligare IOPS (upp till beräkningsstorleken max) efter behov genom att gå till Beräkning + lagring:
Om en topp uppstår kan serverprestandan tillfälligt försämras om I/O-åtgärder överskrider det allokerade värdet. Kapacitet och kostnader är dock förutsägbara.
Funktionen Autoskala IOPS är byggd för oförutsägbar, spikig eller växande databastrafik. Med den här funktionen aktiverad skalas IOPS dynamiskt, så manuell justering krävs inte för att optimera kostnader eller prestanda när arbetsflödet varierar. Det innebär att användningen av funktionen Autoskala IOPS hanterar oanvända arbetsbelastningstoppar transparent och du betalar endast för åtgärder som förbrukas, inte för outnyttjad kapacitet.
För en befintlig flexibel MySQL-server kan du aktivera funktionen Autoskala IOPS i Azure Portal genom att välja Beräkning + lagring:
Kommentar
Du kan också aktivera funktionen Autoskala IOPS när servern skapas.
Övervaka IOPS
Genom att övervaka IOPS kan du avgöra hur nära din instans är maximalt IOPS, om du använder företablerad IOPS eller till den maximala beräkningsstorleken om du använder funktionen Autoskala IOPS.
Om du vill övervaka IOPS-prestanda navigerar du till bladet Mått under avsnittet Övervakning eller till bladet Översikt om du vill visa IOPS-prestanda tillsammans med andra vanliga mått.
På WingTip Toys, eftersom du förväntar dig en stor ökning av trafiken vid oförutsägbara tidpunkter när marknadsföringskampanjen lanseras, vill du undvika risken för att inte kunna hantera inkommande beställningar. Du vill också undvika att betala för maximal kapacitet om du faktiskt inte behöver den. Du väljer att använda funktionen Autoskala IOPS i stället för företablerad IOPS, vilket kräver att du lägger till mer IOPS manuellt efter behov. Den här metoden balanserar kostnadseffektivitet med skalbarhet på begäran.
Etablera en läsreplik
Du etablerar skrivskyddade repliker för att avlasta skrivskyddade frågor till en separat databas, vilket minskar belastningen på huvudprogramdatabasen.
Om du vill etablera en läsreplik går du till Azure Portal på sidan som är associerad med din flexibla server, väljer Replikering och väljer sedan Lägg till replik.
När du har skapat läsrepliken kan du konfigurera replikserverns namn och dess beräknings- och lagringsinställningar. Du kan inte ändra vissa inställningar, till exempel autentisering, som ärvs från den primära servern.
På Wingtip Toys kan data science-teamet och rapporteringsverktygen nu köra frågor mot read replica-servern, vilket minskar belastningen på huvudprogramdatabasen och tar bort behovet av att begränsa analys eller begränsa frågor utanför arbetstid.