Begrepp som rör hög tillgänglighet för Azure Database for MySQL – flexibel server

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

Med Azure Database for MySQL – flexibel server kan du konfigurera hög tillgänglighet med automatisk redundans. Lösningen för hög tillgänglighet är utformad för att säkerställa att incheckade data aldrig går förlorade på grund av fel, och att databasen inte är en felkritisk systemdel i programvaruarkitekturen. När hög tillgänglighet har konfigurerats tillhandahåller och hanterar flexibel server automatiskt en väntelägesreplik. Du debiteras för den etablerade beräkningen och lagringen för både den primära och sekundära repliken. Det finns två arkitekturmodeller med hög tillgänglighet:

• Zonredundant HA. Det här alternativet är att föredra för fullständig isolering och redundans för infrastruktur i flera tillgänglighetszoner. Det ger den högsta tillgänglighetsnivån, men du måste konfigurera programredundans mellan zoner. Zonredundant ha rekommenderas när du vill uppnå den högsta tillgänglighetsnivån mot eventuella infrastrukturfel i tillgänglighetszonen och när svarstiden i tillgänglighetszonen är acceptabel. Det kan bara aktiveras när servern skapas. 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.

• Ha i samma zon. Det här alternativet är att föredra för infrastrukturredundans med lägre nätverksfördröjning eftersom de primära servrarna och väntelägesservrarna kommer att finnas i samma tillgänglighetszon. Den ger hög tillgänglighet utan att du behöver konfigurera programredundans mellan zoner. Ha med samma zon är att föredra när du vill uppnå den högsta tillgänglighetsnivån i en enda tillgänglighetszon med den lägsta nätverksfördröjningen. Ha med samma zon är tillgängligt i alla Azure-regioner där du kan använda Azure Database for MySQL – flexibel server.

Zonredundant HA-arkitektur

När du distribuerar en server med zonredundant HA skapas två servrar:

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

Du kan välja tillgänglighetszonen för den primära repliken och väntelägesrepliken. Om du placerar väntelägesdatabasservrar och väntelägesprogram i samma zon minskar svarstiden. Du kan också förbereda dig bättre för haveriberedskapssituationer och scenarier med "zon ned".

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

Om det finns en redundansväxling:

• 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 senaste checkade transaktionen på den primära.

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 väntelägesreplikservern rollen som primär server. DNS uppdateras 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.

Databasservernamnet används för att ansluta 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 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.

Ha-arkitektur i samma zon

När du distribuerar en server med samma zon-HA skapas 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 erbjuder 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.

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

Om det finns en redundansväxling:

• 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 senaste checkade transaktionen på den primära.

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 används för att ansluta 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. Konfigurationen av samma zon ger inte hög tillgänglighet när beroende infrastrukturer är nere för den specifika tillgänglighetszonen. Det kommer att finnas 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 ha i samma zon:

• Om det uppstår ett fel 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. Därför rekommenderar vi att du använder primära nycklar i alla tabeller för att minska redundanstiden. Redundanstiden är 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 det sker en redundansväxling kan en DNS A-post ändras när de primära och väntelägesserverrollerna har växlats. Den ändringen skulle hindra programmet från att ansluta till den nya primära servern om en IP-adress används i anslutningssträng.

Redundansväxling

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 göra dig redo 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 startas om och växlas till väntelägesrepliken. Klientanslutningar kopplas från och måste återanslutas för att deras åtgärder ska återupptas.

Den totala redundanstiden beror på den aktuella arbetsbelastningen och den senaste kontrollpunkten. I allmänhet förväntas det ta mellan 60 och 120 sekunder.

Kommentar

Azure Resource Health-händelsen genereras i händelse av planerad redundansväxling, vilket representerar den redundanstid då servern inte var tillgänglig. De utlösta händelserna visas när du klickar på "Resource Health" i den vänstra rutan. Användarinitierad/Manuell redundans representeras av statusen "Ej tillgänglig" och taggas 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 tid öppnar du ett supportärende så hjälper vi dig.

Oplanerad: Automatisk redundans

Oplanerad tjänstavbrott kan orsakas av programbuggar eller infrastrukturfel som beräknings-, nätverks- eller lagringsfel eller strömavbrott som påverkar databasens tillgänglighet. Om databasen blir otillgänglig avbryts replikeringen till väntelägesrepliken och väntelägesrepliken aktiveras som den primära databasen. DNS uppdateras och klienterna återansluter till databasservern och återupptar sina åtgärder.

Den totala redundanstiden förväntas vara 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

Azure Resource Health-händelsen genereras i händelse av oplanerad redundansväxling, vilket representerar den redundanstid då servern inte var tillgänglig. De utlösta händelserna visas när du klickar på "Resource Health" i den vänstra rutan. Automatisk redundans representeras av statusen "Ej tillgänglig" och taggas som "Oplanerad". Exempel – "Ej tillgänglig: En redundansåtgärd utlöstes automatiskt (oplanerad)". Om din resurs förblir 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,

