Azure Database for MySQL Flexibele server Serviceniveaus

VAN TOEPASSING OP: Azure Database for MySQL - Flexibele server

U kunt een exemplaar van een flexibele Azure Database for MySQL-server maken in een van de drie verschillende servicelagen: Burstable, Algemeen gebruik en Bedrijfskritiek. De servicelagen worden onderscheiden door de onderliggende VM-SKU die gebruikmaakt van B-serie, D-serie en E-serie. De keuze van de rekenlaag en -grootte bepaalt het geheugen en de vCores die beschikbaar zijn op de server. Dezelfde opslagtechnologie wordt gebruikt in alle servicelagen. Alle resources worden ingericht op het niveau van de flexibele Server-instantie van Azure Database for MySQL. Een server kan een of meer databases hebben.

Resource/laag Burstable Algemeen doel Bedrijfskritiek
VM-reeks B-serie Dadsv5-serie Ddsv4-serie Edsv4 Edsv5-serie*/Eadsv5-serie/
vCores 1, 2, 4, 8, 12, 16, 20 2, 4, 8, 16, 32, 48, 64 2, 4, 8, 16, 32, 48, 64, 80, 96
Geheugen per vCore Variabel 4 GiB 8 GiB **
Opslaggrootte 20 GiB tot 16 TiB 20 GiB tot 16 TiB 20 GiB tot 16 TiB
Bewaarperiode voor databaseback-ups 1 tot 35 dagen 1 tot 35 dagen 1 tot 35 dagen

** Met uitzondering van respectievelijk 64.80 en 96 vCores met 504 GiB, 504 GiB en 672 GiB.

* Ev5 compute biedt de beste prestaties onder andere VM-serie in termen van QPS en latentie. meer informatie over de prestaties en de beschikbaarheid van regio's van Ev5 compute vindt u hier.

Als u een rekenlaag wilt kiezen, gebruikt u de volgende tabel als uitgangspunt.

Compute-laag Beoogde workloads
Met burstfunctie Het meest geschikt voor workloads die niet continu de volledige CPU nodig hebben.
Algemeen gebruik De meeste zakelijke workloads die een evenwichtige rekenkracht en geheugen nodig hebben met schaalbare I/O-doorvoer. Voorbeelden zijn onder meer servers voor het hosten van web- en mobiele apps en andere zakelijke toepassingen.
Bedrijfskritiek Databaseworkloads met hoge prestaties die prestaties in het geheugen vereisen voor snellere transactieverwerking en hogere gelijktijdigheid. Voorbeelden zijn onder meer servers voor het verwerken van realtime gegevens en transactionele of analytische toepassingen met hoge prestaties.

Nadat u een server hebt gemaakt, kunnen de rekenlaag, de rekengrootte en de opslaggrootte worden gewijzigd. Voor het schalen van rekenkracht is opnieuw opstarten vereist en duurt het 60-120 seconden, terwijl het schalen van opslag niet opnieuw hoeft te worden opgestart. U kunt de bewaarperiode voor back-ups ook onafhankelijk van elkaar aanpassen. Zie de sectie Resources schalen voor meer informatie.

Servicelagen, grootte en servertypen

Rekenresources kunnen worden geselecteerd op basis van de laag en grootte. Hiermee bepaalt u de vCores en de geheugengrootte. vCores vertegenwoordigen de logische CPU van de onderliggende hardware.

De gedetailleerde specificaties van de beschikbare servertypen zijn als volgt:

