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 servicelagen: Burstable, Algemeen gebruik en Bedrijfskritiek. De onderliggende VM-SKU onderscheidt de servicelagen die worden gebruikt voor B-serie, D-serie en E-serie. De rekenlaag en groottekeuze bepaalt het geheugen en de vCores die beschikbaar zijn op de server. De exacte 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 grootte virtuele machine met burstmogelijkheden | 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 32 TiB |
| Bewaarperiode voor databaseback-ups | 1 tot 35 dagen | 1 tot 35 dagen | 1 tot 35 dagen |
** Behalve 64.80 en 96 vCores, die respectievelijk 504 GiB, 504 GiB en 672 GiB van geheugen hebben.
* Ev5 compute presteert het beste onder andere VM-serie met betrekking tot QPS en latentie. Meer informatie over de prestaties en regio-beschikbaarheid van Ev5 compute vindt u hier.
Servicelagen voor flexibele server
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 continu niet de volledige CPU nodig hebben. |
| Algemeen gebruik | De meeste zakelijke workloads vereisen evenwichtige computing en geheugen 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, kunt u de rekenlaag, de rekengrootte en de opslaggrootte wijzigen. Voor het schalen van berekeningen is opnieuw opstarten vereist en duurt het 60-120 seconden, terwijl het schalen van opslag niet werkt. 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.
Met burstfunctie
De gedetailleerde specificaties van de beschikbare servertypen zijn als volgt voor de Burstable-servicelaag.
| Grootte berekenen | vCores | Grootte van fysiek geheugen (GiB) | Totale geheugengrootte (GiB) | Maximaal aantal ondersteunde IOPS | Maximum aantal verbindingen | Temp Storage (SSD) GiB |
|---|---|---|---|---|---|---|
| Standard_B1s | 1 | 1 | 1.1 | 320 | 171 | 0 |
| Standard_B1ms | 1 | 2 | 2.2 | 640 | 341 | 0 |
| Standard_B2s | 2 | 4 | 4.4 | 1280 | 683 | 0 |
| Standard_B2ms | 2 | 8 | 8.8 | 1700 | 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 |
Algemeen gebruik
De gedetailleerde specificaties van de beschikbare servertypen zijn als volgt voor de servicelaag Algemeen gebruik
| Grootte berekenen | vCores | Grootte van fysiek geheugen (GiB) | Totale geheugengrootte (GiB) | Maximaal aantal ondersteunde IOPS | Maximum aantal verbindingen | 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 |
Bedrijfskritiek
De gedetailleerde specificaties van de beschikbare servertypen zijn als volgt voor de Bedrijfskritiek servicelaag.
| Grootte berekenen | vCores | Grootte van fysiek geheugen (GiB) | Totale geheugengrootte (GiB) | Maximaal aantal ondersteunde IOPS | Maximum aantal verbindingen | 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 | 18.000 | 10923 | 151 |
| Standard_E8ads_v5 | 8 | 64 | 88 | 18.000 | 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_E80ids_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 | 18.000 | 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 | 80.000 | 100000 | 2004 |
Geheugenbeheer in flexibele Azure Database for MySQL-server
In MySQL speelt geheugen een belangrijke rol in verschillende bewerkingen, waaronder queryverwerking en caching. Azure Database for MySQL flexibele server optimaliseert de geheugentoewijzing voor het MySQL-serverproces (mysqld), zodat deze voldoende geheugenbronnen ontvangt voor efficiënte queryverwerking, caching, clientverbindingsbeheer en threadverwerking. Meer informatie over hoe MySQL geheugen gebruikt.
Grootte van fysiek geheugen (GB)
De grootte van het fysieke geheugen (GB) in de onderstaande tabel vertegenwoordigt het beschikbare RAM-geheugen (random access memory) in gigabytes (GB) op uw flexibele Azure Database for MySQL-server.
Totale geheugengrootte (GB)
Azure Database for MySQL flexibele server biedt een totale geheugengrootte (GB). Dit vertegenwoordigt het totale geheugen dat beschikbaar is voor uw server. Dit is een combinatie van fysiek geheugen en een vaste hoeveelheid tijdelijke opslag-SSD-onderdelen. Deze uniforme weergave is ontworpen om resourcebeheer te stroomlijnen, zodat u zich alleen kunt richten op het totale geheugen dat beschikbaar is voor uw Azure MySQL Server-proces (mysqld). Het metrische geheugenpercentage (memory_percent) vertegenwoordigt het percentage geheugen dat wordt gebruikt door het Azure MySQL-serverproces (mysqld). Deze metrische waarde wordt berekend op basis van de totale geheugengrootte (GB). Wanneer de metrische waarde geheugenpercentage bijvoorbeeld een waarde van 60 weergeeft, betekent dit dat uw Azure MySQL-serverproces 60% van de totale geheugengrootte (GB) gebruikt die beschikbaar is op uw flexibele Azure Database for MySQL-server.
MySQL-server (mysqld)
Het Azure MySQL-serverproces, mysqld, is de kernengine voor databasebewerkingen. Bij het opstarten initialiseert het totale aantal onderdelen, zoals de InnoDB-buffergroep en threadcache, waarbij geheugen wordt gebruikt op basis van de configuratie- en workloadvereisten. De InnoDB-buffergroep slaat bijvoorbeeld vaak gebruikte gegevens en indexen in de cache op om de uitvoeringssnelheid van query's te verbeteren, terwijl de threadcache clientverbindingsthreads beheert. Meer informatie.
InnoDB-opslagengine
Omdat de standaardopslagengine van MySQL wordt gebruikt, gebruikt InnoDB geheugen voor het opslaan van veelgebruikte gegevens in de cache en het beheren van interne structuren zoals de innodb-buffergroep en logboekbuffer. InnoDB-buffergroep bevat tabelgegevens en indexen in het geheugen om de I/O van de schijf te minimaliseren, waardoor de prestaties worden verbeterd. De parameter InnoDB-buffergroepgrootte wordt berekend op basis van de fysieke geheugengrootte (GB) die beschikbaar is op de server. Meer informatie over de grootten van de InnoDB-buffergroep die beschikbaar is in Azure Database for MySQL Flexibele server.
Threads
Clientverbindingen worden beheerd via toegewezen threads die worden verwerkt door de verbindingsbeheerder. Deze threads verwerken verificatie, het uitvoeren van query's en het ophalen van resultaten voor clientinteracties. Meer informatie.
Voor meer informatie over de beschikbare rekenreeks raadpleegt u de Documentatie voor Virtuele Machines uit de B-serie voor burstable virtuele machines uit de B-serie, de Ddsv4-serie algemeen gebruik, en Bedrijfskritiek Edsv4/Edsv5-serie/Eadsv5-serie.
Prestatiebeperkingen van burstable-reeksexemplaren
Notitie
Voor burstable vm-grootten uit de B-serie, als de virtuele machine wordt gestart/gestopt of opnieuw wordt opgestart, kan het tegoed verloren gaan. Zie voor meer informatie de grootten van burstable virtuele machines uit de B-serie.
De 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 is bijvoorbeeld 20%, dat wil gezegd 0,2 Vcore. Stel dat de server van de Burstable-laag een workload uitvoert waarvoor meer CPU-prestaties nodig zijn dan het basisniveau en dat het CPU-tegoed is uitgeput. In dat geval kan de server prestatiebeperkingen ondervinden en uiteindelijk invloed hebben op verschillende systeembewerkingen, zoals Stoppen/Starten/Opnieuw opstarten voor uw server.
Notitie
Voor servers in B-serie burstable virtuele machinegrootten, zoals Standard_B1s/Standard_B1ms/Standard_B2s, kan hun relatief kleinere hostgeheugengrootte leiden tot crashes (onvoldoende geheugen) onder continue 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 de functionaliteit van het maken van leesreplica's in Azure Database for MySQL - Flexible Server en concepten voor hoge beschikbaarheid in de functie Azure Database for MySQL - Flexibele server . Andere rekenlagen, zoals algemeen gebruik of Bedrijfskritiek, zijn geschikter voor dergelijke workloads en functies.
Zie het B-serie CPU-tegoedmodel van de B-serie voor burstable virtuele machines en het CPU-kredietmodel van de B-serie voor meer informatie over het CPU-tegoedmodel van de Azure-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 workload- en prestatievereisten.
Azure Database for MySQL - Flexible Server bewaken: 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.
Azure Database for MySQL - Flexibele server bewaken: met deze metrische waarde wordt het aantal RESTERENDE CPU-tegoeden voor uw exemplaar weergegeven. Het bewaken van deze metrische gegevens kan helpen 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
De opslag die u inricht, is de opslagcapaciteit die beschikbaar is voor uw flexibele server. Opslag wordt gebruikt voor de databasebestanden, tijdelijke bestanden, transactielogboeken en de MySQL-serverlogboeken. Voor de servicelagen Burstable en Algemeen gebruik omvat het opslagbereik minimaal 20 GiB tot maximaal 16 TiB. Daarentegen wordt de opslagondersteuning uitgebreid tot 32 TiB voor Bedrijfskritiek servicelaag. In alle servicelagen wordt opslag in stappen van 1 GiB geschaald en kan deze 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 bereiken
Wanneer de opslag die op de server wordt verbruikt 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 gemarkeerd als alleen-lezen wanneer de gratis opslag kleiner is dan 5 GiB.
Als u bijvoorbeeld 110 GiB van opslag hebt ingericht en het werkelijke gebruik hoger is dan 105 GiB, 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 de server alleen-lezen te maken, worden alle nieuwe schrijftransactieaanvragen geblokkeerd en blijven bestaande actieve transacties worden uitgevoerd. Wanneer de server is ingesteld op alleen-lezen, mislukken alle volgende schrijfbewerkingen en transactiedoorvoeringen, maar blijven leesquery's ononderbroken 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.
Automatische groei van opslag
Automatische groei van opslag voorkomt dat uw server geen opslagruimte meer heeft en alleen-lezen wordt. Als automatisch vergroten 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 servercreaties. 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 groter is dan 990 GB, wordt de opslaggrootte van de server verhoogd naar 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, zodra automatisch omhoog is geschaald, 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. Opslag-IOPS in Azure Database for MySQL - Flexibele server De minimale IOPS is 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 metrische gegevens van Azure Database for MySQL - Flexible Server . U moet de rekenkracht van uw server schalen als u meer IOPS nodig hebt dan de maximale IOPS op basis van rekenkracht.
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 bepaalde 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 de 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 in staat te stellen de prestaties van de databaseservers (IO) naadloos te schalen, afhankelijk van de behoeften van de werkbelasting. Met deze opt-in-functie kunnen gebruikers IOPS op aanvraag schalen zonder dat ze vooraf een bepaalde hoeveelheid IO per seconde hoeven in te richten. Als de IOPS voor automatische schaalaanpassing is ingeschakeld, kunt u nu genieten van probleemloos 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, tijd en geld besparen. 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, waarmee een vaste IOPS-limiet wordt opgegeven en wordt 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 een back-up van uw server. U kunt een bewaarperiode van 1 tot 35 dagen selecteren. Meer informatie over back-ups in het artikel over back-up- en herstelconcepten.
Resources schalen
Nadat u de server hebt gemaakt, kunt u onafhankelijk de rekenlaag, de rekengrootte (vCores en het geheugen), de opslagcapaciteit en de bewaarperiode voor back-ups wijzigen. De rekenkracht kan omhoog of omlaag worden geschaald en de bewaarperiode voor back-ups kan tussen 1 en 35 dagen omhoog of omlaag worden geschaald. De opslaggrootte kan alleen worden verhoogd. U kunt de resources schalen 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, moet de server opnieuw worden opgestart om het nieuwe servertype van kracht te laten worden. Wanneer het systeem overschakelt naar de nieuwe server, kunnen er geen nieuwe verbindingen tot stand worden gebracht en worden alle niet-doorgevoerde transacties teruggedraaid. Dit venster varieert, maar in de meeste gevallen is het 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.
Prijs
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.