• Kundslutpunkt: Kunden 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 till nodernas hanteringsnätverksslutpunkt. Om den här kontrollen misslyckas två gånger kontinuerligt utlöser den automatisk redundansväxling. Scenariot som att noden inte är tillgänglig/inte svarar på grund av os-problem, nätverksproblem mellan hanteringskomponenter och noder osv. åtgärdas av den här hälsokontrollen.
• Övervakaren kör också en enkel fråga på instansen. Om frågorna inte kan köras utlöses automatisk redundans. Scenarier som MySQL demon crashed/stopped/hung, Backend storage issue etc., kommer att åtgärdas av den här hälsokontrollen.

Kommentar

Om det finns nätverksproblem mellan programmet och kundens nätverksslutpunkt (privat/offentlig åtkomst), antingen i nätverkssökvägen , på slutpunkten eller DNS-problem på klientsidan, övervakar hälsokontrollen inte det här scenariot. 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). DNS-matchningen från klientprogramsidan måste också tas om hand.

Övervakning för hög tillgänglighet

Den status för hög tillgänglighet som finns i serverns fönster med hög tillgänglighet i portalen kan användas för att fastställa serverns ha-konfigurationsstatus.

Status	Beskrivning
NotEnabled	HA är inte aktiverat.
ReplicatingData	Väntelägesservern håller på att synkroniseras med den primära servern vid tidpunkten för HA-serveretablering eller när HA-alternativet är aktiverat.
Redundans	Databasservern håller på att växla över från den primära till vänteläget.
Frisk	HA-alternativet är aktiverat.
RemovingStandby	När alternativet HA är inaktiverat och borttagningsprocessen pågår.

Du kan också använda måtten nedan för att övervaka hälsotillståndet för HA-servern.

Måttvisningsnamn	Mått	Enhet	beskrivning
HA I/O-status	ha_io_running	Tillstånd	HA IO-status anger 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 anger 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	replication_lag	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

Här följer några saker att tänka på när du använder hög tillgänglighet:

• Zonredundant hög tillgänglighet kan endast anges när den flexibla servern skapas.
• Hög tillgänglighet stöds inte på den burstbara beräkningsnivån.
• Om den primära databasservern startas om i syfte att hämta ändringar av statiska parametrar startas även väntelägesrepliken om.
• GTID-läget aktiveras eftersom HA-lösningen använder GTID. Kontrollera om din arbetsbelastning har begränsningar eller begränsningar för replikering med GTID:er.

Kommentar

Om du aktiverar ha i samma zon efter att servern har skapats måste du se till att serverparametrarna enforce_gtid_consistency" och "gtid_mode" är inställda på PÅ innan du aktiverar HA.

Kommentar

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

Vanliga frågor och svar

• Vad är serviceavtalen för samma zon jämfört med zonredundant HA aktiverad flexibel server?

  SLA-information för Azure Database for MySQL – flexibel server finns i SLA för Azure Database for MySQL.

• Hur debiteras jag för högtillgängliga servrar (HA) ? Servrar med HA aktiverat har en primär och sekundär replik. Den sekundära repliken kan vara i samma zon eller zonredundant. Du debiteras för den etablerade beräkningen och lagringen för både den primära och sekundära repliken. Om du till exempel har en primär med 4 virtuella kärnors beräkning och 512 GB etablerat lagringsutrymme kommer din sekundära replik också att ha 4 virtuella kärnor och 512 GB etablerat lagringsutrymme. Din zonredundanta HA-server kommer att faktureras för 8 virtuella kärnor och 1 024 GB lagringsutrymme. Beroende på din lagringsvolym för säkerhetskopior kan du också debiteras för lagring av säkerhetskopior.

• Kan jag använda väntelägesrepliken för läs- eller skrivåtgärder?
  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.

• Kommer jag att förlora data när redundansväxling sker?
  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 rollen som primär server.
  

• Behöver jag vidta några åtgärder efter en redundansväxling?
  Redundansväxlingar är helt transparenta från klientprogrammet. Du behöver inte vidta några åtgärder. Program bör bara använda logiken för återförsök för sina anslutningar.
  

• Vad händer när jag inte väljer en specifik zon för min standby-replik? Kan jag ändra zonen senare?
  Om du inte väljer en zon väljs en slumpmässigt. Det är den som används för den primära servern. Om du vill ändra zonen senare kan du ange Hög tillgänglighet till Inaktiverad i fönstret Hög tillgänglighet och sedan ställa in den på Zonredundant och välja en zon.
  

• Är replikeringen mellan de primära replikerna och väntelägesreplikerna synkrona?
  Replikeringen mellan det primära och vänteläget liknar semisynkront läge i MySQL. När en transaktion har checkats in checkas den inte nödvändigtvis in i vänteläget. Men när den primära är otillgänglig replikerar vänteläget alla dataändringar från den primära för att se till att inga data går förlorade.
  

