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

  • Artikel

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

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 att återställa från störande händelser som kan orsaka dataförlust eller orsaka att databasen och programmet blir otillgängliga. Lär dig vad du ska göra när ett användarfel eller programfel påverkar dataintegriteten, en Azure-region har ett avbrott eller om ditt program behöver underhåll.

Funktioner för affärskontinuitet

När du utvecklar din affärskontinuitetsplan måste du förstå dina:

  • Mål för återställningstid (RTO): Den maximala godkända tiden innan programmet återställs helt efter en störande händelse.
  • Mål för återställningspunkt (RPO): Den maximala mängden senaste datauppdateringar (tidsintervall) som programmet kan tolerera att förlora när det återställs efter en störande händelse.

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ällning skapar Azure Database for MariaDB en ny server med hjälp av säkerhetskopierade data som replikeras från en annan region. Den totala tiden för att återställa beror på databasens storlek och mängden loggdata 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 databasen asynkront till en replik. Om det uppstår ett primärt databasfel på grund av ett fel på zonnivå eller på regionnivå, ger rededansväxling till repliken en kortare RTO och minskad dataförlust.

Kommentar

Fördröjningen mellan den primära databasen och repliken beror på svarstiden mellan platserna, mängden data som ska överföras och (viktigast av allt) skrivarbetsbelastningen för den primära servern. Tunga skrivarbetsbelastningar kan generera en betydande fördröjning.

På grund av den asynkrona typen av replikering som används för läsrepliker bör du inte överväga att läsa repliker som en lösning med hög tillgänglighet. De högre fördröjningarna kan innebära högre RTO och RPO. Skrivskyddade repliker kan endast fungera som ett alternativ med hög tillgänglighet för arbetsbelastningar där fördröjningen förblir mindre under tider med hög och låg belastning. Annars är läsrepliker avsedda för sann lässkalning för läsintensiva arbetsbelastningar och för haveriberedskapsscenarier.

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

Kapacitet Grundläggande Generell användning Minnesoptimerad
Återställning till tidpunkt från säkerhetskopiering Alla återställningspunkter inom kvarhållningsperioden
RTO varierar
RPO är mindre än 15 minuter		 Alla återställningspunkter inom kvarhållningsperioden
RTO varierar
RPO är mindre än 15 minuter		 Alla återställningspunkter inom kvarhållningsperioden
RTO varierar
RPO är mindre än 15 minuter
Geo-återställning från geo-replikerade säkerhetskopior Stöds inte RTO varierar
RPO är större än 24 timmar		 RTO varierar
RPO är större än 24 timmar
Skrivskyddade repliker RTO är minuter
RPO är mindre än 5 minuter		 RTO är minuter
RPO är mindre än 5 minuter		 RTO är minuter
RPO är mindre än 5 minuter

RTO och RPO kan i vissa fall vara mycket högre , beroende på faktorer som svarstid mellan platser, mängden data som ska överföras och den primära databasens skrivarbetsbelastning.

Återställning av 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 till exempel oavsiktligt ta bort vissa data, oavsiktligt släppa en viktig tabell eller till och med släppa en hel databas. Ett program kan oavsiktligt skriva över bra data med felaktiga data på grund av ett programfel.

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 ligga inom den kvarhållningsperiod 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!

Du kan bara återställa borttagna servrar inom fem dagar efter borttagningen. Efter fem dagar tas säkerhetskopiorna bort. Du kan bara komma åt och återställa databassäkerhetskopian från den Azure-prenumeration som är värd för servern. Om du vill återställa en borttagen server läser du de dokumenterade stegen. Administratörer kan använda hanteringslås för att skydda serverresurser från oavsiktlig borttagning eller oväntade ändringar efter distributionen.

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

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

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

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 där servern finns är offline. Du kan återställa från dessa säkerhetskopior till vilken annan region som helst och sedan starta servern igen. Läs mer om geo-återställning i artikeln om begrepp för säkerhetskopiering och återställning.

Viktigt!

Geo-återställning är endast möjligt om du har etablerat servern med geo-redundant lagring av säkerhetskopior. Om du vill växla från lokalt redundanta till geo-redundanta säkerhetskopior för en befintlig server måste du generera en säkerhetskopia av din befintliga server med mysqldump. Återställ sedan till en nyskapad server som har konfigurerats med geo-redundanta säkerhetskopior.

Läsrepliker mellan regioner

Du kan använda läsrepliker mellan regioner för att förbättra planeringen för affärskontinuitet och haveriberedskap. Läsrepliker uppdateras asynkront via MySQL:s replikeringsteknik för binära loggar. Läs mer om att läsa repliker, tillgängliga regioner och redundansväxla i artikeln om att läsa replikbegrepp.

Vanliga frågor

Var lagrar Azure Database for MariaDB kunddata?

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

Nästa steg