Så här fungerar Azure Database for MySQL

Slutförd

I den här lektionen utforskar du hur Azure Database for MySQL fungerar, med början i dess arkitektur. Du lär dig också hur tjänsten ger hög tillgänglighet, säkerhetskopieringsfunktioner och skalning för att uppfylla arbetsbelastningens behov.

Azure Database for MySQL-arkitektur

I följande diagram beskrivs arkitekturen för en instans av Azure Database for MySQL – flexibel server.

1. MySQL-instansen körs på en virtuell Azure-dator.
2. Data och loggar lagras i Azure Premium Storage.
3. Data replikeras tre gånger över lokalt redundant lagring för säkerhetskopiering och återhämtning. Tjänsten innehåller också alternativ för att konfigurera zonredundanta eller geo-redundanta lagringssäkerhetskopior.
4. Dessutom har du möjlighet att samplaceera dina olika klientappar som är anslutna till den flexibla MySQL-servern inom samma tillgänglighetszon.

Du kan också välja hög tillgänglighet i samma zon eller zonredundant, vilket automatiskt etablerar och underhåller en standby-replik.

Så här fungerar hög tillgänglighet

För Azure Database for MySQL – flexibel server sker följande process i den enskilda tillgänglighetszonen efter ett värdserverfel:

1. Azure etablerar en ny virtuell dator (VM).
2. Azure mappar lagrings- och datafilerna till den nyligen etablerade virtuella datorn.
3. MySQL-databasmotorn är online.
4. Klientprogram återansluter till den nya MySQL-instansen.

Kommentar

Om du har etablerat hög tillgänglighet mellan zoner underhålls en server med frekvent vänteläge i en annan tillgänglighetszon i samma Azure-region. Den här servern är en fullständigt synkroniserad replik av den primära servern. I händelse av ett primärt serverfel kan den frekventa väntelägesservern snabbt ta över med minimala störningar och därmed upprätthålla tjänstens tillgänglighet.

Så här fungerar säkerhetskopieringar

Du kan använda säkerhetskopior för att återställa servern till valfri tidpunkt inom kvarhållningsperioden (35 dagar eller upp till 10 år med långsiktig kvarhållning i förhandsversionen).

Så här fungerar skalning

Skalning i Azure Database for MySQL innebär att justera beräkningsresurserna efter programmets behov, vilket kan variera baserat på användarnas efterfrågan, komplexiteten i de bearbetade åtgärderna eller andra faktorer som affärstillväxt. Den här flexibiliteten är avgörande för att upprätthålla optimal prestanda och kostnadseffektivitet.

Typer av skalning

1. Lodrät skalning (skala upp/ned)
   • Beräkningsskalning: Det här handlar om att ändra beräkningsnivån för din flexibla MySQL-server. Azure erbjuder flera beräkningsnivåer som var och en är utformad för olika typer av arbetsbelastningar:
     • Burstbar: Lämplig för miljöer med tillfälliga utbrott av CPU-användning som inte kräver kontinuerlig full CPU-prestanda.
     • Generell användning: Utformad för en mängd olika program, vilket ger en balans mellan beräknings-, minnes- och I/O-resurser.
     • Affärskritisk: Ger högsta prestanda för databaser, med kraftfullare processorer och snabbare I/O, som lämpar sig för arbetsbelastningar med hög transaktion och låg latens.
   • Minnes- och CPU-allokering: Beroende på den valda nivån kan du skala antalet virtuella kärnor och mängden RAM-minne som är tillgängligt för databasen, vilket direkt påverkar möjligheten att hantera större eller mer komplexa frågor och möjliggör ett större antal samtidiga anslutningar.
2. Vågrät skalning
   • Azure Database for MySQL kan skalas horisontellt genom att lägga till läsrepliker för att distribuera lästrafik över flera servrar, vilket förbättrar läsprestanda samtidigt som den primära servern hålls tillgänglig för skrivningar. Med horisontell skalning kan databasen hantera mer frågebelastning, vilket ökar programmets svarstider.
3. Lagringsskalning
   • Dynamisk lagringsskalning: Med Azure Database for MySQL kan du öka lagringskapaciteten utan avbrott. Du kan börja med en mindre allokering och skala upp när dina data växer.
   • Autogrow-funktion: Den här funktionen ökar automatiskt lagringsstorleken innan den når kapacitetsgränsen, vilket förhindrar eventuella störningar i samband med lagringsbegränsningar.

Autoskalning av IOPS

Autoskalning av IOPS (in- och utdataåtgärder per sekund) är en funktion som dynamiskt justerar I/O-dataflödet baserat på den aktuella arbetsbelastningen. Detta är särskilt användbart för oförutsägbara eller toppbenägna arbetsbelastningsmönster, eftersom det säkerställer att databasen kan hantera plötsliga ökningar av belastningen utan manuella åtgärder.

• IOPS-skalning baserat på belastning: När arbetsbelastningen ökar och mer I/O-dataflöde krävs ökar funktionen Autoskalning automatiskt IOPS-gränsen upp till det högsta tillåtna i den valda beräkningsnivån. Omvänt minskas IOPS under perioder med låg aktivitet för att minimera kostnaderna.
• Kostnadseffektivitet: Genom att automatiskt justera IOPS baserat på faktisk användning betalar du bara för den IOPS som du använder i stället för överetableringsresurser för att hantera belastningstoppar, vilket kanske bara sker sporadiskt.

Metodtips för skalning

Om du vill skala Azure Database for MySQL effektivt övervakar du prestandamått med Hjälp av Azure Monitor, konfigurerar kritiska aviseringar, planerar för framtida tillväxt genom att granska användningsmönster och testa skalbarhet under låg belastning för att säkerställa smidig prestanda under ökad belastning.

Genom att förstå och använda dessa skalningsmekanismer kan du se till att din flexibla Azure Database for MySQL-server alltid körs effektivt och anpassar sig till både företagets aktuella och framtida behov.

Konfigurera och finjustera motorbeteende

För att enkelt konfigurera och anpassa servervariabler och parametrar i Azure Database for MySQL kan du använda Azure Portal, Azure CLI eller REST API för att justera inställningar som frågecachestorlek, tidsgränser för anslutning och inställningar för lagringsmotorn, vilket säkerställer optimal prestanda och beteende för din specifika arbetsbelastning.

Fundera sedan på om Azure Database for MySQL uppfyller behoven i din organisation, dess appar och databasarbetsbelastningar.