Best practices voor optimale prestaties van Azure Database for MySQL servers

VAN TOEPASSING OP: Azure Database for MySQL - Enkele server Azure Database for MySQL - Flexibele server

Belangrijk

Azure Database for MySQL: één server bevindt zich op het buitengebruikstellingspad. We raden u ten zeerste aan een upgrade uit te voeren naar Azure Database for MySQL - Flexibele server. Zie Wat gebeurt er met Azure Database for MySQL enkele server? voor meer informatie over migreren naar Azure Database for MySQL - Flexibele server.

Ontdek hoe u de beste prestaties krijgt tijdens het werken met uw Azure Database for MySQL-server. Naarmate we nieuwe mogelijkheden aan het platform toevoegen, blijven we onze aanbevelingen in deze sectie verfijnen.

Fysieke nabijheid

Zorg ervoor dat u een toepassing en de database in dezelfde regio implementeert. Een snelle controle voordat u een prestatiebenchmarking-uitvoering start, is om de netwerklatentie tussen de client en database te bepalen met behulp van een eenvoudige SELECT 1-query.

Wanneer resources zoals een webtoepassing en de bijbehorende database in verschillende regio's worden uitgevoerd, kan de communicatie tussen deze resources toenemen. Een ander mogelijk neveneffect van het hebben van de toepassing en database in afzonderlijke regio's heeft betrekking op de kosten voor uitgaande gegevensoverdracht.

Voor het verbeteren van de prestaties en betrouwbaarheid van een toepassing in een implementatie die is geoptimaliseerd voor kosten, wordt ten zeerste aanbevolen dat de webtoepassingsservice en de Azure Database for MySQL resource zich in dezelfde regio en beschikbaarheidszone bevinden. Deze colocatie is het beste voor toepassingen die latentiegevoelig zijn en biedt ook de beste doorvoer, omdat resources nauw zijn gekoppeld.

Versneld netwerken

Gebruik versneld netwerken voor de toepassingsserver als u een virtuele Azure-machine, Azure Kubernetes of App Services gebruikt. Versneld netwerken maakt I/O-virtualisatie met één hoofdmap (SR-IOV) mogelijk voor een VM, waardoor de netwerkprestaties aanzienlijk worden verbeterd. Dit pad met hoge prestaties omzeilt de host van het gegevenspad, waardoor latentie, jitter en CPU-gebruik worden verminderd voor gebruik met de meest veeleisende netwerkworkloads op ondersteunde VM-typen.

Verbindingsefficiëntie

Het tot stand brengen van een nieuwe verbinding is altijd een dure en tijdrovende taak. Wanneer een toepassing een databaseverbinding aanvraagt, wordt prioriteit gegeven aan de toewijzing van bestaande niet-actieve databaseverbindingen in plaats van een nieuwe verbinding te maken. Hier volgen enkele opties voor goede verbindingsprocedures:

  • ProxySQL: gebruik ProxySQL, dat ingebouwde groepsgewijze verbindingen biedt en uw werkbelasting naar meerdere leesreplica's verdelen, indien vereist op aanvraag met eventuele wijzigingen in de toepassingscode.

  • Heimdall-gegevensproxy: u kunt ook Heimdall Data Proxy gebruiken, een leverancierneutrale proxyoplossing. Het biedt ondersteuning voor het opslaan van query's in de cache en het splitsen van lees-/schrijfbewerkingen met detectie van replicatievertragingen. U kunt ook verwijzen naar MySQL-prestaties versnellen met de Heimdall-proxy.

  • Permanente of Long-Lived verbinding: als uw toepassing korte transacties of query's heeft met een uitvoeringstijd < van 5-10 ms, vervangt u korte verbindingen door permanente verbindingen. Voor het vervangen van korte verbindingen door permanente verbindingen zijn slechts kleine wijzigingen in de code vereist, maar dit heeft een groot effect op het verbeteren van de prestaties in veel typische toepassingsscenario's. Zorg ervoor dat u de time-out instelt of de verbinding sluit wanneer de transactie is voltooid.

  • Replica: als u een replica gebruikt, gebruikt u ProxySQL om de belasting tussen de primaire server en de leesbare secundaire replicaserver te verdelen. Meer informatie over het instellen van ProxySQL.

Groepsgewijze verbinding

