Hög tillgänglighet i Azure Database for MySQL

Med hjälp av 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 standby-Hyper-V replik. Du betalar för de tilldelade beräknings- och lagringsresurserna för både de primära och sekundära replikerna. Det finns två arkitekturmodeller med hög tillgänglighet:

• Zon-redundant hög drifttillgänglighet. Det här alternativet ger fullständig isolering och redundans för infrastruktur över flera tillgänglighetszoner. Den har den högsta tillgänglighetsnivån, men du måste konfigurera programredundans mellan zoner. Välj zonredundant hög tillgänglighet 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 hög tillgänglighet när du skapar servern. Zonredundant hög tillgänglighet finns i en delmängd av Azure-regioner där regionen stödjer flera tillgänglighetszoner och zonredundanta Premium-filresurser finns tillgängliga.

• Lokalredundant hög tillgänglighet. 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 lokal redundant hög tillgänglighet när du vill uppnå den högsta tillgänglighetsnivån i en enda tillgänglighetszon med den lägsta nätverksfördröjningen. Lokal-redundant hög tillgänglighet är tillgänglig i alla Azure-regioner där du kan använda Azure Database for MySQL Flexible 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 väntelägesreplikserver 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, storage storlek och nätverkskonfiguration.

Du kan välja tillgänglighetszon för både den primära servern och väntelägesrepliken. Att placera den primära servern och väntelägesservern i samma zon minskar svarstiden, medan om du placerar dem i olika zoner kan du förbereda dig för haveriberedskapssituationer och zon-down-scenarier.

Data- och loggfilerna finns i zonredundant lagring (ZRS). Väntelägesservern läser och spelar kontinuerligt upp loggfilerna från den primära serverns lagringskonto, vilket lagringsreplikering 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 uppdateras så att klientanslutningar dirigeras till den nya primära när klienten återansluter. Failovern ä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 access. 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 storage kan du förvänta dig 5–10 procent ökad svarstid för programskrivningar och incheckningar.

Den primära databasservern säkerhetskopierar automatiskt både snapshots och loggbackuper på zonredundant lagring.

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, storage storlek och nätverkskonfiguration)

Väntelägesservern tillhandahåller infrastrukturredundans med hjälp av 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 lagras i lokalt redundant lagring (LRS). Väntelägesservern läser och spelar kontinuerligt upp loggfilerna från den primära serverns storage-konto, som skyddas av replikering på storage nivå.

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. Failovern ä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. Kommandon och skrivningar bekräftas efter att loggfilerna har tömts på LRS hos den primära servern. 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 lokala redundanta konfigurationen 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.

Den primära databasservern säkerhetskopierar automatiskt både ögonblicksbilder och loggfiler till lokalt redundant lagring.

Migrera från en befintlig server till en zonredundant server

Om du ursprungligen etablerade din Azure Database for MySQL-server som en icke-HA-server kan du aktivera den för lokalt redundant HA-arkitektur. Men om du vill aktivera den för zonredundant HA-arkitektur måste du skapa en ny server med önskad konfiguration och migrera till den genom att följa dessa steg:

1. Skapa en ny server med zonredundant hög tillgänglighet aktiverad genom att följa anvisningarna för det distributionsverktyg du föredrar:

   • Azure portal: Hantera zonredundant hög tillgänglighet i Azure Database for MySQL med Azure-portalen
   • Azure CLI: Hantera zonredundant hög tillgänglighet i Azure Database for MySQL med Azure CLI

