Prestatiefuncties van Azure Database for MySQL - Flexibele server
U kunt flexibele Azure Database for MySQL-servers maken op basis van een van de drie servicelagen: Burstable, General Purpose en Bedrijfskritiek. De servicelagen bieden een toenemend reken- en opslagniveau, evenals het ondersteunde aantal maximale verbindingen en I/O-bewerkingen per seconde (IOPS). Een flexibele MySQL-server kan verschillende databases hosten. U kunt de prestatiegegevens van uw flexibele MySQL-server bewaken, zoals CPU- en geheugengebruik, I/O-prestaties, metrische querygegevens en meer, om weloverwogen beslissingen te nemen over capaciteit.
Rekenkracht: RAM en kernen
Elk van de drie servicelagen biedt verschillende onderliggende VM-SKU's. De Burstable-laag maakt gebruik van VM's uit de B-serie, de laag Algemeen gebruik maakt gebruik van VM's uit de D-serie en de Bedrijfskritiek laag maakt gebruik van VM's uit de E-serie. De gebruikte VM-serie bepaalt het aantal vCores en RAM dat beschikbaar is op de server.
U kunt de rekenlaag, de rekengrootte en de opslaggrootte wijzigen nadat u een server hebt gemaakt. Voor het wijzigen van de rekenlaag of de rekengrootte is een herstart vereist die doorgaans één tot twee minuten duurt. Als u de opslaggrootte wijzigt, hoeft u niet opnieuw op te starten.
Voor niet-productieworkloads (ontwikkeling, fasering, testen, enzovoort) kunt u overwegen servers te gebruiken op basis van de Burstable-laag, die een rendabele oplossing biedt voor workloads die niet continu gebruikmaken van de volledige CPU. Tijdens perioden van laag gebruik verzamelen servers met VM's uit de B-serie CPU-tegoed dat kan worden gebruikt in perioden met hoog gebruik tot burst-prestaties boven de basislijn. Als uw basislijn te hoog is of er te veel pieken in het gebruik zijn, kunt u overwegen om een upgrade uit te voeren naar de lagen Algemeen gebruik of Bedrijfskritiek om prestatievermindering te voorkomen.
Rekengrootten voor servicelagen
Elk van de drie servicelagen biedt verschillende rekenkrachtniveaus. Hoewel de Burstable-laag maximaal 20 vCores kan ondersteunen en de laag Algemeen gebruik maximaal 64 vCores kan ondersteunen, met ondersteuning voor maximaal 96vCores, biedt de Bedrijfskritiek laag het hoogste rekenvermogen. De Bedrijfskritiek-laag biedt ook vm's uit de Ev5-serie, die tot 30% meer QPS en 50% lagere latentie bieden dan de VM's uit de Ev4-serie.
IOPS: vooraf ingericht versus automatisch schalen
Het aantal lees- en schrijfbewerkingen dat per seconde kan worden uitgevoerd, wordt aangeduid als de IOPS (I/O-bewerkingen per seconde). Hogere IOPS-instellingen bieden betere opslagprestaties: meer gelijktijdige lees-/schrijfbewerkingen resulteren in snellere gegevens ophalen, gegevenspersistentie, indexupdates en algehele database-efficiëntie. Als de IOPS-instellingen te laag zijn, kan de database vertragingen en verminderde prestaties ondervinden. Als de IOPS-instellingen te hoog zijn, kunnen uw kosten echter toenemen zonder dat u eventuele prestatieverbeteringen realiseert.
Met Azure Database for MySQL – Flexible Server richt u IOPS vooraf in of gebruikt u de functie IOPS voor automatisch schalen.
Met vooraf ingerichte IOPS wijst u een specifiek aantal IOPS toe om consistente en voorspelbare prestaties te bieden. Dit werkt goed als de belasting niet de drempelwaarde nadert waarop I/O-bewerkingen worden beperkt. Hoewel u altijd extra IOPS kunt toewijzen naarmate uw werkbelasting toeneemt, is hiervoor handmatige tussenkomst vereist.
Als de functie IOPS voor automatisch schalen is ingeschakeld, schaalt uw IOPS op aanvraag op basis van de workloadactiviteit en betaalt u op basis van verbruik. Naarmate de werkbelasting toeneemt, worden de I/O-prestaties van de server naadloos geschaald, zodat uw exemplaar pieken in de werkbelasting kan verwerken zonder te betalen voor ongebruikte capaciteit wanneer het verkeer laag is.
In beide gevallen kan IOPS het maximum van de server niet overschrijden. Zie het artikel Compute- en opslagdocumentatie voor informatie over de maximale IOPS per rekengrootte.
Leesreplica's
Naarmate het verkeer van uw database toeneemt, kunt u de capaciteit horizontaal of uitschalen (aantal rekenknooppunten) of verticaal of 'omhoog' (grootte van rekenknooppunten). Leesreplica's bieden horizontaal schalen.
Een leesreplica is een alleen-lezen kopie van een database die gesynchroniseerd blijft met behulp van de binaire logboekreplicatie (binlog) van MySQL. Naarmate toepassingen groeien, moeten ze reken- en opslagresources schalen (zoals de database). Schalen van toepassingsonderdelen wordt vereenvoudigd door nieuwe VM's in te richten met behulp van Azure Kubernetes Service (AKS), Virtual Machine Scale Sets en App Service. Naarmate deze rekenresources worden geschaald en opgeslagen gegevens toenemen, nemen ze de belasting van de database toe, wat vaak een knelpunt is in de architectuur van de toepassing.
Met behulp van een leesreplica kunt u bewerkingen met het kenmerk Alleen-lezen omleiden naar secundaire databases, zodat de primaire server lees-/schrijfbewerkingen ondersteunt. Azure Database for MySQL biedt beheerde leesreplica's. U kunt een bronserver repliceren naar maximaal 10 replica's. Dit kan helpen bij gebruiksvoorbeelden, zoals rapportage en analyse, die vaak grote hoeveelheden gegevens opvragen.
Het gebruik van een leesreplica is met name handig wanneer om de ene reden of andere query's geen indexen kunnen gebruiken. Het kan onpraktisch of zelfs verstorend zijn om indexen toe te voegen voor alle querypatronen, omdat deze extra belasting op de server plaatst (verwerking, schijf-I/O, opslag, transactietijd, enzovoort). Als een datawarehouse niet beschikbaar is of als u gegevens nodig hebt die recenter zijn dan de vernieuwingscyclus, is het gebruik van een leesreplica een uitstekende manier om 'grote' query's uit te voeren zonder kritieke lees-/schrijfbewerkingen te verstoren.
Leesreplica's zijn niet onmiddellijk synchroon op dezelfde manier als een configuratie met hoge beschikbaarheid. Leesreplica's introduceren niet de transactionele latentie die is gekoppeld aan een ha-oplossing, maar er kan een kleine vertraging optreden wanneer de gegevens de replica bereiken vanuit de primaire database.