Grootte berekenen vCores Geheugengrootte (GiB) Maximaal aantal ondersteunde IOPS Maximum aantal verbindingen Temp Storage (SSD) GiB
Burstable
Standard_B1s 1 1 320 171 4
Standard_B1ms 1 2 640 341 4
Standard_B2s 2 4 1280 683 4
Standard_B2ms 2 8 1700 1365 16
Standard_B4ms 4 16 2400 2731 32
Standard_B8ms 8 32 3100 5461 64
Standard_B12ms 12 48 3800 8193 96
Standard_B16ms 16 64 4300 10923 128
Standard_B20ms 20 80 5000 13653 160
Algemeen doel
Standard_D2ads_v5 2 8 3200 1365 75
Standard_D2ds_v4 2 8 3200 1365 75
Standard_D4ads_v5 4 16 6400 2731 150
Standard_D4ds_v4 4 16 6400 2731 150
Standard_D8ads_v5 8 32 12800 5461 300
Standard_D8ds_v4 8 32 12800 5461 300
Standard_D16ads_v5 16 64 20000 10923 600
Standard_D16ds_v4 16 64 20000 10923 600
Standard_D32ads_v5 32 128 20000 21845 1200
Standard_D32ds_v4 32 128 20000 21845 1200
Standard_D48ads_v5 48 192 20000 32768 1800
Standard_D48ds_v4 48 192 20000 32768 1800
Standard_D64ads_v5 64 256 20000 43691 2400
Standard_D64ds_v4 64 256 20000 43691 2400
Bedrijfskritiek
Standard_E2ds_v4 2 16 5000 2731 75
Standard_E2ads_v5 2 16 5000 2731 75
Standard_E4ds_v4 4 32 10000 5461 150
Standard_E4ads_v5 4 32 10000 5461 150
Standard_E8ds_v4 8 64 18.000 10923 300
Standard_E8ads_v5 8 64 18.000 10923 300
Standard_E16ds_v4 16 128 28000 21845 600
Standard_E16ads_v5 16 128 28000 21845 600
Standard_E20ds_v4 20 160 28000 27306 750
Standard_E20ads_v5 20 160 28000 27306 750
Standard_E32ds_v4 32 256 38000 43691 1200
Standard_E32ads_v5 32 256 38000 43691 1200
Standard_E48ds_v4 48 384 48000 65536 1800
Standard_E48ads_v5 48 384 48000 65536 1800
Standard_E64ds_v4 64 504 64000 86016 2400
Standard_E64ads_v5 64 504 64000 86016 2400
Standard_E80ids_v4 80 504 72000 86016 2400
Standard_E2ds_v5 2 16 5000 2731 75
Standard_E4ds_v5 4 32 10000 5461 150
Standard_E8ds_v5 8 64 18.000 10923 300
Standard_E16ds_v5 16 128 28000 21845 600
Standard_E20ds_v5 20 160 28000 27306 750
Standard_E32ds_v5 32 256 38000 43691 1200
Standard_E48ds_v5 48 384 48000 65536 1800
Standard_E64ds_v5 64 512 64000 87383 2400
Standard_E96ds_v5 96 672 80.000 100000 3600

Raadpleeg de Documentatie voor Azure VM voor Burstable (B-serie), De Ddsv5-serieDdsv4-serie algemeen gebruik en Bedrijfskritiek Edsv4-serie/Eadsv5-serie/voor meer informatie over de beschikbare rekenreeks

Notitie

Voor de rekenlaag Burstable (B-serie) als de VM wordt gestart/gestopt of opnieuw wordt opgestart, kan het tegoed verloren gaan. Zie Veelgestelde vragen over Burstable (B-serie) voor meer informatie.

Prestatiebeperkingen van burstable-reeksexemplaren

Burstable compute-laag is ontworpen om een rendabele oplossing te bieden voor workloads waarvoor continu volledige CPU niet continu nodig is. Deze laag is ideaal voor niet-productieworkloads, zoals ontwikkel-, faserings- of testomgevingen. De unieke functie van de burstable compute-laag is de mogelijkheid om te 'bursten', dat wil gezegd, om meer dan de cpu-prestaties volgens de basislijn te gebruiken met maximaal 100% van de vCPU wanneer de workload dit vereist. Dit wordt mogelijk gemaakt door een CPU-tegoedmodel, waarmee instanties van B-serie 'CPU-tegoeden' kunnen verzamelen tijdens perioden met een laag CPU-gebruik. Deze tegoeden kunnen vervolgens worden besteed tijdens perioden van hoog CPU-gebruik, zodat het exemplaar kan pieken boven de basis-CPU-prestaties.

Het is echter belangrijk om te weten dat wanneer een burstable exemplaar zijn CPU-tegoed verbruikt, het werkt met de basis-CPU-prestaties. De basis-CPU-prestaties van een Standard_B1ms bijvoorbeeld 20% is, namelijk 0,2 Vcore. Als de server met burstable-lagen een workload uitvoert waarvoor meer CPU-prestaties zijn vereist dan het basisniveau en het CPU-tegoed is uitgeput, kan de server prestatiebeperkingen ondervinden en uiteindelijk verschillende systeembewerkingen, zoals Stoppen/Starten/Opnieuw opstarten voor uw server, beïnvloeden.

Notitie

Voor servers in de rekenlaag Burstable (B-serie), zoals Standard_B1s/Standard_B1ms/Standard_B2s, kan hun relatief kleinere hostgeheugengrootte leiden tot crashes (onvoldoende geheugen) onder een aaneengesloten werkbelasting, zelfs als de metrische gegevens van memory_percent niet 100% hebben bereikt.

