Azure Database for MySQL – prestandafunktioner för flexibel server

  • 6 minuter

Du kan skapa flexibla Azure Database for MySQL-servrar baserat på någon av tre tjänstnivåer: Burstable, Generell användning och Affärskritisk. Tjänstnivåerna ger en ökande nivå av beräknings- och lagringsstorlek, samt det antal maximala anslutningar och I/O-åtgärder som stöds per sekund (IOPS). En flexibel MySQL-server kan vara värd för flera databaser. Du kan övervaka den flexibla MySQL-serverns prestandamått som cpu- och minnesanvändning, I/O-prestanda, frågemått med mera för att fatta välgrundade kapacitetsbeslut.

Beräkningsstorlek: RAM-minne och kärnor

Var och en av de tre tjänstnivåerna tillhandahåller olika underliggande VM-SKU:er. Nivån Burstable använder virtuella datorer i B-serien, den Generell användning nivån använder virtuella datorer i D-serien och den Affärskritisk nivån använder virtuella datorer i E-serien. Den vm-serie som används avgör antalet virtuella kärnor och RAM-minne som är tillgängliga på servern.

Du kan ändra beräkningsnivå, beräkningsstorlek och lagringsstorlek när du har skapat en server. Om du ändrar beräkningsnivån eller beräkningsstorleken krävs en omstart som vanligtvis tar mellan en till två minuter att slutföra. Om du ändrar lagringsstorleken krävs ingen omstart.

För icke-produktionsarbetsbelastningar (utveckling, mellanlagring, testning osv.) bör du överväga att använda servrar baserat på nivån Burstable, vilket ger en kostnadseffektiv lösning för arbetsbelastningar som inte kontinuerligt använder hela processorn. Under perioder med låg användning ackumulerar servrar som använder virtuella datorer i B-serien CPU-krediter som kan användas i perioder med hög användning för att öka prestandan kraftigt över baslinjen. Om baslinjen är för hög eller om det finns för många hög användningstoppar bör du överväga att uppgradera till nivåerna Generell användning eller Affärskritisk för att undvika prestandaförsämring.

Beräkningsstorlekar på tjänstnivå

Var och en av de tre tjänstnivåerna ger olika nivåer av beräkningskraft. Nivån Burstable har stöd för upp till 20 virtuella kärnor och Generell användning-nivån har stöd för upp till 64 virtuella kärnor, med stöd för upp till 96 virtuella kärnor, men den Affärskritisk nivån ger den högsta nivån av beräkningskraft. Nivån Affärskritisk tillhandahåller även virtuella Datorer i Ev5-serien, som upp till 30% fler QPS och 50% lägre svarstid än de virtuella datorerna i Ev4-serien.

IOPS: Företablerad jämfört med autoskalning

Antalet läs- och skrivåtgärder som kan utföras per sekund kallas lagrings-IOPS (I/O-åtgärder per sekund). Högre IOPS-inställningar ger bättre lagringsprestanda: fler samtidiga läs-/skrivåtgärder resulterar i snabbare datahämtning, datapersistence, indexuppdateringar och övergripande databaseffektivitet. Om IOPS-inställningarna är för låga kan det uppstå bearbetningsfördröjningar och försämrade prestanda i databasen. Om IOPS-inställningarna är för höga kan dina kostnader dock öka utan att du inser några prestandaförbättringar.

Med Azure Database for MySQL – flexibel server kan du antingen företablera IOPS eller använda funktionen Autoskala IOPS.

  • Med företablerad IOPS allokerar du ett visst antal IOPS för att tillhandahålla konsekventa och förutsägbara prestanda, vilket fungerar bra om belastningen inte närmar sig tröskelvärdet där I/O-åtgärder begränsas. Du kan alltid allokera ytterligare IOPS när arbetsbelastningskraven ökar, men detta kräver manuella åtgärder.

  • Med funktionen Autoskala IOPS aktiverad skalar din IOPS på begäran baserat på arbetsbelastningsaktivitet och du betalar baserat på förbrukning. När arbetsbelastningen ökar skalas I/O-prestanda sömlöst på servern, vilket gör att din instans kan hantera toppar i arbetsbelastningen utan att betala för outnyttjad kapacitet när trafiken är låg.

I båda fallen kan IOPS inte överskrida serverns maxvärde. Information om maximal IOPS efter beräkningsstorlek finns i artikeln Om beräkning och lagringsdokumentation.

Skrivskyddade repliker

När databasens trafik ökar kan du skala dess kapacitet vågrätt eller "ut" (antal beräkningsnoder) eller lodrätt eller "uppåt" (storleken på beräkningsnoder). Läsrepliker ger horisontell skalning.

En read replica är en skrivskyddad kopia av en databas som förblir synkroniserad med hjälp av MySQL:s binärloggreplikering (binlog). När programmen växer måste de skala beräknings- och lagringsresurser (till exempel databasen). Skalning av programkomponenter förenklas genom etablering av nya virtuella datorer med hjälp av Azure Kubernetes Service (AKS), VM-skalningsuppsättningar och App Service. När dessa beräkningsresurser skalas och lagrade data växer ökar belastningen på databasen, vilket ofta blir en flaskhals i programmets arkitektur.

Med en skrivskyddad replik kan du omdirigera skrivskyddade åtgärder till sekundära databaser så att den primära servern stöder läs-/skrivåtgärder. Azure Database for MySQL tillhandahåller hanterade läsrepliker. Du kan replikera en källserver till upp till 10 repliker. Detta kan vara till hjälp i användningsfall som rapportering och analys, som ofta efterfrågar stora mängder data.

Det är särskilt användbart att använda en läsreplik när det av en eller annan anledning inte går att använda index. Det kan vara opraktiskt eller till och med störande att lägga till index för alla frågemönster, eftersom det lägger ytterligare belastning på servern (bearbetning, disk-I/O, lagring, transaktionstid osv.). Om ett informationslager inte är tillgängligt eller om du behöver data som är nyare än uppdateringscykeln är det ett bra sätt att köra "stora" frågor utan att störa kritiska läs-/skrivåtgärder med hjälp av en läsreplik.

Läsrepliker är inte omedelbart synkrona på samma sätt som en konfiguration med hög tillgänglighet. Läsrepliker introducerar inte transaktionsfördröjningen som är associerad med en HA-lösning, men det kan uppstå en liten fördröjning när data når repliken från den primära databasen.