Hög tillgänglighet i Azure Database for MariaDB

Viktigt!

Azure Database for MariaDB är på väg att dras tillbaka. Vi rekommenderar starkt att du migrerar till Azure Database for MySQL. Mer information om hur du migrerar till Azure Database for MySQL finns i Vad händer med Azure Database for MariaDB?.

Azure Database for MariaDB-tjänsten är lämplig för att köra verksamhetskritiska databaser som kräver hög drifttid. Det ger hög tillgänglighet under:

• Planerade händelser, till exempel användarinitierade skalningsberäkningsåtgärder.
• Oplanerade händelser, till exempel underliggande maskinvaru-, programvaru- eller nätverksfel.

Azure Database for MariaDB tillhandahåller ett ekonomiskt säkerhetskopierat serviceavtal för drifttid. Eftersom tjänsten bygger på Azure-arkitektur kan du dra nytta av dess funktioner för hög tillgänglighet, redundans och återhämtning utan att konfigurera några ytterligare komponenter.

Komponenter i Azure Database for MariaDB

Komponent	beskrivning
MariaDB-databasserver	Azure Database for MariaDB tillhandahåller säkerhet, isolering, resursskydd och snabb omstart för databasservrar. De här funktionerna underlättar åtgärder som skalning och databasserveråterställning (i sekunder) efter ett avbrott. Dataändringar på databasservern sker vanligtvis i samband med en databastransaktion. Alla databasändringar registreras synkront i form av loggningsloggar (ib_log filer) i Azure Storage, som är anslutna till databasservern. Under databaskontrollpunktsprocessen töms även datasidor från databasserverminnet till lagringen.
Fjärrlagring	Alla fysiska MariaDB-datafiler och loggfiler lagras i Azure Storage, som lagrar tre kopior av data i en region för att tillhandahålla dataredundans, tillgänglighet och tillförlitlighet. Lagringsskiktet är oberoende av databasservern. Den kan kopplas från en misslyckad databasserver och kopplas tillbaka till en ny databasserver på några sekunder. Azure Storage övervakar kontinuerligt eventuella lagringsfel. Om ett block skadas åtgärdas problemet automatiskt genom att en ny lagringskopia instansieras.
Gateway	Gatewayen fungerar som en databasproxy genom att dirigera alla klientanslutningar till databasservern.

Minskning av planerad stilleståndstid

Arkitekturen för Azure Database for MariaDB ger hög tillgänglighet under planerade driftstopp.

Här följer några scenarier för planerat underhåll:

Scenario	beskrivning
Skala upp eller skala ned	När du utför en skalnings- eller nedskalningsåtgärd etablerar Azure Database for MariaDB en ny databasserver med hjälp av den skalbara beräkningskonfigurationen. På den gamla databasservern tillåter tjänsten att aktiva kontrollpunkter slutförs, tömmer klientanslutningar och avbryter eventuella ogenomförda transaktioner. Tjänsten stänger sedan av den gamla databasservern. Den kopplar från lagringen från den gamla databasservern och kopplar lagringen till den nya databasservern. När klientprogrammet försöker upprätta en ny anslutning igen dirigerar gatewayen anslutningsbegäran till den nya databasservern.
Skala upp lagring	Att skala upp lagringen är en onlineåtgärd och avbryter inte databasservern.
Ny programvarudistribution (Azure)	Distributioner av nya funktioner eller felkorrigeringar sker automatiskt som en del av tjänstens planerade underhåll. Mer information finns i dokumentationen och i portalen.
Delversionsuppgraderingar	Azure Database for MariaDB korrigerar automatiskt databasservrar till den delversion som Azure fastställer. Automatisk korrigering sker som en del av tjänstens planerade underhåll. Det medför en kort stilleståndstid i sekunder och databasservern startas automatiskt om med den nya delversionen. Mer information finns i dokumentationen och i portalen.

Minskning av oplanerad stilleståndstid

Oplanerade driftstopp kan uppstå till följd av oförutsedda fel, inklusive underliggande maskinvarufel, nätverksproblem och programvarubuggar. Om databasservern avslutas oväntat etableras en ny databasserver automatiskt på några sekunder. Fjärrlagringen ansluts automatiskt till den nya databasservern.

MariaDB-motorn utför återställningsåtgärden med hjälp av logg- och databasfiler för skrivning framåt och öppnar databasservern så att klienter kan ansluta. Ogenomförda transaktioner går förlorade och programmet måste försöka igen.

Du kan inte undvika oplanerad stilleståndstid, men Azure Database for MariaDB minimerar det genom att automatiskt utföra återställningsåtgärder på både databasservern och lagringsskikten utan mänsklig inblandning.

Oplanerad stilleståndstid: Felscenarier och tjänståterställning

Här är två felscenarier och hur Azure Database for MariaDB återställs automatiskt:

Scenario	Automatisk återställning
Databasserverfel	Om databasservern är nere på grund av ett underliggande maskinvarufel släpper Azure Database for MariaDB aktiva anslutningar och avbryter alla inflight-transaktioner. Tjänsten distribuerar automatiskt en ny databasserver och kopplar fjärrdatalagringen till den nya databasservern. När databasåterställningen är klar kan klienterna ansluta till den nya databasservern via gatewayen. Program som använder MariaDB-databaserna måste byggas på ett sätt som identifierar och försöker ta bort anslutningar och misslyckade transaktioner igen. När programmet försöker ansluta igen omdirigerar gatewayen transparent anslutningen till den nyligen skapade databasservern.
Lagringsfel	Lagringsrelaterade problem, till exempel ett diskfel eller en fysisk blockskada, påverkar inte program. Eftersom data lagras i tre kopior, hanterar den bevarade lagringen kopian av data. Azure Database for MariaDB korrigerar automatiskt blockfel. Om en kopia av data går förlorad skapar tjänsten automatiskt en ny kopia av data.

Här är felscenarier som kräver att användaråtgärden återställs:

Scenario	Återställningsplan
Regionfel	Fel i en region är en sällsynt händelse. Men om du behöver skydd mot ett regionfel kan du konfigurera en eller flera läsrepliker i andra regioner för haveriberedskap. Mer information finns i den här artikeln om att skapa och hantera läsrepliker. Om ett fel på regionnivå inträffar kan du manuellt höja upp en läsreplik som konfigurerats i en annan region så att den är din produktionsdatabasserver.
Logiskt/användarfel	Återställning från användarfel, till exempel oavsiktligt borttagna tabeller eller felaktigt uppdaterade data, innebär att du utför en återställning till tidpunkt. Den här åtgärden återställer och återställer data tills strax innan felet inträffade. Om du bara vill återställa en delmängd av databaser eller specifika tabeller i stället för alla databaser i databasservern kan du återställa databasservern i en ny instans, exportera tabellerna via mysqldump och sedan återställa tabellerna i databasen.

Sammanfattning

Azure Database for MariaDB har inbyggda funktioner med hög tillgänglighet för att skydda dina databaser mot vanliga avbrott. Den ger snabb omstart av databasservrar, redundant lagring och effektiv routning från gatewayen. För ytterligare dataskydd kan du konfigurera säkerhetskopieringar som geo-replikerade och distribuera läsrepliker i andra regioner.

Nästa steg

• Läs mer om Azure-regioner.
• Lär dig mer om hantering av tillfälliga anslutningsfel.
• Lär dig hur du replikerar dina data med läsrepliker.