Aanbevolen procedures voor optimale prestaties van Azure Database for MySQL - Flexibele server

  • Artikel

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

Belangrijk

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

Leer hoe u de beste prestaties krijgt tijdens het werken met een flexibele Azure Database for MySQL-server. Wanneer 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 uitvoering voor prestatiebenchmarking 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 worden uitgevoerd in verschillende regio's, kan er een verhoogde latentie optreden in de communicatie tussen deze resources. Een ander neveneffect van het feit dat de toepassing en database zich in afzonderlijke regio's bevinden, heeft betrekking op de kosten voor uitgaande gegevensoverdracht.

Om de prestaties en betrouwbaarheid van een toepassing in een kosten geoptimaliseerde implementatie te verbeteren, wordt het ten zeerste aangeraden dat de webtoepassingsservice en de flexibele Azure Database for MySQL-serverresource zich in dezelfde regio en beschikbaarheidszone bevinden. Deze colocatie is het beste voor toepassingen die latentiegevoelig zijn en die ook de beste doorvoer biedt, 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 VIRTUELE machine, 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.

efficiëntie van Verbinding maken

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 te maken. Hier volgen enkele opties voor goede verbindingsprocedures:

  • ProxySQL: Gebruik ProxySQL, dat ingebouwde groepsgewijze verbindingen biedt en uw werkbelasting in balans brengt met meerdere leesreplica's zoals vereist op aanvraag met eventuele wijzigingen in de toepassingscode.

  • Heimdall Data Proxy: U kunt ook Heimdall Data Proxy gebruiken, een leverancierneutrale bedrijfsproxyoplossing. Het biedt ondersteuning voor het opslaan van querycaching en het splitsen van lees-/schrijfbewerkingen met replicatievertragingsdetectie. U kunt ook verwijzen naar hoe u MySQL-prestaties kunt versnellen met de Heimdall-proxy.

  • Permanente of langdurige Verbinding maken ion: als uw toepassing korte transacties of query's heeft met uitvoeringstijd < van 5-10 ms, vervangt u korte verbindingen door permanente verbindingen. Voor het vervangen van korte verbindingen met 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 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

Verbinding maken groepering 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 kort duren. Deze typen verbindingen kunnen zich voordoen, bijvoorbeeld over een grootte 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 verwerken

Een algemene benadering voor het schalen van webtoepassingen om te voldoen aan de fluctuerende vraag is door toepassingsservers toe te voegen en te verwijderen. Elke toepassingsserver kan een verbindingsgroep met de database gebruiken. Deze benadering 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, zou dit 1000 databaseverbindingen bieden. Als de workload van de toepassing wordt geschaald vanwege een hogere gebruikersactiviteit of tijdens piekuren en als er nog eens 50 toepassingsservers worden toegevoegd, zijn de databaseverbindingen in totaal 6000. Meestal zijn de meeste van deze verbindingen niet actief, nadat ze zijn overgezet 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, die elk een eigen set verbindingen maken. In deze scenario's kunt u overwegen de verbindingsgroepen op de toepassingsservers aan te passen. Probeer het aantal verbindingen in elke pool te verminderen tot een acceptabel minimum om ervoor te zorgen dat er geen bloat is in verbindingen aan de serverzijde van de database. 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 querycaching, verbindingsbuffering, herschrijven/routeren van query's en taakverdeling. Voor nog grotere schaalbaarheid kunt u overwegen om meerdere proxy-exemplaren te gebruiken.

Verbinding maken ionafhandeling 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 verbindingsonderbrekingen of hardwarefouten ondervindt. Onthoud ook de noodzaak van operationele acties, zoals het schalen van exemplaargrootten, patchen en het uitvoeren van handmatige failover.

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

Partitionering

Wanneer uw productieworkload gebruikmaakt van zeer grote tabellen, is partitioneren een uitstekende methode om de prestaties van de database te verbeteren en onderhoud te vereenvoudigen. Partitionering maakt het eenvoudiger om grote tabellen te beheren. Met deze methode kunt u partities toevoegen en verwijderen om grote tabellen effectief te beheren. Partitionering kan ook helpen bij het schalen van de engine door conflicten in de interne structuur te verlichten, zoals interne vergrendelingen per tabel of index (bijvoorbeeld de btr_search_latch in InnoDB).

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