Vanwege deze beperking kan de server verbindingsproblemen ondervinden en kunnen systeembewerkingen worden beïnvloed. In dergelijke situaties is het raadzaam om de werkbelasting op de server te onderbreken om tegoeden te verzamelen volgens het kredietbankmodel van de B-serie of om de server te schalen naar hogere lagen, zoals Algemeen gebruik of Bedrijfskritiek lagen.

Daarom biedt de Burstable-rekenlaag aanzienlijke kosten- en flexibiliteitsvoordelen voor bepaalde typen workloads, wordt het niet aanbevolen voor productieworkloads die consistente CPU-prestaties vereisen. De Burstable-laag biedt geen ondersteuning voor functionaliteit voor het maken van leesreplica's en functie voor hoge beschikbaarheid . Voor dergelijke workloads en functies zijn andere rekenlagen, zoals algemeen gebruik of Bedrijfskritiek beter geschikt.

Zie het B-serie CPU-tegoedmodel van de B-serie voor meer informatie over het cpu-kredietmodel van de B-serie en het cpu-kredietmodel uit de B-serie.

CPU-tegoed bewaken in burstable-laag

Het bewaken van uw CPU-tegoedsaldo is van cruciaal belang voor het handhaven van optimale prestaties in de Burstable-rekenlaag. Azure Database for MySQL Flexible Server biedt twee belangrijke metrische gegevens met betrekking tot CPU-tegoed. De ideale drempelwaarde voor het activeren van een waarschuwing is afhankelijk van uw specifieke workload- en prestatievereisten.

VERBRUIKT CPU-tegoed: deze metrische waarde geeft het aantal CPU-tegoed aan dat door uw exemplaar wordt verbruikt. Door deze metrische gegevens te bewaken, krijgt u inzicht in de CPU-gebruikspatronen van uw exemplaar en kunt u de prestaties effectief beheren.

RESTEREND CPU-tegoed: deze metrische waarde toont het aantal RESTERENDE CPU-tegoeden voor uw exemplaar. Door deze metrische gegevens in de gaten te houden, kunt u voorkomen dat uw exemplaar de prestaties verslechtert vanwege het uitputten van het CPU-tegoed. Als het resterende CPU-tegoed lager is dan een bepaald niveau (bijvoorbeeld minder dan 30% van het totale beschikbare tegoed), geeft dit aan dat het exemplaar het risico loopt dat het CPU-tegoed wordt uitgeput als de huidige CPU-belasting wordt voortgezet.

Raadpleeg deze handleiding voor meer informatie over het instellen van waarschuwingen voor metrische gegevens.

Storage

Deze opslagruimte die u inricht, is de hoeveelheid opslagcapaciteit die beschikbaar is voor uw flexibele server. Opslag wordt gebruikt voor de databasebestanden, tijdelijke bestanden, transactielogboeken en de MySQL-serverlogboeken. In alle servicelagen is de minimale opslag die wordt ondersteund 20 GiB en max. 16 TiB. Opslag wordt in stappen van 1 GiB geschaald en kan omhoog worden geschaald nadat de server is gemaakt.

Notitie

Opslag kan alleen omhoog en niet omlaag worden geschaald.

U kunt uw opslagverbruik bewaken in Azure Portal (met Azure Monitor) met behulp van de opslaglimiet, het opslagpercentage en de metrische gegevens over gebruikte opslag. Raadpleeg het bewakingsartikel voor meer informatie over metrische gegevens.

De opslaglimiet wordt bereikt

Wanneer deze opslag die wordt verbruikt op de server bijna de ingerichte limiet bereikt, wordt de server in de modus Alleen-lezen geplaatst om verloren schrijfbewerkingen op de server te beveiligen. Servers met minder dan 100 ingerichte GiB-opslag zijn gemarkeerd als alleen-lezen als de gratis opslag kleiner is dan 5% van de ingerichte opslaggrootte. Servers met meer dan 100 ingerichte GiB-opslag worden als alleen-lezen gemarkeerd wanneer de gratis opslag kleiner is dan 5 GiB.

Als u bijvoorbeeld 110 GiB van opslag hebt ingericht en het werkelijke gebruik meer dan 105 GiB is, wordt de server gemarkeerd als alleen-lezen. Als u 5 GiB aan opslagruimte hebt ingericht, wordt de server ook gemarkeerd als alleen-lezen wanneer de gratis opslag minder dan 256 MB bereikt.

