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

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

Hier volgen enkele aanbevolen procedures om u te helpen bij het bouwen van een cloudklare toepassing 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 verspreiden van exemplaren in 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 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 minder CPU-gebruik op de VIRTUELE machine. Zie Best practices voor Azure Kubernetes Service en Azure Database for MySQL voor meer informatie

Uw serverparameters afstemmen

Voor het afstemmen van serverparameters tmp_table_size voor leesintensieve workloads en max_heap_table_size kan u helpen optimaliseren voor betere prestaties. Als u de vereiste waarden voor deze variabelen wilt berekenen, bekijkt u de totale geheugenwaarden per verbinding en het basisgeheugen. De som van parameters per verbinding, 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 Algemeen server met twee vCores Azure Database for MySQL server is het totale geheugen bijvoorbeeld 5 GB * 2. Meer informatie over geheugen voor elke laag vindt u in de documentatie voor de prijscategorie .

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

Niet-beheerdersgebruikers maken

Maak niet-beheerdersgebruikers 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 de Azure Portal.

Het opnieuw instellen van uw serverwachtwoord voor een productiedatabase kan uw toepassing omlaag brengen. 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 sporen.

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 probleemoplossing.

Auditlogboeken zijn ook beschikbaar via Azure Diagnostics logboeken in Azure Monitor-logboeken, Azure Event Hubs en opslagaccounts. Zie Problemen met queryprestaties oplossen.

Groepsgewijze verbindingen 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 zijn gebracht en de tijd voor het tot stand brengen van verbindingen in sleutelcodepaden verminderen. Gebruik verbindingsgroepen 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 worden verwijderd of verloren gaan. In dergelijke situaties is de server actief na een tot twee nieuwe pogingen binnen 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 waarop uw toepassing de bewerking mislukt beschouwt, zodat u vervolgens verder kunt onderzoeken. Zie Verbindingsproblemen oplossen voor meer informatie.

Leesreplicatie inschakelen om failovers te beperken

U kunt data-in-replicatie gebruiken voor failoverscenario's. Wanneer u leesreplica's gebruikt, treedt er geen automatische failover tussen bron- en replicaservers op.

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 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 ci (continue integratie) en continue levering (CD) gebruiken via Azure Pipelines 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 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. Schrijfbewerkingen voor de productiedatabase moeten pas worden uitgevoerd als 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 gebruikmaakt van de nieuwe database met de meest recente updates.
  6. Behoud de oude productiedatabase zodat u de wijzigingen kunt terugdraaien. U kunt vervolgens evalueren of u de oude productiedatabase verwijdert of deze indien nodig exporteert 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 zich voordoen 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 mySQL-metrische gegevens om te zien of uw workload de tijdelijke tabelgrootten in het geheugen overschrijdt

Met een leesintensieve workload kunnen query's die worden uitgevoerd op uw MySQL-server, de tijdelijke tabelgrootten in het geheugen overschrijden. Een leesintensieve workload 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. De created_tmp_table metrische waarde geeft aan hoeveel tijdelijke tabellen moeten worden gevormd in het geheugen, gezien uw workload. Als u wilt bepalen of het uitvoeren van een specifieke query tijdelijke tabellen gebruikt, 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 naar schijven lopen, 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 lager zijn dan 25%. Als u ziet dat het percentage 25% of hoger is, raden we u aan twee serverparameters te wijzigen, tmp_table_size en max_heap_table_size.

Databaseschema en query's

Hier volgen 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 vanwege onjuiste gegevenstypen.

Indexen gebruiken

U kunt indexen gebruiken om trage query's te voorkomen. Indexen kunnen helpen om snel rijen met specifieke kolommen te 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. Hiermee kunt u knelpunten of problemen met uw query detecteren. Zie UITLEG gebruiken om queryprestaties te profilen.