Houd er rekening mee dat hoewel partitioneren voordelen heeft, het ook enkele beperkingen heeft, zoals het ontbreken van ondersteuning voor refererende sleutels in gepartitioneerde tabellen, het gebrek aan querycache, enzovoort. Zie het hoofdstuk Beperkingen en beperkingen voor partitioneren in de handleiding voor MySQL-naslaginformatie voor een volledige lijst met deze beperkingen.

Lees- en schrijfbewerkingen scheiden

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

Voor een breder gebruik van leesreplica's is mogelijk meer aandacht nodig, omdat replica's iets achterblijven achter de primaire replica vanwege de asynchrone aard van replicatie. Zoek zoveel mogelijk gebieden van de toepassing die kunnen worden geleverd met leesbewerkingen van de replica's met kleine codewijzigingen. U moet deze methode ook toepassen op hogere niveaus met betrekking tot caching. Gebruik 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 worden nieuwe functionaliteit toegevoegd. Uit gemak of algemene praktijk worden de tabellen toegevoegd aan de primaire database. Voor het afhandelen van toenemende verkeersbelastingen op een database, identificeert u gebieden van de toepassing die eenvoudig kunnen worden verplaatst naar afzonderlijke databases en kunt u overwegen horizontaal sharding of verticaal te splitsen van de database.

Horizontaal sharding 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 waarin individuele klanten klein zijn en de belasting van de toepassing 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 overheersten.

Verdeel de belasting verticaal door de database functioneel te sharden: afzonderlijke toepassingsdomeinen (of microservices) verplaatsen naar hun eigen databases. Hiermee wordt de belasting van de primaire database verdeeld om databases per service te scheiden. Eenvoudige voorbeelden zijn een logboektabel of siteconfiguratiegegevens die niet in dezelfde database hoeven te staan als de tabel met zwaar geladen orders. Complexere voorbeelden zijn het breken van klant- en accountdomeinen, afgezien van orders of afhandelingsdomeinen. In sommige gevallen zijn er mogelijk toepassingswijzigingen vereist, bijvoorbeeld om e-mail- of achtergrondtaakwachtrijen zelf te wijzigen en niet te vertrouwen op joins naar een klant- of ordertabel. Het verplaatsen van bestaande tabellen en gegevens naar een nieuwe primaire database kan worden uitgevoerd met leesreplica's van Azure Database for MySQL flexibele server en het promoten van de replica en het aanwijzen van onderdelen van de toepassing naar de zojuist gemaakte beschrijfbare database. De zojuist gemaakte database moet de toegang beperken tot verbindingsgroepen, query's afstemmen en de belasting verdelen met eigen replica's, net als de oorspronkelijke primaire replica.

Configuraties voor gegevensimport

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

Aanbevelingen voor geheugen voor flexibele servers in Azure Database for MySQL

Een best practice voor flexibele serverprestaties van Azure Database for MySQL is om voldoende RAM toe te wijzen, zodat uw werkset bijna volledig in het geheugen aanwezig is.

InnoDB-bufferpool warmup gebruiken

Nadat de flexibele Server-instantie van Azure Database for MySQL opnieuw is opgestart, worden de gegevenspagina's die zich in de opslag bevinden, geladen wanneer 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.

Als u innoDB-buffergroep opwarmt, wordt de opwarmperiode korter door schijfpagina's die zich in de buffergroep bevonden, opnieuw te laden in plaats van te wachten op DML- of SELECT-bewerkingen om toegang te krijgen tot overeenkomende rijen.

U kunt de opwarmperiode verminderen na het opnieuw opstarten van uw exemplaar van flexibele Azure Database for MySQL-server, wat een prestatievoordeel vertegenwoordigt door innoDB-bufferserverparameters te configureren. InnoDB bespaart een percentage van de laatst gebruikte pagina's 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 langere opstarttijd voor de server. Wanneer deze parameter is ingeschakeld, wordt verwacht dat de opstart- en herstarttijd van de server toeneemt, 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 kleiner is dan 335 GB).

Als u de status van de buffergroep bij het afsluiten van de server wilt opslaan, stelt u de serverparameter in innodb_buffer_pool_dump_at_shutdown op ON. Stel op dezelfde manier de serverparameter in innodb_buffer_pool_load_at_startup om ON de status van de buffergroep te herstellen bij het opstarten van de server. U kunt het effect op de opstart-/herstarttijd beheren 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 in opslagservers voor algemeen gebruik met maximaal 16 TB opslag. Zie De opslagopties voor flexibele azure Database for MySQL-servers voor meer informatie.

Volgende stappen