Metodtips för att skapa ett program med Azure Database for MySQL

  • Artikel
  • 6 minuter för att läsa

GÄLLER FÖR: Azure Database for MySQL – enskild server Azure Database for MySQL – flexibel server

Här är några metodtips som hjälper dig att skapa ett molnklart program med hjälp av Azure Database for MySQL. Dessa metodtips kan minska utvecklingstiden för din app.

Konfiguration av program- och databasresurser

Behåll programmet och databasen i samma region

Se till att alla dina beroenden finns i samma region när du distribuerar programmet i Azure. Om instanser sprids mellan regioner eller tillgänglighetszoner uppstår nätverksfördröjning, vilket kan påverka programmets övergripande prestanda.

Skydda MySQL-servern

Konfigurera MySQL-servern så att den är säker och inte tillgänglig offentligt. Använd något av följande alternativ för att skydda din server:

Av säkerhetsskäl måste du alltid ansluta till MySQL-servern via SSL och konfigurera MySQL-servern och programmet att använda TLS 1.2. Se Så här konfigurerar du SSL/TLS.

Använda avancerade nätverk med AKS

När accelererat nätverk är aktiverat på en virtuell dator finns det kortare svarstid, mindre jitter och minskad processoranvändning på den virtuella datorn. Mer information finns i Metodtips för Azure Kubernetes Service och Azure Database for MySQL

Finjustera serverparametrarna

För läsintensiva arbetsbelastningar som finjusterar serverparametrar och tmp_table_size kan hjälpa till att optimera för bättre max_heap_table_size prestanda. Om du vill beräkna de värden som krävs för dessa variabler tittar du på de totala minnesvärdena per anslutning och basminnet. Summan av minnesparametrar per anslutning, exklusive , i tmp_table_size kombination med basminneskontona för serverns totala minne.

Om du vill beräkna den största möjliga storleken tmp_table_size för och använder du följande max_heap_table_size formel:

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

Anteckning

Totalt minne anger den totala mängden minne som servern har över de etablerade virtuella kärnorna. I en Generell användning två virtuella kärnor Azure Database for MySQL är det totala minnet 5 GB * 2. Mer information om minne för varje nivå finns i dokumentationen om prisnivåer.

Basminnet anger minnesvariablerna, till query_cache_size exempel och , som innodb_buffer_pool_size MySQL initierar och allokerar när servern startas. Minne per anslutning, som sort_buffer_size och , är minne som endast join_buffer_size allokeras när en fråga behöver det.

Skapa icke-administratörsanvändare

Skapa icke-administratörsanvändare för varje databas. Normalt identifieras användarnamnen som databasnamn.

Återställa lösenordet

Du kan återställa lösenordet för MySQL-servern med hjälp av Azure Portal.

Om du återställer serverlösenordet för en produktionsdatabas kan programmet bli av. Det är en bra idé att återställa lösenordet för produktionsarbetsbelastningar vid låg belastning för att minimera påverkan på programmets användare.

Prestanda och återhämtning

Här är några verktyg och metoder som du kan använda för att felsöka prestandaproblem med ditt program.

Aktivera långsamma frågeloggar för att identifiera prestandaproblem

Du kan aktivera långsamma frågeloggar och granskningsloggar på servern. Genom att analysera långsamma frågeloggar kan du identifiera prestandaflaskhalsar för felsökning.

Granskningsloggar är också tillgängliga via Azure Diagnostics i Azure Monitor, Azure Event Hubs och lagringskonton. Se Så här felsöker du problem med frågeprestanda.

Använda anslutningspooler

Hantering av databasanslutningar kan ha en betydande inverkan på programmets prestanda som helhet. För att optimera prestandan måste du minska antalet gånger som anslutningar upprättas och tiden för att upprätta anslutningar i nyckelkodsökvägar. Använd anslutningspooler för att ansluta till Azure Database for MySQL för att förbättra återhämtning och prestanda.

Du kan använda ProxySQL-anslutningspoolen för att effektivt hantera anslutningar. Om du använder en anslutningspool kan du minska inaktiva anslutningar och återanvända befintliga anslutningar, vilket hjälper dig att undvika problem. Mer information finns i Konfigurera ProxySQL.

Logik för omprövning för att hantera tillfälliga fel

Programmet kan uppleva tillfälliga fel där anslutningar till databasen tas bort eller förloras tillfälligt. I sådana situationer är servern igång och körs efter ett till två återförsök på 5 till 10 sekunder.

En bra idé är att vänta i 5 sekunder innan ditt första återförsök. Följ sedan varje återförsök genom att öka väntetiden gradvis, upp till 60 sekunder. Begränsa det maximala antalet återförsök då programmet anser att åtgärden misslyckades, så att du sedan kan undersöka vidare. Mer information finns i Felsöka anslutningsfel.