Groepsgewijze verbindingen is een mechanisme waarmee het maken en toewijzen van databaseverbindingen wordt beheerd en een database wordt beschermd tegen verbindingspieken. Overweeg groepsgewijze verbindingen als uw toepassing in relatief korte tijd veel verbindingen opent en de verbindingen van korte duur zijn. Dit soort verbindingen kunnen bijvoorbeeld optreden over een omvang van honderden of duizenden per seconde en de tijd die nodig is om ze tot stand te brengen en te sluiten, is aanzienlijk in vergelijking met de totale levensduur van de verbinding.

Als het ontwikkelframework van uw toepassing geen ondersteuning biedt voor groepsgewijze verbindingen, gebruikt u in plaats daarvan een verbindingsproxy, zoals ProxySQL of Heimdall-proxy, tussen de toepassing en de databaseserver.

Schalen van verbindingen afhandelen

Een veelgebruikte aanpak voor het schalen van webtoepassingen om te voldoen aan de fluctuerende vraag, is het toevoegen en verwijderen van toepassingsservers. Elke toepassingsserver kan een verbindingsgroep met de database gebruiken. Deze aanpak zorgt ervoor dat het totale aantal verbindingen op een databaseserver toeneemt ten opzichte van het aantal toepassingsservers. Als een databaseserver bijvoorbeeld 10 toepassingsservers heeft en elke server is geconfigureerd voor 100 databaseverbindingen, biedt dat 1000 databaseverbindingen. Als de workload van de toepassing schaalt vanwege hogere gebruikersactiviteit of tijdens piekuren en als er nog eens 50 toepassingsservers worden toegevoegd, zouden de databaseverbindingen in totaal 6000 zijn. Meestal zijn de meeste van deze verbindingen inactief, nadat ze zijn voortgebracht door de toepassingsservers. Omdat niet-actieve verbindingen resources (geheugen en CPU) verbruiken om open te blijven, kan de schaalbaarheid van de database worden beïnvloed.

Extra potentiële uitdagingen zijn het afhandelen van het totale aantal verbindingen met de databaseserver. Dit wordt bepaald door het aantal toepassingsservers dat is verbonden met de databaseserver, waarbij elk een eigen set verbindingen maakt. In deze scenario's kunt u de verbindingsgroepen op de toepassingsservers aanpassen. Probeer het aantal verbindingen in elke groep tot een acceptabel minimum te beperken om ervoor te zorgen dat er geen bloat is in verbindingen aan de databaseserverzijde. Beschouw dit als een kortetermijnoplossing om de effecten van het schalen van toepassingsservers tegen te gaan in plaats van een permanente oplossing om de groei van de toepassing aan te pakken.

Als langetermijnoplossing introduceert u een verbindingsproxy, zoals ProxySQL of Heimdall-proxy, tussen de databaseserver en de toepassingsserver. Dit helpt omdat de proxy het volgende doet:

  • Maak een verbinding met de databaseserver met een vast aantal verbindingen.
  • Accepteer toepassingsverbindingen en fungeren als buffer voor potentiële verbindingsstormen.

Proxy's kunnen andere functies bieden, zoals het opslaan van query's in de cache, het bufferen van verbindingen, het herschrijven/routeren van query's en taakverdeling. Voor een nog grotere schaalbaarheid kunt u overwegen om meerdere proxy-exemplaren te gebruiken.

Verbindingsafhandeling voor fouttolerantie en sneller herstel

Wanneer u uw toepassingen en omgeving ontwerpt voor fouttolerantie en sneller herstel, moet u er rekening mee houden dat u in een databaseomgeving waarschijnlijk te maken krijgt met verbindingsonderbrekingen of hardwarefouten. Denk ook aan de noodzaak van operationele acties, zoals het schalen van instantiegrootten, patchen en het uitvoeren van handmatige failover.

Denk bijvoorbeeld aan een scenario waarin de failover van uw databaseserver binnen een minuut wordt voltooid, maar uw toepassing enkele minuten langer niet beschikbaar is vanwege zaken zoals DNS TTL die te lang is aan de toepassingszijde. In deze gevallen zorgt het simpelweg verlagen van de TTL-waarde voor een sneller herstel. Het integreren van een verbindingsproxy tussen toepassing en databaseserver kan helpen bij het afhandelen van dergelijke fouten.

Partitionering

Wanneer uw productieworkload gebruikmaakt van extreem grote tabellen, is partitionering een uitstekende methode om de databaseprestaties te verbeteren en het onderhoud te vereenvoudigen. Partitionering maakt het eenvoudiger om grote tabellen te beheren. Met deze benadering kunt u partities toevoegen en verwijderen om grote tabellen effectief te beheren. Partitionering kan ook helpen de engine te schalen door interne structuurconflicten, zoals interne vergrendelingen per tabel of per index, te verlichten (denk bijvoorbeeld aan de btr_search_latch in InnoDB).

