Share via

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

  • Artikel

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

Viktigt!

Azure Database for MySQL – enskild server är på väg att dras tillbaka. Vi rekommenderar starkt att du uppgraderar till en flexibel Azure Database for MySQL-server. Mer information om hur du migrerar till en flexibel Azure Database for MySQL-server finns i Vad händer med Azure Database for MySQL – enskild server?

Här följer 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 ditt program i Azure. Att sprida instanser mellan regioner eller tillgänglighetszoner skapar 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 servern:

För säkerhet måste du alltid ansluta till MySQL-servern via SSL och konfigurera MySQL-servern och ditt program för att använda TLS 1.2. Se Konfigurera SSL/TLS.

Använda avancerade nätverk med AKS

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

Justera serverparametrarna

För läsintensiva arbetsbelastningar justerar du serverparametrar tmp_table_size och max_heap_table_size kan optimera för bättre prestanda. Om du vill beräkna de värden som krävs för dessa variabler tittar du på de totala värdena per anslutning och basminne. Summan av minnesparametrarna per anslutning, exklusive tmp_table_size, kombinerat med basminneskontona för serverns totala minne.

Om du vill beräkna största möjliga storlek på tmp_table_size och max_heap_table_sizeanvänder du följande formel:

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

Kommentar

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

Basminnet anger de minnesvariabler, som och innodb_buffer_pool_size, som query_cache_size MySQL initierar och allokerar när servern startar. Minne per anslutning, som och join_buffer_size, är det minne som sort_buffer_size bara allokeras när en fråga behöver det.

Skapa användare som inte är användare

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

Återställa lösenordet

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

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

Prestanda och återhämtning

Här följer några verktyg och metoder som hjälper dig att felsöka programmets prestandaproblem.

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 flaskhalsar i prestanda för felsökning.

Granskningsloggar är också tillgängliga via Azure Diagnostics-loggar i Azure Monitor-loggar, Azure Event Hubs och lagringskonton. Se Felsöka problem med frågeprestanda.

Använda anslutningspooler

Att hantera databasanslutningar kan ha en betydande inverkan på programmets prestanda som helhet. För att optimera prestandan måste du minska antalet gånger 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 hantera anslutningar effektivt. Om du använder en anslutningspool kan du minska antalet inaktiva anslutningar och återanvända befintliga anslutningar, vilket hjälper dig att undvika problem. Mer information finns i Konfigurera ProxySQL .

Omförsökslogik 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 efter en till två återförsök på 5 till 10 sekunder.

Det är bra att vänta i 5 sekunder innan du försöker igen. Följ sedan varje nytt fö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 kan undersöka saken ytterligare. Mer information finns i Felsöka anslutningsfel .

Aktivera läsreplikering för att minska redundansväxlingar

För redundansscenarier kan du använda Datareplikering. Ingen automatiserad redundansväxling mellan käll- och replikservrar sker när läsrepliker används.

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öjningen från några sekunder till några minuter.

Databasdistribution

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

Ibland måste du distribuera ändringar till 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 den manuella databasdistributionen följer du dessa steg för att minimera stilleståndstiden eller minska risken för misslyckad distribution:

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

Kommentar

Om programmet är som en e-handelsapp och du inte kan placera det i skrivskyddat tillstånd distribuerar du ändringarna direkt i produktionsdatabasen när du har gjort en säkerhetskopia. Dessa ändringar bör ske under låg belastning med låg trafik till appen för att minimera effekten 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 minnesinterna tillfälliga tabellstorlekar

Med en läsintensiv arbetsbelastning kan frågor mot MySQL-servern överskrida de minnesinterna tillfälliga tabellstorlekarna. En läsintensiv arbetsbelastning kan göra att servern växlar till att skriva temporära tabeller till disk, vilket påverkar programmets prestanda. Om du vill ta reda på om servern skriver till disken på grund av att den tillfälliga tabellstorleken överskrids kan du titta på följande mått:

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 har skapats på disken. Med tanke på din arbetsbelastning visar måttet created_tmp_table hur många temporära tabeller som måste skapas i minnet. Om du vill ta reda på om en specifik fråga använder tillfälliga tabeller kör du EXPLAIN-instruktionen på frågan. Informationen i extra kolumnen anger Using temporary om frågan körs med hjälp av tillfälliga 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

Den här procentandelen bör helst vara mindre än 25 %. Om procentandelen är 25 % eller högre föreslår vi att du ändrar två serverparametrar, tmp_table_size och max_heap_table_size.

Databasscheman och frågor

Här följer några tips att komma ihåg 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 lagring och minska fel på grund av felaktiga datatyper.

Använda index

Om du vill undvika långsamma frågor kan du använda index. Index kan hjälpa dig att snabbt hitta rader med specifika kolumner. Se Använda index i MySQL.

Använda EXPLAIN för dina SELECT-frågor

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