• Finns det en redundansväxling till väntelägesrepliken för alla oplanerade fel?
  Om det uppstår ett databaskrasch- eller nodfel startas den virtuella datorn för flexibel server om på samma nod. Samtidigt utlöses en automatisk redundansväxling. Om omstarten av den flexibla serverdatorn lyckas innan redundansväxlingen är klar avbryts redundansåtgärden. Vilken server som ska användas som primär replik beror på vilken process som slutförs först.
  

• Finns det en prestandapåverkan när jag använder HA?
  För zonredundant HA kan svarstiden för skrivfråga minska med upp till 40 procent, även om det inte finns någon större prestandapåverkan för läsarbetsbelastningar i tillgänglighetszoner. Ökningen av skrivfördröjning beror på synkron replikering i tillgänglighetszonen. Påverkan på skrivsvarstid är vanligtvis två gånger i zonredundant HA jämfört med samma zon-HA. Eftersom den primära repliken och väntelägesrepliken finns i samma zon för samma zon är replikeringsfördröjningen och därmed den synkrona skrivfördröjningen lägre för samma zon. Sammanfattningsvis, om skrivfördröjning är mer kritiskt för dig jämfört med tillgänglighet, kanske du vill välja ha i samma zon, men om tillgänglighet och återhämtning av dina data är mer kritiskt för dig på bekostnad av skrivfördröjning, måste du välja zonredundant HA. För att mäta den korrekta effekten av svarstidsminskningen i HA-konfigurationen rekommenderar vi att du utför prestandatestning för din arbetsbelastning för att fatta ett välgrundat beslut.
  

• Hur sker underhållet av min HA-server?
  Planerade händelser som skalning av beräknings- och delversionsuppgraderingar sker först på den ursprungliga väntelägesinstansen, och därefter utlöses en planerad redundansåtgärd och körs sedan på den ursprungliga primära instansen. Du kan ange det schemalagda underhållsfönstret för HA-servrar precis som för flexibla servrar. Stilleståndstiden är samma som stilleståndstiden för Azure Database for MySQL– flexibel server-instans när HA är inaktiverat.
  

• Kan jag göra en återställning till tidpunkt (PITR) för min HA-server?
  Du kan göra en PITR för en HA-aktiverad Azure Database for MySQL – flexibel serverinstans till en ny Azure Database for MySQL – flexibel serverinstans som har inaktiverat ha. Om källservern skapades med zonredundant HA kan du aktivera zonredundant HA eller ha i samma zon på den återställda servern senare. Om källservern skapades med ha i samma zon kan du bara aktivera ha i samma zon på den återställde servern.
  

• Kan jag aktivera HA på en server när jag har skapat servern?
  Zonredundant HA måste aktiveras när servern skapas. Du kan aktivera ha i samma zon när du har skapat servern. Innan du aktiverar samma zon ha se till att serverparametrarna enforce_gtid_consistency" och "gtid_mode" är inställda på PÅ
  

• Kan jag inaktivera HA för en server när jag har skapat den?
  Du kan inaktivera HA på en server när du har skapat den. Faktureringen stoppas omedelbart.
  

• Hur kan jag minska stilleståndstiden?
  Du måste kunna minska stilleståndstiden för ditt program även när du inte använder HA. Tjänstavbrott, till exempel schemalagda korrigeringar, delversionsuppgraderingar eller kundinitierade åtgärder som skalning av beräkning, kan utföras under schemalagda underhållsperioder. För att minska programpåverkan för Azure-initierade underhållsaktiviteter kan du schemalägga dem en dag i veckan och tid som minimerar effekten på programmet.
  

• Kan jag använda en läsreplik för en HA-aktiverad server?
  Ja, läsrepliker stöds för HA-servrar.
  

• Kan jag använda datareplikering för HA-servrar?
  Stöd för datareplikering för hög tillgänglighet (HA) aktiverad server är endast tillgängligt via GTID-baserad replikering. Den lagrade proceduren för replikering med GTID är tillgänglig på alla HA-aktiverade servrar med namnet mysql.az_replication_with_gtid.

• Kan jag växla över till väntelägesservern när servern startas om eller vid upp- eller nedskalning för att minska stilleståndstiden?
  För närvarande har Azure Database for MySQL – flexibel server använt planerad redundans för att välja ha-åtgärder, inklusive upp-/nedskalning och planerat underhåll för att minska stilleståndstiden. När sådana åtgärder startades skulle den fungera på den ursprungliga väntelägesinstansen först, följt av att utlösa en planerad redundansåtgärd och sedan köras på den ursprungliga primära instansen.
  

• Kan vi ändra tillgänglighetsläget (zonredundant HA/samma zon) för servern
  Om du skapar servern med zonredundant HA-läge aktiverat kan du ändra från Zonredundant HA till samma zon och vice versa. Om du vill ändra tillgänglighetsläget kan du ange Hög tillgänglighet till Inaktiverad i fönstret Hög tillgänglighet och sedan återgå till Zonredundant eller samma zon och välja Läge för hög tillgänglighet.
  

Nästa steg

• Lär dig mer om affärskontinuitet.
• Läs mer om zonredundant hög tillgänglighet.
• Läs mer om säkerhetskopiering och återställning.