Door bijvoorbeeld vijf partities toe te voegen, breekt u een grote tabel met veel activiteit op in vijf kleinere, efficiëntere tabellen. Dit is voornamelijk handig voor gevallen waarin de hoofdbewerking primaire sleutelzoekacties in de tabel zijn, zodat de query's kunnen profiteren van 'partities verwijderen'. Maar partitioneren kan ook helpen bij het scannen van tabellen.

Hoewel partitioneren voordelen heeft, heeft het ook enkele beperkingen, zoals het ontbreken van ondersteuning voor refererende sleutels in gepartitioneerde tabellen, het ontbreken van querycache, enzovoort. Zie het hoofdstuk Beperkingen en beperkingen voor partitionering in de MySQL-referentiehandleiding voor een volledige lijst van deze beperkingen.

Lees- en schrijfbewerkingen scheiden

De meeste toepassingen lezen voornamelijk uit de database, waarbij slechts een klein percentage van de interacties betrekking heeft op schrijfbewerkingen. Het aantal actieve verbindingen in de primaire database dat we voor de verbindingsgroepen hebben berekend, omvat waarschijnlijk leesverkeer. Het offloaden van zoveel mogelijk query's naar leesreplica's en het besparen van toegang tot het primaire beschrijfbare exemplaar verhoogt de totale databaseactiviteit die door de toepassingsservers wordt uitgevoerd zonder de belasting van de primaire database te verhogen. Als u nog geen toegang hebt tot leesreplica's, ten minste voor langere query's zoals rapporten, kunt u overwegen om rapporten of analyses onmiddellijk te verplaatsen naar leesreplica's.

Het gebruik van leesreplica's op grotere schaal kan zorgvuldiger overwegen, omdat replica's iets achterblijven op de primaire replica vanwege de asynchrone aard van replicatie. Zoek zoveel mogelijk gebieden van de toepassing die kunnen worden geleverd met leesbewerkingen uit de replica's met kleine codewijzigingen. U moet deze methode ook toepassen op hogere niveaus met betrekking tot caching: meer van de alleen-lezen of langzaam veranderende inhoud van een toegewezen cachelaag, zoals Azure Cache voor Redis.

Schalen en sharding schrijven

Na verloop van tijd ontwikkelen toepassingen zich en wordt nieuwe functionaliteit toegevoegd. Uit gemak of algemene praktijk worden de tabellen toegevoegd aan de primaire database. Als u de toenemende verkeersbelasting op een database wilt afhandelen, identificeert u gebieden van de toepassing die eenvoudig naar afzonderlijke databases kunnen worden verplaatst en kunt u overwegen om de database horizontaal te sharden of verticaal te splitsen.

Het horizontaal sharden van een database werkt door meerdere kopieën van het toepassingsschema in afzonderlijke databases te maken en klanten en alle bijbehorende gegevens te scheiden op basis van klant-id, geografie of een ander kenmerk per klant of tenant. Dit werkt zeer goed voor SaaS- of B2C-toepassingen waarbij individuele klanten klein zijn en de belasting voor de toepassing afkomstig is van het geaggregeerde gebruik van miljoenen klanten. Het is echter moeilijker met B2B-toepassingen waarin klanten verschillende grootten hebben en individuele grote klanten de verkeersbelasting voor een bepaalde shard kunnen domineren.

De belasting verticaal splitsen door de database functioneel te sharden, waarbij afzonderlijke toepassingsdomeinen (of microservices) naar hun eigen databases worden verplaatst. Hiermee wordt de belasting van de primaire database verdeeld om databases per service te scheiden. Eenvoudige voorbeelden zijn een logboekregistratietabel of siteconfiguratiegegevens die niet in dezelfde database hoeven te staan als de tabel met zwaar geladen orders. Complexere voorbeelden zijn het verbreken van klant- en accountdomeinen, afgezien van orders of afhandelingsdomeinen. In sommige gevallen kan dit toepassingswijzigingen vereisen, bijvoorbeeld om e-mail- of achtergrondtaakwachtrijen te wijzigen zodat deze op zichzelf staan en niet afhankelijk zijn van joins terug naar een klant of ordertabel. Het verplaatsen van bestaande tabellen en gegevens naar een nieuwe primaire database kan worden uitgevoerd met Azure Database for MySQL leesreplica's en het promoveren van de replica en het verwijzen van onderdelen van de toepassing naar de zojuist gemaakte beschrijfbare database. De zojuist gemaakte database moet de toegang met verbindingsgroepen beperken, query's afstemmen en de belasting verspreiden met eigen replica's, net zoals de oorspronkelijke primaire database.