Terwijl de service probeert om de server alleen-lezen te maken, worden alle nieuwe transactieaanvragen voor schrijven geblokkeerd en worden bestaande actieve transacties verder uitgevoerd. Indien de server op alleen-lezen is ingesteld, zullen alle daaropvolgende schrijfbewerkingen en transactiedoorvoeringen mislukken. Leesquery’s blijven gewoon werken.

Als u deze server uit de modus Alleen-lezen wilt halen, moet u de ingerichte opslag op de server verhogen. U kunt dit doen via de Azure-portal of Azure CLI. Zodra dit is verhoogd, is de server klaar om schrijftransacties opnieuw te accepteren.

U wordt aangeraden een waarschuwing in te stellen om u op de hoogte te stellen wanneer uw serveropslag de drempelwaarde nadert, zodat u de status Alleen-lezen kunt voorkomen. Zie de documentatie over waarschuwingsdocumentatie voor het instellen van een waarschuwing voor meer informatie.

Automatisch vergroten van opslag

Automatische groei van opslag voorkomt dat uw server geen opslagruimte meer heeft en alleen-lezen wordt. Als automatische groei van opslag is ingeschakeld, groeit de opslag automatisch zonder dat dit van invloed is op de werkbelasting. Automatische groei van opslag is standaard ingeschakeld voor alle nieuwe servers. Voor servers met minder dan 100 GB ingerichte opslag wordt de ingerichte opslaggrootte met 5 GB verhoogd wanneer de gratis opslag lager is dan 10% van de ingerichte opslag. Voor servers met ingerichte opslag van meer dan 100 GB wordt de ingerichte opslag met 5% verhoogd zodra de vrije opslag lager is dan 10 GB van de ingerichte opslag (welke groter is). De hierboven gespecificeerde maximale opslaglimieten zijn van toepassing. Vernieuw serverexemplaren om de bijgewerkte opslag te zien die is ingericht onder Instellingen op de pagina Compute + Storage .

Als u bijvoorbeeld 1000 GB opslagruimte hebt ingericht en het werkelijke gebruik hoger is dan 990 GB, wordt de opslaggrootte van de server verhoogd tot 1050 GB. Als u 20 GB opslagruimte hebt ingericht, wordt de opslaggrootte ook verhoogd naar 25 GB wanneer minder dan 2 GB aan opslagruimte gratis is.

Houd er rekening mee dat opslag na automatisch omhoog schalen niet omlaag kan worden geschaald.

Notitie

Automatische groei van opslag is standaard ingeschakeld voor een geconfigureerde server met hoge beschikbaarheid en kan niet worden uitgeschakeld.

IOPS

Flexibele Azure Database for MySQL-server ondersteunt vooraf ingerichte IOPS en IOPS voor automatische schaalaanpassing. Meer informatie. De minimale IOPS zijn 360 voor alle rekengrootten en de maximale IOPS wordt bepaald door de geselecteerde rekenkracht. Raadpleeg de tabel voor meer informatie over de maximale IOPS per rekengrootte.

Belangrijk

**Minimale IOPS zijn 360 voor alle rekengrootten
**Maximale IOPS worden bepaald door de geselecteerde rekenkracht.

U kunt uw I/O-verbruik bewaken in Azure Portal (met Azure Monitor) met behulp van het metrische io-percentage . Als u meer IOPS nodig hebt dan de maximale IOPS op basis van rekenkracht, moet u de rekenkracht van uw server schalen.

Vooraf ingerichte IOPS

Flexibele Azure Database for MySQL-server biedt vooraf ingerichte IOPS, zodat u een specifiek aantal IOPS kunt toewijzen aan uw flexibele Azure Database for MySQL-serverexemplaren. Deze instelling zorgt voor consistente en voorspelbare prestaties voor uw workloads. Met vooraf ingerichte IOPS kunt u een specifieke IOPS-limiet definiëren voor uw opslagvolume, waardoor u een bepaald aantal aanvragen per seconde kunt verwerken. Dit resulteert in een betrouwbaar en verzekerd prestatieniveau. Met vooraf ingerichte IOPS kunt u extra IOPS inrichten boven de IOPS-limiet. Met deze functie kunt u ook op elk gewenst moment het aantal ingerichte IOPS verhogen of verlagen op basis van de workloadvereisten.

IOPS automatisch schalen

De hoeksteen van flexibele Azure Database for MySQL-server is de mogelijkheid om de beste prestaties te bereiken voor workloads van laag 1. Dit kan worden verbeterd door de server automatisch de prestaties van de databaseservers te laten schalen, afhankelijk van de behoeften van de werkbelasting. Dit is een opt-in-functie waarmee gebruikers IOPS op aanvraag kunnen schalen zonder een bepaalde hoeveelheid IO per seconde vooraf in te richten. Als de functie IOPS voor automatische schaalaanpassing is ingeschakeld, kunt u nu genieten van zorgeloos IO-beheer in Azure Database for MySQL flexibele server, omdat de server IOPS automatisch omhoog of omlaag schaalt, afhankelijk van de behoeften van de werkbelasting.

