Aanbevolen procedures voor het bouwen van een toepassing met Azure Database for MySQL

  • 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 ?

Hier volgen enkele aanbevolen procedures om u te helpen bij het bouwen van een toepassing die gereed is voor de cloud met behulp van Azure Database for MySQL. Deze aanbevolen procedures kunnen de ontwikkeltijd voor uw app verminderen.

Configuratie van toepassings- en databasebronnen

De toepassing en database in dezelfde regio behouden

Zorg ervoor dat al uw afhankelijkheden zich in dezelfde regio bevinden bij het implementeren van uw toepassing in Azure. Het spreiden van exemplaren tussen regio's of beschikbaarheidszones zorgt voor netwerklatentie, wat van invloed kan zijn op de algehele prestaties van uw toepassing.

Uw MySQL-server veilig houden

Configureer uw MySQL-server zodanig dat deze veilig en niet openbaar toegankelijk is. Gebruik een van deze opties om uw server te beveiligen:

Voor beveiliging moet u altijd verbinding maken met uw MySQL-server via SSL en uw MySQL-server en uw toepassing configureren om TLS 1.2 te gebruiken. Zie SSL /TLS configureren.

Geavanceerde netwerken gebruiken met AKS

Wanneer versneld netwerken is ingeschakeld op een virtuele machine, is er een lagere latentie, een verminderde jitter en een lager CPU-gebruik op de VIRTUELE machine. Zie Best practices voor Azure Kubernetes Service en Azure Database for MySQL voor meer informatie.

De serverparameters afstemmen

Voor het afstemmen van serverparameters tmp_table_size met veel leesintensieve werkbelastingen en max_heap_table_size kan dit helpen optimaliseren voor betere prestaties. Als u de waarden wilt berekenen die vereist zijn voor deze variabelen, bekijkt u de totale waarden per verbinding en basisgeheugenwaarden. De som van parameters per verbindingsgeheugen, met uitzondering tmp_table_sizevan , gecombineerd met de basisgeheugenaccounts voor het totale geheugen van de server.

Gebruik de volgende formule om de grootst mogelijke grootte van tmp_table_size en max_heap_table_sizete berekenen:

(total memory - (base memory + (sum of per-connection memory * # of connections)) / # of connections

Notitie

Totaal geheugen geeft de totale hoeveelheid geheugen aan die de server heeft voor de ingerichte vCores. In een Azure Database for MySQL-server voor algemeen gebruik is het totale geheugen bijvoorbeeld 5 GB * 2. Meer informatie over geheugen vindt u voor elke laag in de documentatie voor de prijscategorie .

Basisgeheugen geeft de geheugenvariabelen, zoals query_cache_size en innodb_buffer_pool_size, aan dat MySQL wordt geïnitialiseerd en toegewezen aan het begin van de server. Geheugen per verbinding, zoals sort_buffer_size en join_buffer_size, is het toegewezen geheugen alleen wanneer een query deze nodig heeft.

Niet-beheerders maken

Maak niet-beheerders voor elke database. Normaal gesproken worden de gebruikersnamen geïdentificeerd als de databasenamen.

Uw wachtwoord opnieuw instellen

U kunt uw wachtwoord voor uw MySQL-server opnieuw instellen met behulp van Azure Portal.

Als u het serverwachtwoord voor een productiedatabase opnieuw instelt, kan uw toepassing worden uitgeschakeld. Het is een goede gewoonte om het wachtwoord voor productieworkloads buiten piekuren opnieuw in te stellen om de impact op de gebruikers van uw toepassing te minimaliseren.

Prestaties en tolerantie

Hier volgen enkele hulpprogramma's en procedures voor het opsporen van fouten in de prestaties van uw toepassing.

Trage querylogboeken inschakelen om prestatieproblemen te identificeren

U kunt trage querylogboeken en auditlogboeken op uw server inschakelen. Het analyseren van trage querylogboeken kan helpen bij het identificeren van prestatieknelpunten voor het oplossen van problemen.

Auditlogboeken zijn ook beschikbaar via Azure Diagnostics-logboeken in Azure Monitor-logboeken, Azure Event Hubs en opslagaccounts. Zie Hoe u prestatieproblemen met query's kunt oplossen.

Groepsgewijze verbinding gebruiken

Het beheren van databaseverbindingen kan een aanzienlijke invloed hebben op de prestaties van de toepassing als geheel. Om de prestaties te optimaliseren, moet u het aantal keren dat verbindingen tot stand worden gebracht en de tijd voor het tot stand brengen van verbindingen in sleutelcodepaden verminderen. Gebruik groepsgewijze verbindingen om verbinding te maken met Azure Database for MySQL om de tolerantie en prestaties te verbeteren.

U kunt de ProxySQL-verbindingspooler gebruiken om verbindingen efficiënt te beheren. Als u een verbindingspooler gebruikt, kunt u niet-actieve verbindingen verminderen en bestaande verbindingen opnieuw gebruiken, zodat u problemen kunt voorkomen. Zie ProxySQL instellen voor meer informatie.

Logica voor opnieuw proberen om tijdelijke fouten te verwerken

Uw toepassing kan tijdelijke fouten ondervinden waarbij verbindingen met de database af en toe verloren gaan. In dergelijke situaties is de server actief na een tot twee nieuwe pogingen in 5 tot 10 seconden.

Een goede gewoonte is om vijf seconden te wachten voordat u het opnieuw probeert. Volg vervolgens elke nieuwe poging door de wachttijd geleidelijk te verhogen, tot 60 seconden. Beperk het maximum aantal nieuwe pogingen, waarbij uw toepassing van mening is dat de bewerking is mislukt, zodat u deze verder kunt onderzoeken. Zie Verbindingsproblemen oplossen voor meer informatie.

Leesreplicatie inschakelen om failovers te beperken

Voor failoverscenario's kunt u replicatie van inkomende gegevens gebruiken. Er vindt geen geautomatiseerde failover plaats tussen bron- en replicaservers bij het gebruik van leesreplica's.

U ziet een vertraging tussen de bron en de replica omdat de replicatie asynchroon is. Netwerkvertraging kan worden beïnvloed door veel factoren, zoals de grootte van de werkbelasting die wordt uitgevoerd op de bronserver en de latentie tussen datacenters. In de meeste gevallen varieert de replicavertraging van een paar seconden tot een paar minuten.

Database-implementatie

Een Azure-database voor MySQL-taak configureren in uw CI/CD-implementatiepijplijn

Af en toe moet u wijzigingen in uw database implementeren. In dergelijke gevallen kunt u continue integratie (CI) en continue levering (CD) via Azure Pipelines gebruiken en een taak voor uw MySQL-server gebruiken om de database bij te werken door er een aangepast script voor uit te voeren.

Een effectief proces gebruiken voor handmatige database-implementatie

Volg deze stappen tijdens handmatige database-implementatie om downtime te minimaliseren of het risico op mislukte implementatie te verminderen:

  1. Maak een kopie van een productiedatabase op een nieuwe database met behulp van mysqldump of MySQL Workbench.
  2. Werk de nieuwe database bij met uw nieuwe schemawijzigingen of updates die nodig zijn voor uw database.
  3. Plaats de productiedatabase in de status Alleen-lezen. Het is het beste als u geen schrijfbewerkingen op de productiedatabase hebt totdat de implementatie is voltooid.
  4. Test uw toepassing met de zojuist bijgewerkte database uit stap 1.
  5. Implementeer uw toepassingswijzigingen en zorg ervoor dat de toepassing nu de nieuwe database gebruikt met de nieuwste updates.
  6. Behoud de oude productiedatabase om de wijzigingen terug te draaien. U kunt vervolgens evalueren om de oude productiedatabase te verwijderen of deze zo nodig te exporteren in Azure Storage.

Notitie

Als de toepassing lijkt op een e-commerce-app en u deze niet in de status Alleen-lezen kunt plaatsen, implementeert u de wijzigingen rechtstreeks in de productiedatabase nadat u een back-up hebt gemaakt. Deze wijzigingen moeten optreden tijdens daluren met weinig verkeer naar de app om de impact te minimaliseren, omdat sommige gebruikers mogelijk mislukte aanvragen ondervinden.

Zorg ervoor dat uw toepassingscode ook mislukte aanvragen verwerkt.

Gebruik systeemeigen metrische gegevens van MySQL om te zien of uw workload tijdelijke tabelgrootten in het geheugen overschrijdt

Met een leesintensieve workload kunnen query's op uw MySQL-server de tijdelijke tabelgrootten in het geheugen overschrijden. Een werkbelasting met veel leesbewerkingen kan ertoe leiden dat uw server overschakelt naar het schrijven van tijdelijke tabellen naar schijf, wat van invloed is op de prestaties van uw toepassing. Als u wilt bepalen of uw server naar de schijf schrijft als gevolg van het overschrijden van de tijdelijke tabelgrootte, bekijkt u de volgende metrische gegevens:

show global status like 'created_tmp_disk_tables';
show global status like 'created_tmp_tables';

De created_tmp_disk_tables metrische waarde geeft aan hoeveel tabellen er op schijf zijn gemaakt. Op basis van uw workload geeft de created_tmp_table metrische waarde aan hoeveel tijdelijke tabellen er in het geheugen moeten worden gevormd. Als u wilt bepalen of een specifieke query gebruikmaakt van tijdelijke tabellen, voert u de INSTRUCTIE EXPLAIN uit voor de query. De details in de extra kolom geven aan Using temporary of de query wordt uitgevoerd met behulp van tijdelijke tabellen.

Als u het percentage van uw workload wilt berekenen met query's die overlopen naar schijven, gebruikt u de metrische waarden in de volgende formule:

(created_tmp_disk_tables / (created_tmp_disk_tables + created_tmp_tables)) * 100

In het ideale geval moet dit percentage kleiner zijn dan 25%. Als het percentage 25% of hoger is, raden we u aan om twee serverparameters, tmp_table_size en max_heap_table_size te wijzigen.

Databaseschema en query's

Hier volgen enkele tips die u moet onthouden bij het bouwen van uw databaseschema en query's.

Het juiste gegevenstype gebruiken voor de tabelkolommen

Door het juiste gegevenstype te gebruiken op basis van het type gegevens dat u wilt opslaan, kunt u de opslag optimaliseren en fouten verminderen vanwege onjuiste gegevenstypen.

Indexen gebruiken

U kunt indexen gebruiken om trage query's te voorkomen. Met indexen kunt u snel rijen met specifieke kolommen vinden. Zie Indexen gebruiken in MySQL.

UITLEG gebruiken voor uw SELECT-query's

Gebruik de EXPLAIN instructie om inzicht te krijgen in wat MySQL doet om uw query uit te voeren. Hiermee kunt u knelpunten of problemen met uw query detecteren. Zie Uitleg gebruiken om queryprestaties te profilen.