Dela via

Hög tillgänglighet i Azure Database for MySQL

Med Azure Database for MySQL – flexibel server kan du konfigurera hög tillgänglighet med automatisk redundans. Den här lösningen säkerställer att fel aldrig orsakar förlust av incheckade data och att databasen inte är en enda felpunkt i din programvaruarkitektur. När du konfigurerar hög tillgänglighet etablerar och hanterar flexibel server automatiskt en väntelägesreplik. Du betalar för den etablerade beräkningen och lagringen för både de primära och sekundära replikerna. Det finns två arkitekturmodeller med hög tillgänglighet:

  • Zonredundant hög tillgänglighet. Det här alternativet ger fullständig isolering och redundans för infrastruktur i flera tillgänglighetszoner. Den har den högsta tillgänglighetsnivån, men du måste konfigurera programredundans mellan zoner. Välj zonredundant HA när du vill skydda mot eventuella infrastrukturfel i tillgänglighetszonen och när svarstiden i tillgänglighetszonen är acceptabel. Du kan endast aktivera zonredundant HA när du skapar servern. Zonredundant HA är tillgängligt i en delmängd av Azure-regioner där regionen stöder flera tillgänglighetszoner och zonredundanta Premium-filresurser är tillgängliga.

  • Lokalt redundant hög tillförlitlighet Det här alternativet ger infrastrukturredundans med lägre nätverksfördröjning eftersom de primära servrarna och väntelägesservrarna finns i samma tillgänglighetszon. Den erbjuder hög tillgänglighet utan att du behöver konfigurera programredundans mellan zoner. Välj Lokalt redundant HA när du vill uppnå den högsta tillgänglighetsnivån i en enda tillgänglighetszon med den lägsta nätverksfördröjningen. Lokalredundant HA är tillgänglig i alla Azure-regioner där du kan använda Azure Database för MySQL Flexibel Server.

Arkitektur för zonredundant hög tillgänglighet (HA)

När du distribuerar en server med zonredundant hög tillgänglighet skapar Azure två servrar:

  • En primär server i en tillgänglighetszon.
  • En reservreplikserver i en annan tillgänglighetszon i samma Azure-region. Replikservern i vänteläge har samma konfiguration som den primära servern, inklusive beräkningsnivå, beräkningsstorlek, lagringsstorlek och nätverkskonfiguration.

Du kan välja tillgänglighetszon för både den primära servern och väntelägesrepliken. Om du placerar väntelägesdatabasservrar och väntelägesprogram i samma zon minskar svarstiden. Det hjälper dig också att förbereda dig för haveriberedskapssituationer och scenarier med "zon ned".

Diagram som visar arkitekturen för zonredundant hög tillgänglighet.

Data och loggfiler finns i zonredundant lagring (ZRS). Väntelägesservern läser och spelar kontinuerligt upp loggfilerna från den primära serverns lagringskonto, som replikering på lagringsnivå skyddar.

Om en redundansväxling inträffar:

  • Standby-repliken aktiveras.
  • De binära loggfilerna för den primära servern fortsätter att gälla för väntelägesservern för att få den online till den senast genomförda transaktionen på den primära servern.

Loggar i ZRS är tillgängliga även när den primära servern inte är tillgänglig. Den här tillgängligheten hjälper till att säkerställa att data inte går förlorade. När väntelägesrepliken har aktiverats och binära loggar har tillämpats tar den aktuella reservreplikservern rollen som den primära servern. DNS-uppdateringar så att klientanslutningar dirigeras till den nya primära när klienten återansluter. Redundansväxlingen är helt transparent från klientprogrammet och kräver ingen åtgärd från dig. HA-lösningen tar sedan tillbaka den gamla primära servern när det är möjligt och placerar den i vänteläge.

Du använder databasservernamnet för att ansluta program till den primära servern. Lösningen exponerar inte väntelägesreplikinformation för direkt åtkomst. Incheckningar och skrivningar bekräftas när loggfilerna har tömts på den primära serverns ZRS. På grund av synkroniseringsreplikeringstekniken som används i ZRS-lagring kan du förvänta dig 5–10 procent ökad svarstid för programskrivningar och incheckningar.

Automatiska säkerhetskopieringar, både ögonblicksbilder och loggsäkerhetskopior, utförs på zonredundant lagring från den primära databasservern.

