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

  • Artikel

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

Viktigt!

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

Den här översikten beskriver de funktioner som Azure Database for PostgreSQL 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 PostgreSQL tillhandahåller funktioner för verksamhetskontinuitet som innefattar georedundanta säkerhetskopieringar, med möjlighet att initiera geoåterställning och distribuera skrivskyddade repliker 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 :

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

Vi rekommenderar att du använder Azure-resurslås för att förhindra oavsiktlig borttagning av servern. Om du har tagit bort servern av misstag kanske du kan återställa den om borttagningen skedde under de senaste 5 dagarna. Mer information finns i Återställa en borttagen Azure Database for PostgreSQL-server.

Återställa från ett driftavbrott i ett Azure-datacenter

Ä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 ett datacenter 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. Du kan återställa från dessa säkerhetskopior till valfri annan region. Geo-återställningen skapar en ny server med data från säkerhetskopiorna. 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 göra en dump med hjälp av pg_dump av den befintliga servern 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 PostgreSQL:s fysiska replikeringsteknik och kan fördröja den primära replikeringen. 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 PostgreSQL kunddata?

Som standard flyttar eller lagrar inte Azure Database for PostgreSQL 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