2. Migrera arbetsbelastningen till den nya servern genom att följa någon av dessa metoder. Beroende på migreringsmetoden kan stilleståndstid krävas.

   • Offlinemigreringsmetoder: Om ditt program har råd med viss stilleståndstid är offlinemigreringar alltid det bästa valet, eftersom de är enkla och enkla att köra. Med en offlinemigrering tas källservern offline och en dump och återställning av databaserna utförs på målservern. Det här alternativet kräver mest stilleståndstid. Varaktigheten för stilleståndstiden bestäms av den tid det tar att utföra återställningen på målservern.

     • Data Migration Service (DMS): Mer information om hur du använder DMS finns i Migrera från MySQL till Azure Database for MySQL offline med DMS via Azure-portalen.

       Självstudien beskriver steg för migrering från en lokal MySQL-server till Azure Database for MySQL, men du kan använda samma procedur för att migrera data från en Azure Database for MySQL-server utan stöd för tillgänglighetszoner till en annan med stöd för tillgänglighetszoner.

     • Verktyg med öppen källkod: Du kan migrera offline med hjälp av verktyg med öppen källkod, till exempel MySQL Workbench, mydumper/myloader eller mysqldump för att säkerhetskopiera och återställa databasen. Information om hur du använder dessa verktyg finns i Alternativ för migrering Azure Database for MySQL – enskild server till flexibel server. Även om självstudien beskriver steg för migrering från Azure MySQL-server i enskilt läge till Azure Database for MySQL flexibel server, kan samma procedur användas för att migrera data från en Azure Database for MySQL flexibel server som inte stöder tillgänglighetszoner till en annan som stöder tillgänglighetszoner.

   • Onlinemigreringsmetoder: Onlinemigreringar minimerar programavbrott. Källservern tillåter uppdateringar och migreringslösningen replikerar de pågående ändringarna mellan käll- och målservern tillsammans med den inledande dumpen och återställningen på målet. Dessa metoder är dock mer komplexa att implementera än en offlinemigrering.

     • Data Migration Service (DMS): Mer information om hur du använder DMS finns i Migrera från MySQL till Azure Database for MySQL online med DMS via Azure-portalen.

       Självstudien beskriver steg för migrering från en lokal MySQL-server till Azure Database for MySQL, men du kan använda samma procedur för att migrera data från en Azure Database for MySQL-server utan stöd för tillgänglighetszoner till en annan med stöd för tillgänglighetszoner.

     • Verktyg med öppen källkod: Du kan använda en kombination av verktyg med öppen källkod, till exempel mydumper/myloader tillsammans med Data-in-replikering.

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, främjas standby-replikan till att bli 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.

Planerad: Forcerad redundans

Azure Database for MySQL flexibel server med tvingad redundansväxling kan du 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.

Tvingad redundans utlöser en redundansväxling som aktiverar väntelägesrepliken för att bli den primära servern med samma databasservernamn och uppdatering av 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 sin drift.

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

Oplanerad: Automatisk övergång

Oplanerad tjänstavbrott kan inträffa på grund av programfel eller infrastrukturfel, till exempel beräknings-, nätverks- eller storage-fel. 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.

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.
• Administrationsslutpunkt: Används internt för tjänstkommunikation med hanteringskomponenter och för att ansluta till backend-lagring.

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

• Övervakaren pingar nodens hanteringsnätverksslutpunkt. Om den här kontrollen misslyckas två gånger i rad utlöser den en automatisk redundansåtgärd. Den här hälsokontrollen hanterar 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 behandlar scenarier som MySQL-daemonkrascher, stopp, eller hänger sig, och backendlagringsproblem eller liknande problem.

Ö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.

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

Begränsningar

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

• Du kan endast konfigurera hög tillgänglighet med zonredundans 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 och restriktioner för replikering med GTID:er.

Kända problem

Azure Database for MySQL Flexible Server använder intern MySQL-replikering i backend. Det finns ett känt problem i MySQL Community Edition 8.0 och senare versioner som kan bryta replikeringen när du utför en DELETE-åtgärd på flera tabeller som förlitar sig på främmande nyckelkonstraint med ON DELETE CASCADE. Det här problemet spåras som MySQL Bug 102586. När du aktiverar hög tillgänglighet på Azure Database for MySQL flexibel server bör du därför undvika att använda överlappande borttagningar med sekundärnycklar, eftersom det här mönstret kan leda till replikeringsfel och kan påverka serverns tillgänglighet.

Hälsokontroll

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

Övervaka hälsa

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 användningen av CPU, minne och lagring för att förhindra flaskhalsar.

Tillförlitlighet och motståndskraft

En omfattande översikt över tillförlitligheten i Azure Database for MySQL, inklusive tillfällig felhantering, motståndskraft i tillgänglighetszoner, haveriberedskap mellan regioner med läsrepliker, säkerhetskopiering och återställning samt tjänstunderhåll finns i Tillförlitlighet i Azure Database for MySQL.

Relaterat innehåll

• Vanliga frågor och svar om hög tillgänglighet (HA) i Azure Database for MySQL
• Översikt över affärskontinuitet med Azure Database for MySQL – flexibel server
• Tillförlitlighet i Azure Database för MySQL