Arkitektur för lokal redundant hög tillgänglighet (HA)

När du distribuerar en server med lokalt redundant ha skapar du två servrar i samma zon:

  • En primär server
  • En väntelägesreplikserver som har samma konfiguration som den primära servern (beräkningsnivå, beräkningsstorlek, lagringsstorlek och nätverkskonfiguration)

Väntelägesservern tillhandahåller infrastrukturredundans med en separat virtuell dator (beräkning). Den här redundansen minskar redundanstiden och nätverksfördröjningen mellan programmet och databasservern på grund av samlokalisering.

Diagram som visar arkitekturen för lokal redundant hög tillgänglighet.

Data- och loggfilerna finns i lokalt redundant lagring (LRS). Väntelägesservern läser och spelar kontinuerligt upp loggfilerna från den primära serverns lagringskonto, som skyddas av replikering på lagringsnivå.

Om en redundansväxling inträffar:

  • Standby-repliken aktiveras.
  • De binära loggfilerna för den primära servern fortsätter att gälla för väntelägesservern för att få den online till den senast genomförda transaktionen på den primära servern.

Loggar i LRS är tillgängliga även när den primära servern inte är tillgänglig. Den här tillgängligheten hjälper till att säkerställa att data inte går förlorade. När väntelägesrepliken har aktiverats och binära loggar har tillämpats tar den aktuella väntelägesrepliken rollen som den primära servern. DNS uppdateras för att omdirigera anslutningar till den nya primära när klienten återansluts. Redundansväxlingen är helt transparent från klientprogrammet och kräver ingen åtgärd från dig. HA-lösningen tar sedan tillbaka den gamla primära servern när det är möjligt och placerar den i vänteläge.

Databasservernamnet ansluter program till den primära servern. Väntelägesreplikinformation exponeras inte för direkt åtkomst. Incheckningar och skrivningar bekräftas när loggfilerna har tömts på den primära serverns LRS. Eftersom den primära repliken och väntelägesrepliken finns i samma zon finns det mindre replikeringsfördröjning och kortare svarstid mellan programservern och databasservern. Den lokalredundanta installationen ger inte hög tillgänglighet när beroende infrastrukturer är nere för den specifika tillgänglighetszonen. Det finns stilleståndstid tills alla beroende tjänster är online igen för den tillgänglighetszonen.

Automatiska säkerhetskopieringar, både ögonblicksbilder och loggsäkerhetskopior, utförs på lokalt redundant lagring från den primära databasservern.

Kommentar

För både zonredundant och lokalt redundant HA:

  • Om ett fel inträffar beror den tid som krävs för att väntelägesrepliken ska ta över rollen primär på den tid det tar att spela upp binärloggen från det primära lagringskontot till vänteläget. Om du vill minska redundanstiden använder du primära nycklar i alla tabeller. Redundansen tar vanligtvis mellan 60 och 120 sekunder.
  • Väntelägesservern är inte tillgänglig för läs- eller skrivåtgärder. Det är ett passivt vänteläge för att aktivera snabb redundans.
  • Använd alltid ett fullständigt domännamn (FQDN) för att ansluta till din primära server. Undvik att använda en IP-adress för att ansluta. Om en redundansväxling inträffar kan en DNS A-post ändras när de primära och väntelägesserverrollerna har växlats. Den ändringen förhindrar att programmet ansluter till den nya primära servern om en IP-adress används i anslutningssträngen.

Redundansväxling

Under redundansväxlingen i Azure Database for MySQL växlar systemet automatiskt från den primära servern till väntelägesrepliken. Den här växeln säkerställer kontinuitet och minimerar stilleståndstiden. När systemet upptäcker ett fel höjs väntelägesrepliken till den nya primära servern. Systemet tillämpar de binära loggfilerna från den ursprungliga primära servern på väntelägesrepliken. Den här processen synkroniserar väntelägesrepliken med den senast genomförda transaktionen och säkerställer ingen dataförlust. Den här sömlösa övergången bidrar till att upprätthålla hög tillgänglighet och tillförlitlighet för databastjänsten.

Kommentar

