Dela via

Översikt över affärskontinuitet med Azure Database for MySQL – enskild server

  • Artikel

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

Viktigt!

Azure Database for MySQL – enskild server är på väg att dras tillbaka. Vi rekommenderar starkt att du uppgraderar till en flexibel Azure Database for MySQL-server. Mer information om hur du migrerar till en flexibel Azure Database for MySQL-server finns i Vad händer med Azure Database for MySQL – enskild server?

Den här artikeln beskriver de funktioner som Azure Database for MySQL 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ändar- eller programfel påverkar dataintegriteten, en Azure-region har ett avbrott eller om programmet 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 godtagbara tiden innan programmet återställs helt efter den störande händelsen – 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 den störande händelsen – det här är ditt mål för återställningspunkt (RPO).

Azure Database for MySQL – enskild server ger funktioner för affärskontinuitet och haveriberedskap som omfattar geo-redundanta säkerhetskopior med möjlighet att initiera geo-återställning och distribution av 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äkerhetskopierade data 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 på regionnivå, ger rededansväxling till repliken en kortare RTO och minskad dataförlust.

Kommentar

Fördröjningen mellan den primära 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 asynkron replikering som används för skrivskyddade repliker bör de inte betraktas som en ha-lösning (hög tillgänglighet), eftersom de högre fördröjningarna kan innebära högre RTO och RPO. Läsrepliker kan endast fungera som alternativ för arbetsbelastningar där fördröjningen förblir mindre genom arbetsbelastningens topp- och icke-topptider. Annars är läsrepliker avsedda för sann lässkalning för redo tunga arbetsbelastningar och för (Haveriberedskap) DR-scenarier.

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

Förmåga Grundläggande 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 vara mycket högre i vissa fall 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 oavsiktligt 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 Den Azure-prenumeration som är värd för servern. Information om hur du återställer en borttagen server finns i 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 tidsperiod, 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öra servern online igen. Läs mer om geo-återställning från artikeln om 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 dumpa den 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 läsrepliker mellan regioner för att förbättra planeringen för affärskontinuitet och haveriberedskap. Läsrepliker uppdateras asynkront med mySQL:s replikeringsteknik för binära loggar. Läs mer om att läsa repliker, tillgängliga regioner och hur du redundansväxlar från artikeln om att läsa repliker.

Vanliga frågor

Var lagrar Azure Database for MySQL kunddata?

Som standard flyttar eller lagrar inte Azure Database for MySQL kunddata från den region som den distribueras i. Kunder 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