Met IOPS voor automatische schaalaanpassing betaalt u alleen voor de I/O die de server gebruikt en hoeft u deze niet meer in te richten en te betalen voor resources die ze niet volledig gebruiken, wat tijd en geld bespaart. Bovendien kunnen bedrijfskritieke Laag-1-toepassingen consistente prestaties bereiken door op elk gewenst moment extra IO beschikbaar te maken voor de workload. IOPS voor automatische schaalaanpassing elimineert het beheer dat nodig is om de beste prestaties te bieden voor klanten met flexibele Azure Database for MySQL-servers.

Dynamisch schalen: IOPS automatisch schalen past de IOPS-limiet van uw databaseserver dynamisch aan op basis van de werkelijke vraag van uw workload. Dit zorgt voor optimale prestaties zonder handmatige tussenkomst of configuratie.

Workloadpieken verwerken: met IOPS voor automatische schaalaanpassing kan uw database probleemloos werkbelastingpieken of -fluctuaties afhandelen zonder de prestaties van uw toepassingen in gevaar te brengen. Deze functie zorgt voor consistente reactiesnelheid, zelfs tijdens piekperioden van het gebruik.

Kostenbesparingen: In tegenstelling tot de vooraf ingerichte IOPS waarbij een vaste IOPS-limiet wordt opgegeven en betaald, ongeacht het gebruik, kunt u met IOPS voor automatische schaalaanpassing alleen betalen voor het aantal I/O-bewerkingen dat u gebruikt.

Backup

De service maakt automatisch back-ups van uw server. U kunt een bewaarperiode selecteren van een bereik van 1 tot 35 dagen. Meer informatie over back-ups in het artikel over back-up- en herstelconcepten.

Resources schalen

Nadat u de server hebt gemaakt, kunt u de rekenlaag, de rekengrootte (vCores en het geheugen) en de hoeveelheid opslagruimte en de bewaarperiode voor back-ups onafhankelijk wijzigen. De rekenkracht kan omhoog of omlaag worden geschaald. De bewaarperiode voor back-ups kan tussen 1 en 35 dagen omhoog of omlaag worden geschaald. De opslaggrootte kan alleen worden verhoogd. Het schalen van de resources kan worden uitgevoerd via de portal of Azure CLI.

Notitie

De opslaggrootte kan alleen worden verhoogd. U kunt niet teruggaan naar een kleinere opslaggrootte na de toename.

Wanneer u de rekenlaag of de rekengrootte wijzigt, wordt de server opnieuw opgestart zodat het nieuwe servertype van kracht wordt. Op het moment dat het systeem overschakelt naar de nieuwe server, kunnen er geen nieuwe verbindingen worden vastgelegd en worden alle niet-doorgevoerde transacties teruggedraaid. Dit venster varieert, maar in de meeste gevallen ligt dit tussen 60 en 120 seconden.

Het schalen van opslag en het wijzigen van de bewaarperiode voor back-ups zijn onlinebewerkingen en vereisen geen server opnieuw opstarten.

Prijzen

Zie de pagina met serviceprijzen voor de meest recente prijsinformatie. Als u de gewenste kosten voor de gewenste configuratie wilt zien, worden in Azure Portal de maandelijkse kosten weergegeven op het tabblad Compute en opslag op basis van de opties die u selecteert. Als u geen Azure-abonnement hebt, kunt u de Azure-prijscalculator gebruiken om een geschatte prijs op te halen. Selecteer op de website van de Azure-prijscalculator items toevoegen, vouw de categorie Databases uit, kies Azure Database for MySQL en Flexible Server als het implementatietype om de opties aan te passen.

Als u de serverkosten wilt optimaliseren, kunt u de volgende tips overwegen:

  • Schaal uw rekenlaag of rekenkracht (vCores) omlaag als de rekenkracht te weinig wordt gebruikt.
  • Overweeg over te schakelen naar de Burstable-rekenlaag als uw workload de volledige rekencapaciteit niet continu nodig heeft vanuit de lagen Algemeen gebruik en Bedrijfskritiek.
  • Stop de server wanneer deze niet in gebruik is.
  • Verminder de bewaarperiode voor back-ups als een langere retentie van back-ups niet is vereist.

Volgende stappen