För att minska redundansberoendet av DNS-cachelagring, från och med oktober 2025, kommer alla nya HA-servrar som skapats med offentlig åtkomst eller privat länk att använda den nya arkitekturen med en dedikerad SLB för varje HA-server. Genom att hantera vägen för MySQL-datatrafiken eliminerar SLB behovet av DNS-ändringar under övervakning och förbättrar prestanda för failover avsevärt. Den omdirigerar trafik till den aktuella primära instansen under omkoppling vid systemfel genom att använda belastningsutjämningsregler. Befintliga servrar med offentlig åtkomst eller privat länk migreras gradvis för att minimera påverkan. Kunder som föredrar tidig migrering kan inaktivera och återaktivera HA. Den här funktionen stöds inte för servrar som använder privat åtkomst med VNet-integrering.

Planerad: Forcerad redundans

Azure Database for MySQL – flexibel server – tvingad redundans gör att du kan framtvinga en redundansväxling manuellt. Med den här funktionen kan du testa funktionerna med dina programscenarier och hjälpa dig att förbereda dig för avbrott.

Forcerad redundans utlöser en redundansväxling som aktiverar väntelägesrepliken så att den blir den primära servern med samma databasservernamn genom att uppdatera DNS-posten. Den ursprungliga primära servern startar om och växlar till väntelägesrepliken. Klientanslutningar kopplas från och måste återansluta för att återuppta sina åtgärder.

Den totala redundanstiden beror på den aktuella arbetsbelastningen och den senaste kontrollpunkten. I allmänhet tar det mellan 60 och 120 sekunder.

Kommentar

En Azure Resource Health-händelse genereras under en planerad redundansväxling. Händelsen representerar den redundanstid under vilken servern inte är tillgänglig. Du kan se de utlösta händelserna när de väljs i Resource Health i den vänstra rutan. Statusen representerar användarinitierad eller manuell redundans som "Ej tillgänglig" och taggad som "Planerad". Exempel – "En redundansåtgärd utlöstes av en behörig användare (planerad)". Om din resurs förblir i det här tillståndet under en längre period öppnar du ett supportärende och vi hjälper dig.

Oplanerad: Automatisk redundans

Oplanerad tjänstavbrott kan inträffa på grund av programvarufel eller infrastrukturfel, till exempel beräknings-, nätverks- eller lagringsfel. Strömavbrott kan också påverka databasens tillgänglighet. Om databasen blir otillgänglig stoppas replikeringen till väntelägesrepliken och väntelägesrepliken blir den primära databasen. DNS-uppdateringar sker och klienter återansluter till databasservern och återupptar sina åtgärder.

Den totala redundanstiden är vanligtvis mellan 60 och 120 sekunder. Men beroende på aktiviteten på den primära databasservern vid tidpunkten för redundansväxlingen (till exempel stora transaktioner och återställningstid) kan redundansväxlingen ta längre tid.

Kommentar

En Azure Resource Health-händelse genereras under en oplanerad redundansväxling. Händelsen representerar redundanstiden när servern inte är tillgänglig. Du kan se de utlösta händelserna när du väljer Resource Health i den vänstra rutan. Automatisk redundans visar statusen "Ej tillgänglig" och är taggad som "Oplanerad".

Till exempel Ej tillgänglig: En redundansåtgärd utlöstes automatiskt (oplanerad). Om din resurs är i det här tillståndet under en längre tid öppnar du ett supportärende så hjälper vi dig.

Så här fungerar automatisk redundansidentifiering på HA-aktiverade servrar

Den primära servern och den sekundära servern har två nätverksslutpunkter vardera:

  • Kundslutpunkt: Kunder ansluter och kör frågor på instansen med hjälp av den här slutpunkten.
  • Hanteringsslutpunkt: Används internt för tjänstkommunikation till hanteringskomponenter och för att ansluta till serverdelslagring.

Hälsoövervakarkomponenten utför kontinuerligt följande kontroller:

  • Övervakaren pingar nodens slutpunkt för hanteringsnätverket. Om den här kontrollen misslyckas två gånger i rad utlöser den en automatisk redundansåtgärd. Den här hälsokontrollen åtgärdar scenarier som otillgänglighet för noder eller bristande svar på grund av os-problem, nätverksproblem mellan hanteringskomponenter och noder och liknande problem.
  • Övervakaren kör en enkel fråga på instansen. Om frågorna inte kan köras utlöses automatisk redundans. Den här hälsokontrollen åtgärdar scenarier som MySQL-daemonkrascher, stopp eller låser sig samt problem med serverdelslagring och liknande problem.

