Översikt över affärskontinuitet med Azure Database for MariaDB

Den här artikeln beskriver de funktioner som Azure Database for MariaDB tillhandahåller för affärskontinuitet och haveriberedskap. Lär dig mer om alternativ för återställning från störande händelser som kan orsaka dataförlust eller göra att databasen och programmet blir otillgängliga. Lär dig vad du ska göra när ett användar- eller programfel påverkar dataintegriteten, en Azure-region har ett avbrott eller om ditt program kräver underhåll.

Funktioner som du kan använda för att tillhandahålla affärskontinuitet

När du utvecklar din affärskontinuitetsplan måste du förstå den maximala godkända tiden innan programmet återställs helt efter störande händelse – det här är ditt mål för återställningstid (RTO). Du måste också förstå den maximala mängden senaste datauppdateringar (tidsintervall) som programmet kan tolerera att förlora när det återställs efter störande händelse – det här är ditt mål för återställningspunkt (RPO).

Azure Database for MariaDB tillhandahåller funktioner för affärskontinuitet och haveriberedskap som omfattar geo-redundanta säkerhetskopior med möjlighet att initiera geo-återställning och distribuera läsrepliker i en annan region. Varje funktion har olika egenskaper för återställningstid och potentiell dataförlust. Med geo-återställningsfunktionen skapas en ny server med hjälp av säkerhetskopieringsdata som replikeras från en annan region. Den totala tid det tar att återställa beror på databasens storlek och mängden loggar som ska återställas. Den totala tiden för att upprätta servern varierar från några minuter till några timmar. Med läsrepliker strömmas transaktionsloggar från den primära asynkront till repliken. I händelse av ett primärt databasfel på grund av ett fel på zonnivå eller regionnivå ger rededansväxling till repliken en kortare RTO och minskad dataförlust.

Anteckning

Fördröjningen mellan den primära repliken och repliken beror på svarstiden mellan platserna, mängden data som ska överföras och viktigast av allt på den primära serverns skrivarbetsbelastning. Tunga skrivarbetsbelastningar kan generera betydande fördröjning.

På grund av den asynkrona typen av replikering som används för läsrepliker bör de inte betraktas som en lösning med hög tillgänglighet (HA), eftersom de högre fördröjningarna kan innebära högre RTO och RPO. Läsrepliker kan bara fungera som ett alternativ för hög tillgänglighet när fördröjningen är mindre under arbetsbelastningens topp- och icke-topptider. Annars är läsrepliker avsedda för verklig lässkalning för färdiga tunga arbetsbelastningar och för (Haveriberedskap) DR-scenarier.

I följande tabell jämförs RTO och RPO i ett typiskt arbetsbelastningsscenario :

Kapacitet Basic Generell användning Minnesoptimerad
Återställning till tidpunkt från säkerhetskopia Alla återställningspunkter inom kvarhållningsperioden
RTO – varierar
RPO < 15 min
Alla återställningspunkter inom kvarhållningsperioden
RTO – varierar
RPO < 15 min
Alla återställningspunkter inom kvarhållningsperioden
RTO – varierar
RPO < 15 min
Geo-återställning från geo-replikerade säkerhetskopior Stöds inte RTO – varierar
RPO < 1 h
RTO – varierar
RPO < 1 h
Skrivskyddade repliker RTO - Minuter*
RPO < 5 min*
RTO - Minuter*
RPO < 5 min*
RTO - Minuter*
RPO < 5 min*

* RTO och RPO kan i vissa fall vara mycket högre beroende på olika faktorer, inklusive svarstid mellan platser, mängden data som ska överföras och viktig primär databasskrivningsarbetsbelastning.

Återställa en server efter ett användar- eller programfel

Du kan använda tjänstens säkerhetskopior för att återställa en server från olika störande händelser. En användare kan oavsiktligt ta bort vissa data, oavsiktligt släppa en viktig tabell eller till och med släppa en hel databas. Ett program kan av misstag skriva över bra data med felaktiga data på grund av ett programfel och så vidare.

Du kan utföra en återställning till tidpunkt för att skapa en kopia av servern till en känd tidpunkt då den var felfri. Den här tidpunkten måste vara inom kvarhållningsperioden för säkerhetskopior som du har konfigurerat för servern. När data har återställts till den nya servern kan du antingen ersätta den ursprungliga servern med den nyligen återställde servern eller kopiera nödvändiga data från den återställde servern till den ursprungliga servern.

Viktigt

Borttagna servrar kan bara återställas inom fem dagar efter borttagningen, varefter säkerhetskopiorna tas bort. Databassäkerhetskopian kan endast nås och återställas från Azure-prenumerationen som är värd för servern. Om du vill återställa en borttagen server läser du dokumenterade steg. Administratörer kan använda hanteringslås för att skydda serverresurser, efter distribution, från oavsiktlig borttagning eller oväntade ändringar.

Återställa från ett avbrott i ett regionalt Datacenter i Azure

Även om det är ovanligt finns risken för ett avbrott på ett Azure-datacenter. När ett avbrott inträffar orsakar det ett avbrott i verksamheten som kanske bara varar några minuter, men som kan pågå i timmar.

Ett alternativ är att vänta tills servern är online igen när datacentrets avbrott är över. Detta fungerar för program som har råd att ha servern offline under en viss tid, till exempel en utvecklingsmiljö. När datacentret har ett avbrott vet du inte hur länge avbrottet kan pågå, så det här alternativet fungerar bara om du inte behöver servern på ett tag.

Geo-återställning

Geo-återställningsfunktionen återställer servern med hjälp av geo-redundanta säkerhetskopior. Säkerhetskopiorna finns i serverns parkopplade region. Dessa säkerhetskopior är tillgängliga även när den region som servern finns i är offline. Du kan återställa från dessa säkerhetskopior till vilken annan region som helst och få servern online igen. Mer informasjon om geo-återställning från artikeln om säkerhetskopiering och återställning.

Viktigt

Geo-återställning är bara möjligt om du har etablerat servern med geo-redundant säkerhetskopieringslagring. Om du vill växla från lokalt redundanta till geo-redundanta säkerhetskopior för en befintlig server, måste du ta en dump med mysqldump för din befintliga server och återställa den till en nyskapad server som konfigurerats med geo-redundanta säkerhetskopior.

Läsrepliker mellan regioner

Du kan använda skrivskyddade repliker mellan regioner för att förbättra din planering för affärskontinuitet och haveriberedskap. Läsrepliker uppdateras asynkront med mySQL:s replikeringsteknik för binär logg. Mer informasjon om läsrepliker, tillgängliga regioner och hur du redundansväxlar från artikeln om läsrepliker.

Vanliga frågor

Var lagrar Azure Database for MariaDB kunddata?

Som standard flyttar eller lagrar Azure Database for MariaDB inte kunddata från den region som den distribueras i. Kunder kan dock välja att aktivera geo-redundanta säkerhetskopieringar eller skapa skrivskyddade repliker mellan regioner för lagring av data i en annan region.

Nästa steg