Aktivera läsreplikering för att minimera redundans

Du kan använda Datareplikering för redundansscenarier. När du använder skrivskyddade repliker sker ingen automatisk redundans mellan käll- och replikservrar.

Du ser en fördröjning mellan källan och repliken eftersom replikeringen är asynkron. Nätverksfördröjning kan påverkas av många faktorer, till exempel storleken på arbetsbelastningen som körs på källservern och svarstiden mellan datacenter. I de flesta fall varierar replikfördröjning från några sekunder till några minuter.

Databasdistribution

Konfigurera en Azure Database for MySQL-uppgift i din CI/CD-distributionspipeline

Ibland behöver du distribuera ändringar i databasen. I sådana fall kan du använda kontinuerlig integrering (CI) och kontinuerlig leverans (CD) via Azure Pipelines och använda en uppgift för din MySQL-server för att uppdatera databasen genom att köra ett anpassat skript mot den.

Använda en effektiv process för manuell databasdistribution

Under manuell databasdistribution följer du dessa steg för att minimera driftstopp eller minska risken för misslyckad distribution:

  1. Skapa en kopia av en produktionsdatabas på en ny databas med hjälp av mysqldump eller MySQL Workbench.
  2. Uppdatera den nya databasen med dina nya schemaändringar eller uppdateringar som behövs för databasen.
  3. Placera produktionsdatabasen i skrivskyddade tillstånd. Du bör inte ha skrivåtgärder på produktionsdatabasen förrän distributionen har slutförts.
  4. Testa programmet med den nyligen uppdaterade databasen från steg 1.
  5. Distribuera dina programändringar och se till att programmet nu använder den nya databasen som har de senaste uppdateringarna.
  6. Behåll den gamla produktionsdatabasen så att du kan återställa ändringarna. Du kan sedan utvärdera för att antingen ta bort den gamla produktionsdatabasen eller exportera den på Azure Storage om det behövs.

Anteckning

Om programmet är som en e-handelsapp och du inte kan försätta det i skrivskyddade tillstånd distribuerar du ändringarna direkt på produktionsdatabasen när du har gjort en säkerhetskopia. Dessa ändringar bör ske vid låg belastning med låg trafik till appen för att minimera påverkan, eftersom vissa användare kan uppleva misslyckade begäranden.

Kontrollera att programkoden även hanterar misslyckade begäranden.

Använd inbyggda MySQL-mått för att se om din arbetsbelastning överskrider storlekarna för temporära tabeller i minnet

Med en läsintensiva arbetsbelastning kan frågor som körs mot din MySQL-server överskrida de temporära tabellstorlekarna i minnet. En läsintensiva arbetsbelastning kan göra att servern växlar till att skriva temporära tabeller till disk, vilket påverkar programmets prestanda. Titta på följande mått för att avgöra om servern skriver till disk på grund av att den temporära tabellstorleken överskrids:

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

Måttet created_tmp_disk_tables anger hur många tabeller som skapades på disken. Måttet created_tmp_table visar hur många temporära tabeller som måste skapas i minnet, givet din arbetsbelastning. Om du vill avgöra om en specifik fråga ska använda temporära tabeller kör du EXPLAIN-instruktionen på frågan. Information i kolumnen anger extra om frågan ska köras med hjälp av Using temporary temporära tabeller.

Om du vill beräkna procentandelen av din arbetsbelastning med frågor som spills till diskar använder du dina måttvärden i följande formel:

(created_tmp_disk_tables / (created_tmp_disk_tables + created_tmp_tables)) * 100

Vi rekommenderar att den här procentandelen är mindre än 25 %. Om du ser att procentandelen är 25 % eller högre föreslår vi att du ändrar två serverparametrar, tmp_table_size och max_heap_table_size.

Databasschema och frågor

Här är några tips att tänka på när du skapar ditt databasschema och dina frågor.

Använd rätt datatyp för dina tabellkolumner

Om du använder rätt datatyp baserat på vilken typ av data du vill lagra kan du optimera lagringen och minska fel som kan inträffa på grund av felaktiga datatyper.

Använda index

Du kan använda index för att undvika långsamma frågor. Index kan hjälpa dig att snabbt hitta rader med specifika kolumner. Se Använda index i MySQL.

Använd EXPLAIN för DINA SELECT-frågor

Använd EXPLAIN -instruktionen för att få insikter om vad MySQL gör för att köra frågan. Det kan hjälpa dig att identifiera flaskhalsar eller problem med din fråga. Se Så här använder du EXPLAIN för att profilera frågeprestanda.