Kommentar

Hälsokontrollen övervakar inte nätverksproblem mellan programmet och kundens nätverksslutpunkt (privat/offentlig åtkomst). Dessa problem kan uppstå i nätverkssökvägen, på slutpunkten eller i DNS-problem på klientsidan. Om du använder privat åtkomst kontrollerar du att NSG-reglerna för det virtuella nätverket inte blockerar kommunikationen till instansens kundnätverksslutpunkt på port 3306. För offentlig åtkomst kontrollerar du att brandväggsreglerna är inställda och att nätverkstrafik tillåts på port 3306 (om nätverkssökvägen har andra brandväggar). Du måste också ta hand om DNS-matchning från klientprogramsidan.

Övervaka hög tillgänglighet

Om du vill kontrollera serverns konfigurationsstatus för hög tillgänglighet använder du statusen för hög tillgänglighet i serverns fönster med hög tillgänglighet i portalen.

Status Beskrivning
NotEnabled (ej aktiverad) hög tillgänglighet är inte aktiverat.
Replikera data Väntelägesservern synkroniseras med den primära servern under serveretablering med hög tillgänglighet eller när du aktiverar alternativet för hög tillgänglighet.
Redundans Databasservern växlar över från den primära till vänteläget.
Frisk alternativet för hög tillgänglighet är aktiverat.
Ta bortStandby Borttagningsprocessen pågår när du inaktiverar alternativet för hög tillgänglighet.

Om du vill övervaka hälsotillståndet för servern med hög tillgänglighet använder du följande mått.

Måttvisningsnamn Mått Enhet beskrivning
HA-status IO ha_io_running Tillstånd HA-status IO visar tillståndet för HA-replikering. Måttvärdet är 1 om I/O-tråden körs och 0 om inte.
HA SQL-status ha_sql_running Tillstånd HA SQL-status visar tillståndet för HA-replikering. Måttvärdet är 1 om SQL-tråden körs och 0 om inte.
HA-replikeringsfördröjning replikeringsfördröjning Sekunder Replikeringsfördröjning är det antal sekunder som vänteläget ligger efter när transaktionerna som tas emot på den primära servern spelas upp igen.

Begränsningar

Tänk på följande när du använder hög tillgänglighet:

  • Du kan konfigurera zonredundant hög tillgänglighet endast när servern skapas.

  • Den burstbara beräkningsnivån har inte stöd för hög tillgänglighet.

  • Om du startar om den primära databasservern för att tillämpa statiska parameterändringar startas även väntelägesrepliken om.

  • Lösningen aktiverar GTID-läge eftersom den använder GTID. Kontrollera om din arbetsbelastning har begränsningar eller begränsningar för replikering med GTID:er.

Kommentar

Automatisk lagring är aktiverat som standard för en konfigurerad server med hög tillgänglighet och kan inte inaktiveras.

Hälsokontroller

När du konfigurerar hög tillgänglighet (HA) för Azure Database for MySQL spelar hälsokontroller en avgörande roll för att upprätthålla databasens tillförlitlighet och prestanda. Dessa kontroller övervakar kontinuerligt status och hälsa för både de primära replikerna och väntelägesreplikerna, vilket säkerställer att de identifierar eventuella problem snabbt. Genom att spåra olika mått, till exempel serverresponsivitet, replikeringsfördröjning och resursanvändning, hjälper hälsokontroller till att säkerställa att redundansprocesser kan köras sömlöst, vilket minimerar stilleståndstiden och förhindrar dataförlust. Korrekt konfigurerade hälsokontroller är viktiga för att uppnå önskad nivå av tillgänglighet och motståndskraft i databaskonfigurationen.

Övervaka hälsotillstånd

Du kan övervaka hälsotillståndet för ha-konfigurationen via Azure-portalen. Viktiga mått att observera är:

  • Serverresponsivitet: Anger om den primära servern kan nås.
  • Replikeringsfördröjning: Mäter fördröjningen mellan de primära replikerna och väntelägesreplikerna, vilket säkerställer datakonsekvens.
  • Resursanvändning: Övervakar cpu-, minnes- och lagringsanvändningen för att förhindra flaskhalsar.

Relaterat innehåll