Tjänstnivåer för Azure Database for MySQL – flexibel server
GÄLLER FÖR: 
Azure Database for MySQL – flexibel server
Du kan skapa en flexibel Azure Database for MySQL-serverinstans på någon av tre tjänstnivåer: Burstable, Generell användning och Affärskritisk. Den underliggande VM-SKU:n skiljer de tjänstnivåer som används i B-serien, D-serien och E-serien. Valet av beräkningsnivå och storlek avgör vilket minne och de virtuella kärnor som är tillgängliga på servern. Den exakta lagringstekniken används på alla tjänstnivåer. Alla resurser etableras på instansnivå för Azure Database for MySQL– flexibel server. En server kan ha en eller flera databaser.
| Resurs/nivå | Burstbar | Generell användning | Affärskritisk |
|---|---|---|---|
| VM-serie | Storlekar på burstbara virtuella datorer i B-serien | Dadsv5-serienDdsv4-serien | Edsv4 Edsv5-serien*/Eadsv5-serien/ |
| Virtuella kärnor | 1, 2, 4, 8, 12, 16, 20 | 2, 4, 8, 16, 32, 48, 64 | 2, 4, 8, 16, 32, 48, 64, 80, 96 |
| Minne per virtuell kärna | Olika | 4 GiB | 8 GiB ** |
| Lagringsstorlek | 20 GiB till 16 TiB | 20 GiB till 16 TiB | 20 GiB till 32 TiB |
| Kvarhållningsperiod för databassäkerhetskopiering | 1 till 35 dagar | 1 till 35 dagar | 1 till 35 dagar |
** Förutom 64,80 och 96 virtuella kärnor, som har 504 GiB, 504 GiB respektive 672 GiB minne.
* Ev5-beräkning presterar bäst bland andra VM-serier när det gäller QPS och svarstid. Läs mer om prestanda och regiontillgänglighet för Ev5-beräkning härifrån.
Tjänstnivåer för flexibel server
Om du vill välja en beräkningsnivå använder du följande tabell som utgångspunkt.
| Beräkningsnivå | Målbelastningar |
|---|---|
| Burstbar | Bäst för arbetsbelastningar som kontinuerligt inte behöver hela processorn. |
| Generell användning | De flesta företagsarbetsbelastningar kräver balanserad databehandling och minne med skalbart I/O-dataflöde. Några exempel kan vara servrar som är värd för webb- och mobilappar och andra företagsprogram. |
| Affärskritisk | Databasarbetsbelastningar med höga prestanda som kräver minnesintern prestanda för snabbare transaktionsbearbetning och högre samtidighet. Exempel på det är servrar för att bearbeta realtidsdata och transaktionsappar eller analysappar med höga prestanda. |
När du har skapat en server kan du ändra beräkningsnivå, beräkningsstorlek och lagringsstorlek. Beräkningsskalning kräver en omstart och tar 60–120 sekunder, medan lagringsskalning inte gör det. Du kan också oberoende justera kvarhållningsperioden för säkerhetskopior upp eller ned. Mer information finns i avsnittet Skala resurser .
Tjänstnivåer, storlek och servertyper
Beräkningsresurser kan väljas baserat på nivå och storlek. Detta avgör virtuella kärnor och minnesstorlek. virtuella kärnor representerar den underliggande maskinvarans logiska PROCESSOR.
Burstbar
De detaljerade specifikationerna för de tillgängliga servertyperna är följande för tjänstnivån Burstable.
| Beräkningsstorlek | Virtuella kärnor | Fysisk minnesstorlek (GiB) | Total minnesstorlek (GiB) | Maximalt antal IOPS som stöds | Max antal anslutningar | Temp Storage (SSD) GiB |
|---|---|---|---|---|---|---|
| Standard_B1ms | 1 | 2 | 2,2 | 640 | 341 | 0 |
| Standard_B2s | 2 | 4 | 4.4 | 1280 | 683 | 0 |
| Standard_B2ms | 2 | 8 | 8.8 | 1 700 | 1365 | 0 |
| Standard_B4ms | 4 | 16 | 17,6 | 2400 | 2731 | 0 |
| Standard_B8ms | 8 | 32 | 35.2 | 3100 | 5461 | 0 |
| Standard_B12ms | 12 | 48 | 52.8 | 3800 | 8193 | 0 |
| Standard_B16ms | 16 | 64 | 70.4 | 4300 | 10923 | 0 |
| Standard_B20ms | 20 | 80 | 88 | 5000 | 13653 | 0 |
Generell användning
De detaljerade specifikationerna för tillgängliga servertyper är följande för tjänstnivån Generell användning
| Beräkningsstorlek | Virtuella kärnor | Fysisk minnesstorlek (GiB) | Total minnesstorlek (GiB) | Maximalt antal IOPS som stöds | Max antal anslutningar | Temp Storage (SSD) GiB |
|---|---|---|---|---|---|---|
| Standard_D2ads_v5 | 2 | 8 | 11 | 3200 | 1365 | 53 |
| Standard_D2ds_v4 | 2 | 8 | 11 | 3200 | 1365 | 53 |
| Standard_D4ads_v5 | 4 | 16 | 22 | 6400 | 2731 | 107 |
| Standard_D4ds_v4 | 4 | 16 | 22 | 6400 | 2731 | 107 |
| Standard_D8ads_v5 | 8 | 32 | 44 | 12800 | 5461 | 215 |
| Standard_D8ds_v4 | 8 | 32 | 44 | 12800 | 5461 | 215 |
| Standard_D16ads_v5 | 16 | 64 | 88 | 20000 | 10923 | 430 |
| Standard_D16ds_v4 | 16 | 64 | 88 | 20000 | 10923 | 430 |
| Standard_D32ads_v5 | 32 | 128 | 176 | 20000 | 21845 | 860 |
| Standard_D32ds_v4 | 32 | 128 | 176 | 20000 | 21845 | 860 |
| Standard_D48ads_v5 | 48 | 192 | 264 | 20000 | 32768 | 1290 |
| Standard_D48ds_v4 | 48 | 192 | 264 | 20000 | 32768 | 1290 |
| Standard_D64ads_v5 | 64 | 256 | 352 | 20000 | 43691 | 1720 |
| Standard_D64ds_v4 | 64 | 256 | 352 | 20000 | 43691 | 1720 |
Affärskritisk
De detaljerade specifikationerna för de tillgängliga servertyperna är följande för Affärskritisk tjänstnivå.
| Beräkningsstorlek | Virtuella kärnor | Fysisk minnesstorlek (GiB) | Total minnesstorlek (GiB) | Maximalt antal IOPS som stöds | Max antal anslutningar | Temp Storage (SSD) GiB |
|---|---|---|---|---|---|---|
| Standard_E2ds_v4 | 2 | 16 | 22 | 5000 | 2731 | 37 |
| Standard_E2ads_v5 | 2 | 16 | 22 | 5000 | 2731 | 37 |
| Standard_E4ds_v4 | 4 | 32 | 44 | 10000 | 5461 | 75 |
| Standard_E4ads_v5 | 4 | 32 | 44 | 10000 | 5461 | 75 |
| Standard_E8ds_v4 | 8 | 64 | 88 | 18000 | 10923 | 151 |
| Standard_E8ads_v5 | 8 | 64 | 88 | 18000 | 10923 | 151 |
| Standard_E16ds_v4 | 16 | 128 | 176 | 28000 | 21845 | 302 |
| Standard_E16ads_v5 | 16 | 128 | 176 | 28000 | 21845 | 302 |
| Standard_E20ds_v4 | 20 | 160 | 220 | 28000 | 27306 | 377 |
| Standard_E20ads_v5 | 20 | 160 | 220 | 28000 | 27306 | 377 |
| Standard_E32ds_v4 | 32 | 256 | 352 | 38000 | 43691 | 604 |
| Standard_E32ads_v5 | 32 | 256 | 352 | 38000 | 43691 | 604 |
| Standard_E48ds_v4 | 48 | 384 | 528 | 48000 | 65536 | 906 |
| Standard_E48ads_v5 | 48 | 384 | 528 | 48000 | 65536 | 906 |
| Standard_E64ds_v4 | 64 | 504 | 693 | 64000 | 86016 | 1224 |
| Standard_E64ads_v5 | 64 | 504 | 693 | 64000 | 86016 | 1224 |
| Standard_E80ds_v4 | 80 | 504 | 693 | 72000 | 86016 | 1224 |
| Standard_E2ds_v5 | 2 | 16 | 22 | 5000 | 2731 | 37 |
| Standard_E4ds_v5 | 4 | 32 | 44 | 10000 | 5461 | 75 |
| Standard_E8ds_v5 | 8 | 64 | 88 | 18000 | 10923 | 151 |
| Standard_E16ds_v5 | 16 | 128 | 176 | 28000 | 21845 | 302 |
| Standard_E20ds_v5 | 20 | 160 | 220 | 28000 | 27306 | 377 |
| Standard_E32ds_v5 | 32 | 256 | 352 | 38000 | 43691 | 604 |
| Standard_E48ds_v5 | 48 | 384 | 528 | 48000 | 65536 | 906 |
| Standard_E64ds_v5 | 64 | 512 | 704 | 64000 | 87383 | 1208 |
| Standard_E96ds_v5 | 96 | 672 | 924 | 80000 | 100000 | 2004 |
Standardzonsresiliens i Azure Database for MySQL – flexibel server Affärskritisk nivå: Från och med mitten av december 2024 kommer alla nya servrar som etableras i Azure Database for MySQL – flexibel server Affärskritisk nivå att levereras med inbyggd zonresiliens – utan extra kostnad! Det innebär att dina data och loggfiler automatiskt lagras på zonredundant lagring, vilket säkerställer snabb återställning efter zonindeliga avbrott. Även utan hög tillgänglighet kan du dra nytta av sömlöst skydd med zonredundanta säkerhetskopior. Läs mer.
Minneshantering i Azure Database for MySQL – flexibel server
I MySQL spelar minnet en viktig roll i olika åtgärder, inklusive frågebearbetning och cachelagring. Azure Database for MySQL – flexibel server optimerar minnesallokering för MySQL-serverprocessen (mysqld), vilket säkerställer att den tar emot tillräckligt med minnesresurser för effektiv frågebearbetning, cachelagring, hantering av klientanslutningar och trådhantering. Läs mer om hur MySQL använder minne.
Fysisk minnesstorlek (GB)
Den fysiska minnesstorleken (GB) i tabellen nedan representerar det tillgängliga ramminnet (Random Access Memory) i gigabyte (GB) på din flexibla Azure Database for MySQL-server.
Total minnesstorlek (GB)
Azure Database for MySQL – flexibel server ger en total minnesstorlek (GB). Detta representerar det totala minnet som är tillgängligt för servern, vilket är en kombination av fysiskt minne och en uppsättning temporära SSD-komponenter för lagring. Den här enhetliga vyn är utformad för att effektivisera resurshanteringen, så att du endast kan fokusera på det totala minne som är tillgängligt för din Azure MySQL Server-process (mysqld). Måttet Minnesprocent (memory_percent) representerar procentandelen minne som upptas av Azure MySQL-serverprocessen (mysqld). Det här måttet beräknas från den totala minnesstorleken (GB). När måttet Minnesprocent till exempel visar värdet 60 innebär det att Azure MySQL Server-processen använder 60 % av den totala minnesstorleken (GB) som är tillgänglig på din flexibla Azure Database for MySQL-server.
MySQL Server (mysqld)
Azure MySQL-serverprocessen mysqld är huvudmotorn för databasåtgärder. Vid start initieras totalt antal komponenter, till exempel InnoDB-buffertpoolen och trådcache, med hjälp av minne baserat på konfigurations- och arbetsbelastningskrav. Till exempel cachelagrar InnoDB-buffertpoolen data och index som används ofta för att förbättra frågekörningshastigheten, medan trådcachen hanterar klientanslutningstrådar. Läs mer.
InnoDB-lagringsmotor
Som MySQL:s standardlagringsmotor använder InnoDB minne för cachelagring av data som används ofta och hanterar interna strukturer som innodb-buffertpoolen och loggbufferten. InnoDB-buffertpoolen innehåller tabelldata och index i minnet för att minimera disk-I/O, vilket förbättrar prestandan. Parametern InnoDB Buffer Pool Size beräknas baserat på den fysiska minnesstorlek (GB) som är tillgänglig på servern. Läs mer om storleken på innoDB-buffertpoolen som är tillgänglig i Azure Database for MySQL – flexibel server.
Trådar
Klientanslutningar hanteras via dedikerade trådar som hanteras av anslutningshanteraren. Dessa trådar hanterar autentisering, frågekörning och resultathämtning för klientinteraktioner. Läs mer.
Mer information om tillgängliga beräkningsserier finns i Dokumentation om virtuella Azure-datorer för B-seriens burstable vm-storlekar, Generell användning Ddsv4-serien i Dadsv5-serien och Affärskritisk Edsv4/Edsv5-serien/Eadsv5-serien.
Prestandabegränsningar för burstbara serieinstanser
Kommentar
Om den virtuella datorn startas/stoppas eller startas om i B-serien kan krediterna gå förlorade om den virtuella datorn startas/stoppas eller startas om. Mer information finns i B-seriens burstable virtual machine sizes (B-seriens burstable virtual machine sizes).
Den burstbara beräkningsnivån är utformad för att tillhandahålla en kostnadseffektiv lösning för arbetsbelastningar som inte kräver kontinuerlig full CPU kontinuerligt. Den här nivån är idealisk för icke-produktionsarbetsbelastningar som utvecklings-, mellanlagrings- eller testmiljöer. Den unika funktionen för den burstable beräkningsnivån är dess förmåga att "burst", det villa att använda mer än sin baslinje CPU-prestanda med upp till 100% av vCPU när arbetsbelastningen kräver det. Detta möjliggörs av en CPU-kreditmodell, som gör det möjligt för B-seriens instanser att ackumulera "CPU-krediter" under perioder med låg CPU-användning. Dessa krediter kan sedan användas under perioder med hög CPU-användning, vilket gör att instansen kan överskrida sin grundläggande CPU-prestanda.
Det är dock viktigt att observera att när en burstbar instans förbrukar sina CPU-krediter fungerar den med sin grundläggande CPU-prestanda. Till exempel är den grundläggande CPU-prestandan för en Standard_B1ms 20 %, det vill säga 0,2 virtuella kärnor. Anta att burstable-nivåservern kör en arbetsbelastning som kräver mer CPU-prestanda än basnivån och har förbrukat sina CPU-krediter. I så fall kan servern uppleva prestandabegränsningar och så småningom påverka olika systemåtgärder som Stop/Start/Restart för servern.
Kommentar
För servrar i B-seriens burstbara storlekar för virtuella datorer, till exempel Standard_B1s/Standard_B1ms/Standard_B2s, deras relativt mindre minnesstorlek för värden, kan det leda till krascher (slut på minne) under kontinuerlig arbetsbelastning, även om måttet memory_percent inte har nått 100 %.
På grund av den här begränsningen kan servern stöta på anslutningsproblem och systemåtgärder kan påverkas. I sådana situationer rekommenderar vi att du pausar arbetsbelastningen på servern för att ackumulera krediter enligt kreditbankmodellen i B-serien, eller att överväga att skala servern till högre nivåer, till exempel Generell användning eller Affärskritisk nivåer.
Även om beräkningsnivån Burstable erbjuder betydande kostnads- och flexibilitetsfördelar för vissa typer av arbetsbelastningar rekommenderas det därför inte för produktionsarbetsbelastningar som kräver konsekvent CPU-prestanda. Nivån Burstable stöder inte funktionerna för att skapa läsrepliker i Azure Database for MySQL – flexibel server och hög tillgänglighet i Azure Database for MySQL – flexibel serverfunktion . Andra beräkningsnivåer, till exempel Generell användning eller Affärskritisk, är lämpligare för sådana arbetsbelastningar och funktioner.
Mer information om Azures processorkreditmodell i B-serien finns i B-seriens burstable virtual machine sizes and B-series CPU credit model (B-seriens burstable virtual machine sizes and B-series CPU credit model).
Övervaka CPU-krediter på burstbar nivå
Att övervaka ditt CPU-kreditsaldo är avgörande för att upprätthålla optimala prestanda på beräkningsnivån Burstable. Azure Database for MySQL – flexibel server innehåller två viktiga mått relaterade till CPU-krediter. Det idealiska tröskelvärdet för att utlösa en avisering beror på dina arbetsbelastnings- och prestandakrav.
Övervaka Azure Database for MySQL – flexibel server: Det här måttet anger antalet CPU-krediter som förbrukas av din instans. Genom att övervaka det här måttet kan du förstå cpu-användningsmönstren för din instans och hantera dess prestanda effektivt.
Övervaka Azure Database for MySQL – flexibel server: Det här måttet visar hur många CPU-krediter som återstår för din instans. Genom att övervaka det här måttet kan du förhindra att din instans försämrar prestandan på grund av att processorkrediterna har förbrukats. Om måttet återstående CPU-kredit sjunker under en viss nivå (till exempel mindre än 30 % av de totala tillgängliga krediterna) skulle detta tyda på att instansen riskerar att förbruka sina CPU-krediter om den aktuella CPU-belastningen fortsätter.
Mer information om hur du konfigurerar aviseringar för mått finns i den här guiden.
Storage
Lagringen som du etablerar är lagringskapaciteten som är tillgänglig för din flexibla server. Lagring används för databasfiler, temporära filer, transaktionsloggar och MySQL-serverloggarna. För burstbar och Generell användning tjänstnivåer sträcker sig lagringsintervallet från minst 20 GiB till högst 16 TiB. Omvänt utökar lagringsstödet upp till 32 TiB för Affärskritisk tjänstnivå. På alla tjänstnivåer skalas lagringen i steg om 1 GiB och kan skalas upp när servern har skapats.
Kommentar
Lagringen kan bara skalas upp, inte ned
Du kan övervaka din lagringsförbrukning i Azure Portal (med Azure Monitor) med hjälp av måtten lagringsgräns, lagringsprocent och lagring som används. Mer information om mått finns i övervakningsartikeln .
Nå lagringsgränsen
När lagringen som förbrukas på servern är nära att nå den etablerade gränsen försätts servern i skrivskyddat läge för att skydda eventuella förlorade skrivningar på servern. Servrar med mindre än 100 GiB-etablerat lagringsutrymme markeras som skrivskyddade om det kostnadsfria lagringsutrymmet är mindre än 5 % av den etablerade lagringsstorleken. Servrar med över 100 GiB-etablerade lagringsutrymmen markeras som skrivskyddade när det kostnadsfria lagringsutrymmet är mindre än 5 GiB.
Om du till exempel har etablerat 110 GiB lagringsutrymme och den faktiska användningen överskrider 105 GiB markeras servern som skrivskyddad. Om du har etablerat 5 GiB lagringsutrymme markeras servern som skrivskyddad när det kostnadsfria lagringsutrymmet når mindre än 256 MB.
Medan tjänsten försöker göra servern skrivskyddad blockeras alla nya skrivtransaktionsbegäranden och befintliga aktiva transaktioner fortsätter att köras. När servern är inställd på skrivskyddad misslyckas alla efterföljande skrivåtgärder och transaktionsincheckningar, men läsfrågor fortsätter att fungera oavbrutet.
Öka den etablerade lagringen på servern för att inaktivera det skrivskyddade läget. Du kan göra detta i Microsoft Azure-portalen eller Azure CLI. När den har ökat är servern redo att acceptera skrivtransaktioner igen.
Vi rekommenderar att du konfigurerar en avisering för att meddela dig när serverlagringen närmar sig tröskelvärdet så att du kan undvika att hamna i skrivskyddat tillstånd. Mer information finns i dokumentationen om aviseringsdokumentationen om hur du konfigurerar en avisering.
Automatisk lagringsbrytning
Automatisk lagringsväxning hindrar servern från att få slut på lagring och blir skrivskyddad. Om automatisk ökning av lagring är aktiverat växer lagringen automatiskt utan att påverka arbetsbelastningen. Automatisk lagringsbrytning är aktiverat som standard för alla nya serverskapanden. För servrar med mindre än 100 GB etablerat lagringsutrymme ökas den etablerade lagringsstorleken med 5 GB när det kostnadsfria lagringsutrymmet är under 10 % av det etablerade lagringsutrymmet. För servrar med mer än 100 GB allokerat lagringsutrymme ökas den allokerade lagringsstorleken med 5 % när det lediga lagringsutrymmet är mindre än 10 GB av den allokerade lagringsstorleken. Maximala lagringsgränser enligt informationen ovan gäller. Uppdatera serverinstansen för att se det uppdaterade lagringsutrymmet som etablerats under Inställningar på sidan Beräkning + lagring.
Om du till exempel har etablerat 1 000 GB lagringsutrymme och den faktiska användningen överstiger 990 GB ökas serverlagringsstorleken till 1 050 GB. Om du har etablerat 20 GB lagringsutrymme ökar du också lagringsstorleken till 25 GB när mindre än 2 GB lagringsutrymme är ledigt.
Kom ihåg att lagring, när den har skalats upp automatiskt, inte kan skalas ned.
Kommentar
Automatisk lagringsbrytning är aktiverat som standard för en konfigurerad server med hög tillgänglighet och kan inte inaktiveras.
IOPS
Azure Database for MySQL – flexibel server stöder företablerad IOPS och autoskalning av IOPS. Lagrings-IOPS i Azure Database for MySQL – flexibel server Den minsta IOPS är 360 för alla beräkningsstorlekar, och den maximala IOPS bestäms av den valda beräkningsstorleken. Mer information om maximal IOPS per beräkningsstorlek finns i tabellen.
Viktigt!
**Minsta IOPS är 360 för alla beräkningsstorlekar
**Maximal IOPS bestäms av den valda beräkningsstorleken.
Du kan övervaka din I/O-förbrukning i Azure Portal (med Azure Monitor) med hjälp av måttet Övervaka Azure Database for MySQL – flexibel server. Du måste skala serverns beräkning om du behöver mer IOPS än det maximala IOPS-värde som baseras på beräkning.
Företablerad IOPS
Azure Database for MySQL – flexibel server erbjuder företablerad IOPS, så att du kan allokera ett visst antal IOPS till din flexibla Azure Database for MySQL-serverinstans. Den här inställningen garanterar konsekventa och förutsägbara prestanda för dina arbetsbelastningar. Med företablerad IOPS kan du definiera en specifik IOPS-gräns för din lagringsvolym, vilket garanterar möjligheten att hantera vissa begäranden per sekund. Detta resulterar i en tillförlitlig och säker prestandanivå. Med företablerad IOPS kan du etablera ytterligare IOPS över IOPS-gränsen. Med den här funktionen kan du när som helst öka eller minska antalet IOPS som tillhandahålls baserat på dina arbetsbelastningskrav.
Autoskalning av IOPS
Hörnstenen i en flexibel Azure Database for MySQL-server är dess förmåga att uppnå bästa möjliga prestanda för arbetsbelastningar på nivå 1. Detta kan förbättras genom att göra det möjligt för servern att automatiskt skala sina databasservrars prestanda (I/O) sömlöst beroende på arbetsbelastningens behov. Med den här funktionen kan användare skala IOPS på begäran utan att behöva etablera en viss mängd I/O per sekund. Med funktionen Autoskala IOPS aktiverad kan du nu njuta av bekymmersfri I/O-hantering i Azure Database for MySQL – flexibel server eftersom servern skalar upp eller ned IOPS automatiskt beroende på arbetsbelastningsbehov. Autoskala IOPS skalas automatiskt upp till "Max IOPS som stöds" för varje tjänstnivå och beräkningsstorlek, enligt vad som anges i dokumentationen om tjänstnivåer. Detta säkerställer optimala prestanda utan att behöva göra manuell skalning
Med autoskalnings-IOPS betalar du bara för den I/O som servern använder och behöver inte längre etablera och betala för resurser som de inte använder fullt ut, vilket sparar tid och pengar. Dessutom kan verksamhetskritiska nivå 1-program uppnå konsekventa prestanda genom att göra ytterligare I/O tillgängligt för arbetsbelastningen när som helst. Autoskalning av IOPS eliminerar den administration som krävs för att ge bästa möjliga prestanda till lägsta kostnad för kunder med flexibel Azure Database for MySQL-server.
Dynamisk skalning: IOPS för autoskalning justerar dynamiskt databasserverns IOPS-gräns baserat på din arbetsbelastnings faktiska efterfrågan. Detta säkerställer optimala prestanda utan manuella åtgärder eller konfiguration.
Hantering av arbetsbelastningstoppar: Med autoskalnings-IOPS kan din databas smidigt hantera arbetsbelastningstoppar eller fluktuationer utan att äventyra programmets prestanda. Den här funktionen säkerställer konsekvent svarstid även under perioder med hög användning.
Kostnadsbesparingar: Till skillnad från den företablerade IOPS, som anger en fast IOPS-gräns och betalas för oavsett användning, kan du med autoskalnings-IOPS endast betala för det antal I/O-åtgärder som du använder.
Backup
Tjänsten säkerhetskopierar automatiskt servern. Du kan välja en kvarhållningsperiod på 1 till 35 dagar. Läs mer om säkerhetskopior i artikeln om säkerhetskopiering och återställning.
Skala resurser
När du har skapat servern kan du oberoende ändra beräkningsnivå, beräkningsstorlek (virtuella kärnor och minne), lagringsmängd och kvarhållningsperiod för säkerhetskopiering. Beräkningsstorleken kan skalas upp eller ned och kvarhållningsperioden för säkerhetskopior kan skalas upp eller ned från 1 till 35 dagar. Lagringsstorleken kan bara ökas. Du kan skala resurserna via portalen eller Azure CLI.
Kommentar
Lagringsstorleken kan bara ökas. Du kan inte gå tillbaka till en mindre lagringsstorlek efter ökningen.
När du ändrar beräkningsnivån eller beräkningsstorleken måste servern startas om för att den nya servertypen ska börja gälla. När systemet växlar över till den nya servern går det inte att upprätta några nya anslutningar och alla ogenomförda transaktioner återställs. Det här fönstret varierar, men i de flesta fall är det mellan 60 och 120 sekunder.
Skalning av lagring och ändring av kvarhållningsperioden för säkerhetskopior är onlineåtgärder och kräver ingen omstart av servern.
Pris
Den senaste prisinformationen finns på sidan med tjänstpriser. Om du vill se kostnaden för den konfiguration du vill ha visar Azure Portal månadskostnaden på fliken Beräkning + lagring baserat på de alternativ du väljer. Om du inte har en Azure-prenumeration kan du använda priskalkylatorn för Azure för att få ett uppskattat pris. På webbplatsen för Priskalkylatorn för Azure väljer du Lägg till objekt, expanderar kategorin Databaser, väljer Azure Database for MySQL och Flexibel server som distributionstyp för att anpassa alternativen.
Om du vill optimera serverkostnaden kan du överväga följande tips:
- Skala ned beräkningsnivån eller beräkningsstorleken (virtuella kärnor) om beräkningen är underutnyttad.
- Överväg att byta till beräkningsnivån Burstable om din arbetsbelastning inte behöver den fullständiga beräkningskapaciteten kontinuerligt från nivåerna Generell användning och Affärskritisk.
- Stoppa servern när den inte används.
- Minska kvarhållningsperioden för säkerhetskopior om en längre kvarhållning av säkerhetskopian inte krävs.