Dela via

Metodtips för serveråtgärder i Azure Database for MySQL – flexibel server

  • Artikel

Lär dig mer om metodtipsen för att arbeta med Azure Database for MySQL – flexibel server. När vi lägger till nya funktioner i plattformen fortsätter vi att fokusera på att förfina de metodtips som beskrivs i det här avsnittet.

Driftsriktlinjer för Azure Database for MySQL – flexibel server

Följande är driftsriktlinjer som bör följas när du arbetar med Azure Database for MySQL – flexibel server för att förbättra databasens prestanda:

  • Samplats: Om du vill minska nätverksfördröjningen placerar du klienten och databasservern i samma Azure-region.

  • Övervaka din minnes-, CPU- och lagringsanvändning: Du kan ställa in aviseringar för att meddela dig när användningsmönstren ändras eller när du närmar dig kapaciteten för distributionen, så att du kan upprätthålla systemets prestanda och tillgänglighet.

  • Accelererade loggar för förbättrad prestanda: Aktivera funktionen för accelererade loggar optimerar transaktionsloggrelaterade åtgärder, vilket ökar serverns dataflöde och prestanda. Den här funktionen, som är tillgänglig utan extra kostnad, är ett betydande tillägg till bästa praxis för användare av Affärskritisk tjänstnivå.

  • Skala upp din DB-instans: Du kan skala upp när du närmar dig lagringskapacitetsgränser. Du bör ha en buffert i lagring och minne för att hantera oförutsedda ökningar av efterfrågan från dina program. Du kan också aktivera funktionen för automatisk lagringsväxning "PÅ" bara för att säkerställa att tjänsten automatiskt skalar lagringen när den närmar sig lagringsgränserna.

  • Konfigurera säkerhetskopior: Aktivera lokala eller geo-redundanta säkerhetskopior baserat på företagets krav. Dessutom ändrar du kvarhållningsperioden för hur länge säkerhetskopiorna är tillgängliga för affärskontinuitet.

  • Optimera I/O-kapacitet med autoskalnings-IOPS: Om databasarbetsbelastningen kräver mer I/O än etablerad går det långsamt att återställa eller utföra andra transaktionsåtgärder för databasen. Om du vill öka I/O-kapaciteten för en serverinstans gör du något av följande:

    • Använd autoskalnings-IOPS: Autoskalning av IOPS eliminerar behovet av att etablera ett visst antal I/O-åtgärder per sekund. I stället kan servern automatiskt justera IOPS baserat på arbetsbelastningskrav1. Det innebär att servern kan skala upp eller ned IOPS automatiskt beroende på arbetsbelastningsbehov.

    • Azure Database for MySQL – flexibel server tillhandahåller IOPS-skalning med en hastighet av tre IOPS per GB-lagring som etablerats. Öka den etablerade lagringen för att skala IOPS för bättre prestanda.

    • Om du redan använder Etablerad IOPS-lagring etablerar du ytterligare kapacitet för dataflöde.

  • Skalningsberäkning: Databasarbetsbelastningen kan också begränsas på grund av PROCESSOR eller minne och detta kan ha stor inverkan på transaktionsbearbetningen. Beräkning (prisnivå) kan skalas upp eller ned mellan nivåerna Generell användning eller Minnesoptimerad.

  • Test för redundans: Testa redundans för serverinstansen manuellt för att förstå hur lång tid processen tar för ditt användningsfall och för att säkerställa att programmet som kommer åt serverinstansen automatiskt kan ansluta till den nya serverinstansen efter redundansväxlingen.

  • Använd primärnyckel: Kontrollera att tabellerna har en primär eller unik nyckel när du arbetar på Azure Database for MySQL – flexibel serverinstans. Detta hjälper till att ta säkerhetskopior, repliker osv. och förbättrar prestandan.

  • Konfigurera TTL-värde: Om klientprogrammet cachelagrar DNS-data (Domain Name Service) för dina serverinstanser anger du ett TTL-värde (time-to-live) på mindre än 30 sekunder. Eftersom den underliggande IP-adressen för en serverinstans kan ändras efter en redundansväxling kan cachelagring av DNS-data under en längre tid leda till anslutningsfel om programmet försöker ansluta till en IP-adress som inte längre är i tjänst.

  • Använd anslutningspooler för att undvika att överskrida de maximala anslutningsgränsernaoch använda logik för återförsök för att undvika tillfälliga anslutningsproblem.

  • Om du använder replik använder du ProxySQL för att balansera belastningen mellan den primära servern och den läsbara sekundära replikservern. Se installationsstegen här.

  • När du etablerar resursen kontrollerar du att du har aktiverat automatisk tillväxt för din Azure Database for MySQL– flexibel serverinstans. Detta lägger inte till någon extra kostnad och skyddar databasen från eventuella flaskhalsar i lagringen som du kan stöta på.

Använda InnoDB med Azure Database for MySQL – flexibel server

  • Om du använder ibdata1 funktionen, som är en systemtabellrymdsdatafil, kan den inte krympas eller rensas genom att data tas bort från tabellen, eller så flyttas tabellen till fil-per-tabell tablespaces.

  • För en databas som är större än 1 TB bör du skapa tabellen i innodb_file_per_table tablespace. För en enskild tabell som är större än 1 TB bör du använda partitionstabellen.

  • För en server som har ett stort antal tablespaceär motorstarten mycket långsam på grund av den sekventiella tabellområdessökningen under start eller redundansväxling av Azure Database for MySQL – flexibel server.

  • Ange innodb_file_per_table = PÅ innan du skapar en tabell, om det totala tabellnumret är mindre än 500.

  • Om du har fler än 500 tabeller i en databas granskar du tabellstorleken för varje enskild tabell. För en stor tabell bör du fortfarande överväga att använda tabellområdet file-per-table för att undvika att systemtabellytans fil når maximal lagringsgräns.

Kommentar

Överväg att använda systemtabellområdet för tabeller med en storlek som är mindre än 5 GB

CREATE TABLE tbl_name ... *TABLESPACE* = *innodb_system*;

  • Partitionera tabellen när du skapar tabellen om du har en stor tabell som potentiellt kan växa över 1 TB.

  • Använd flera Azure Database for MySQL– flexibla serverinstanser och sprid tabellerna över dessa servrar. Undvik att placera för många tabeller på en enskild server om du har cirka 10 000 tabeller eller mer.

Relaterat innehåll