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

Artikel
09/28/2021
7 minuten om te lezen

VAN TOEPASSING OP: Azure Database for MySQL - Single Server Azure Database for MySQL - Flexible Server

Hier volgen enkele best practices voor het bouwen van een toepassing die gereed is voor de cloud met behulp van Azure Database for MySQL. Deze best practices kunnen de ontwikkeltijd voor uw app verminderen.

Configuratie van toepassings- en databasebronnen

De toepassing en database in dezelfde regio houden

Zorg ervoor dat al uw afhankelijkheden zich in dezelfde regio wanneer u uw toepassing implementeert 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 zo dat deze veilig is en niet openbaar toegankelijk is. Gebruik een van deze opties om uw server te beveiligen:

Voor de beveiliging moet u altijd verbinding maken met uw MySQL-server via SSL en uw MySQL-server en uw toepassing configureren voor het gebruik van TLS 1.2. Zie How to configure SSL/TLS (SSL/TLS configureren).

Geavanceerde netwerken gebruiken met AKS

Wanneer versneld netwerken is ingeschakeld op een VM, is er een lagere latentie, minder jitter en minder CPU-gebruik op de VM. Zie Best practices for Azure Kubernetes Service and Azure Database for MySQL (Best practices voor Azure Kubernetes Service en Azure Database for MySQL

Uw serverparameters afstemmen

Voor lees-zware werkbelastingen die serverparameters afstemmen tmp_table_size en kunnen helpen bij het optimaliseren voor betere max_heap_table_size prestaties. Als u de vereiste waarden voor deze variabelen wilt berekenen, bekijkt u de totale geheugenwaarden per verbinding en het basisgeheugen. De som van geheugenparameters per verbinding, met uitzondering van , in combinatie met de tmp_table_size basisgeheugenaccounts voor het totale geheugen van de server.

Gebruik de volgende formule om de grootst mogelijke grootte tmp_table_size van en max_heap_table_size te 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 inrichtende vCores. In een server met Algemeen twee vCores Azure Database for MySQL is het totale geheugen bijvoorbeeld 5 GB * 2. Meer informatie over het geheugen voor elke laag vindt u in de documentatie over de prijscategorie.

Basisgeheugen geeft de geheugenvariabelen aan, zoals en , die query_cache_size Door MySQL worden initialiseren innodb_buffer_pool_size en toegewezen bij het starten van de server. Geheugen per verbinding, zoals en , is geheugen dat alleen wordt toegewezen sort_buffer_size wanneer een query dit nodig join_buffer_size heeft.

Gebruikers zonder beheerdersrechten maken

Maak niet-beheerders voor elke database. Normaal gesproken worden de gebruikersnamen aangeduid als de databasenamen.

Uw wachtwoord opnieuw instellen

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

Het opnieuw instellen van uw serverwachtwoord voor een productiedatabase kan uw toepassing in de weg zitten. Het is een goede gewoonte om het wachtwoord opnieuw in te stellen voor productieworkloads buiten piekuren om de impact op de gebruikers van uw toepassing te minimaliseren.

Prestaties en tolerantie

Hier volgen enkele hulpprogramma's en procedures die u kunt gebruiken om prestatieproblemen met uw toepassing op te lossen.

Logboeken voor langzame query's inschakelen om prestatieproblemen te identificeren

U kunt logboeken voor langzame query's en auditlogboeken op uw server inschakelen. Het analyseren van logboeken voor langzame query's 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 Problemen met queryprestaties oplossen.

Verbindingsgroepering 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 beperken dat verbindingen tot stand worden gebracht en de tijd voor het tot stand brengen van verbindingen in sleutelcodepaden. Gebruik verbindingsgroepering om verbinding te maken met Azure Database for MySQL tolerantie en prestaties te verbeteren.

U kunt de ProxySQL-verbindingspooler gebruiken om verbindingen efficiënt te beheren. Het gebruik van een verbindingspooler kan niet-actieve verbindingen verminderen en bestaande verbindingen hergebruiken, waardoor problemen worden voorkomen. Zie ProxySQL instellen voor meer informatie.

Pogingslogica voor het afhandelen van tijdelijke fouten

Uw toepassing kan tijdelijke fouten ervaren waarbij verbindingen met de database af en toe worden verwijderd of verloren gaan. In dergelijke situaties is de server actief na één tot twee nieuwe keer in 5 tot 10 seconden.

Het is een goed idee om vijf seconden te wachten voordat u het voor het eerst opnieuw doet. Volg vervolgens elke nieuwe poging door de wachttijd geleidelijk te verhogen tot maximaal 60 seconden. Beperk het maximum aantal nieuwe pogingen op welk moment uw toepassing de bewerking als mislukt beschouwt, zodat u dit verder kunt onderzoeken. Zie Verbindingsfouten oplossen voor meer informatie.

Leesreplicatie inschakelen om failovers te beperken

U kunt deze Replicatie van inkomende gegevens voor failoverscenario's. Wanneer u leesreplica's gebruikt, vindt er geen automatische failover plaats tussen bron- en replicaservers.

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 workload die op de bronserver wordt uitgevoerd 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 op 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 implementaties te verminderen:

Maak een kopie van een productiedatabase in een nieuwe database met behulp van mysqldump of MySQL Workbench.
Werk de nieuwe database bij met uw nieuwe schemawijzigingen of updates die nodig zijn voor uw database.
De productiedatabase in een alleen-lezen status. Schrijfbewerkingen voor de productiedatabase mogen pas worden uitgevoerd als de implementatie is voltooid.
Test uw toepassing met de zojuist bijgewerkte database uit stap 1.
Implementeer uw toepassingswijzigingen en zorg ervoor dat de toepassing nu gebruik maakt van de nieuwe database met de meest recente updates.
Bewaar de oude productiedatabase zodat u de wijzigingen kunt terugdraaien. U kunt vervolgens evalueren om de oude productiedatabase te verwijderen of deze te exporteren op Azure Storage indien nodig.

Notitie

Als de toepassing lijkt op een e-commerce-app en u deze niet in de alleen-lezen status kunt zetten, implementeert u de wijzigingen rechtstreeks in de productiedatabase nadat u een back-up hebt gemaakt. Deze wijziging moet zich voordoen tijdens daluren met weinig verkeer naar de app om de impact te minimaliseren, omdat sommige gebruikers mogelijk te maken krijgen met mislukte aanvragen.

Zorg ervoor dat uw toepassingscode ook mislukte aanvragen verwerkt.

Gebruik systeemeigen mySQL-metrische gegevens om te zien of uw workload de tijdelijke tabelgrootten in het geheugen overschrijdt

Met een leesbelasting kunnen query's die worden uitgevoerd op uw MySQL-server de tijdelijke tabelgrootten in het geheugen overschrijden. Een leesbelasting 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 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 gegevens geven aan hoeveel tabellen er op schijf zijn gemaakt. De metrische gegevens geven aan hoeveel tijdelijke tabellen er in het geheugen moeten worden gevormd created_tmp_table op basis van uw workload. Als u wilt bepalen of voor het uitvoeren van een specifieke query tijdelijke tabellen worden gebruikt, moet u de instructie EXPLAIN uitvoeren voor de query. De details in de extra kolom geven aan of de query wordt uitgevoerd met behulp van tijdelijke Using temporary tabellen.

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

(created_tmp_disk_tables / (created_tmp_disk_tables + created_tmp_tables)) * 100

Idealiter zou dit percentage minder dan 25% moeten zijn. Als u ziet dat het percentage 25% of hoger is, raden we u aan twee serverparameters, tmp_table_size en max_heap_table_size.

Databaseschema en query's

Hier vindt u enkele tips om rekening mee te houden wanneer u uw databaseschema en uw query's bouwt.

Het juiste gegevenstype gebruiken voor uw 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 die kunnen optreden als gevolg van 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.

EXPLAIN gebruiken voor uw SELECT-query's

Gebruik de EXPLAIN instructie om inzicht te krijgen in wat MySQL doet om uw query uit te voeren. Het kan u helpen bij het detecteren van knelpunten of problemen met uw query. Zie EXPLAIN gebruiken om queryprestaties te profileren.