Configuraties voor het importeren van gegevens

  • U kunt uw exemplaar tijdelijk schalen naar een hogere SKU-grootte voordat u een gegevensimportbewerking start en deze vervolgens omlaag schalen wanneer het importeren is voltooid.
  • U kunt uw gegevens met minimale downtime importeren met behulp van Azure Database Migration Service (DMS) voor online- of offlinemigraties.

aanbevelingen voor Azure Database for MySQL geheugen

Een Azure Database for MySQL best practice voor prestaties is om voldoende RAM-geheugen toe te wijzen, zodat uw werkset zich bijna volledig in het geheugen bevindt.

  • Controleer of het geheugenpercentage dat wordt gebruikt om de limieten te bereiken met behulp van de metrische gegevens voor de MySQL-server.
  • Stel waarschuwingen in voor dergelijke nummers om ervoor te zorgen dat wanneer de server limieten bereikt, u promptacties kunt ondernemen om het probleem op te lossen. Controleer op basis van de gedefinieerde limieten of de database-SKU omhoog wordt geschaald, naar een hogere rekenkracht of naar een betere prijscategorie, wat resulteert in een aanzienlijke toename van de prestaties.
  • Schaal omhoog totdat uw prestatiecijfers na een schaalbewerking niet meer drastisch dalen. Zie Metrische gegevens van MySQL DB voor informatie over het bewaken van de metrische gegevens van een DB-exemplaar.

Warmup voor InnoDB-buffergroepen gebruiken

Nadat de Azure Database for MySQL server opnieuw is opgestart, worden de gegevenspagina's die zich in de opslag bevinden, geladen terwijl de tabellen worden opgevraagd, wat leidt tot een hogere latentie en tragere prestaties voor de eerste uitvoering van de query's. Dit is mogelijk niet acceptabel voor latentiegevoelige workloads.

Door gebruik te maken van de warming-up van de InnoDB-buffergroep wordt de warming-upperiode verkort door schijfpagina's die zich vóór het opnieuw opstarten in de buffergroep bevonden, opnieuw te laden in plaats van te wachten op DML- of SELECT-bewerkingen voor toegang tot overeenkomende rijen.

U kunt de warm-upperiode verminderen nadat u de Azure Database for MySQL-server opnieuw hebt opgestart. Dit is een prestatievoordeel door innoDB-buffergroepserverparameters te configureren. InnoDB slaat een percentage van de laatst gebruikte pagina's op voor elke buffergroep bij het afsluiten van de server en herstelt deze pagina's bij het opstarten van de server.

Het is ook belangrijk om te weten dat verbeterde prestaties ten koste gaan van een langere opstarttijd voor de server. Wanneer deze parameter is ingeschakeld, neemt de opstart- en opstarttijd van de server naar verwachting toe, afhankelijk van de IOPS die op de server is ingericht.

We raden u aan om de opstarttijd te testen en te controleren om ervoor te zorgen dat de opstart-/herstartprestaties acceptabel zijn, omdat de server gedurende die tijd niet beschikbaar is. Het wordt niet aanbevolen om deze parameter te gebruiken met minder dan 1000 ingerichte IOPS (of met andere woorden, wanneer de ingerichte opslag minder dan 335 GB is).

Als u de status van de buffergroep bij het afsluiten van de server wilt opslaan, stelt u de serverparameter innodb_buffer_pool_dump_at_shutdown in op ON. Stel op dezelfde manier de serverparameter innodb_buffer_pool_load_at_startup in op ON om de status van de buffergroep te herstellen bij het opstarten van de server. U kunt het effect op de opstart-/opstarttijd bepalen door de waarde van de serverparameter innodb_buffer_pool_dump_pctte verlagen en af te stemmen. Deze parameter is standaard ingesteld op 25.

Notitie

Opwarmparameters voor innoDB-buffergroepen worden alleen ondersteund op opslagservers voor algemeen gebruik met een opslag van maximaal 16 TB. Zie Azure Database for MySQL opslagopties voor meer informatie.

Volgende stappen