Hög tillgänglighet (tillförlitlighet) i Azure Database for PostgreSQL

Den här artikeln beskriver hög tillgänglighet i Azure Database for PostgreSQL, som omfattar tillgänglighetszoner och återställning mellan regioner och affärskontinuitet. En mer detaljerad översikt över tillförlitligheten i Azure finns i Azures tillförlitlighet.

Azure Database for PostgreSQL stöder hög tillgänglighet genom att etablera fysiskt avgränsade primära repliker och väntelägesrepliker, antingen inom samma tillgänglighetszon (zonindelad) eller mellan tillgänglighetszoner (zonredundant). Den här modellen med hög tillgänglighet är utformad för att säkerställa att incheckade data aldrig går förlorade vid fel. I en konfiguration med hög tillgänglighet (HA) skrivs data synkront till både den primära och standby-servern. Modellen är utformad så att databasen inte blir en enda felpunkt i din programvaruarkitektur. Mer information om stöd för hög tillgänglighet och tillgänglighetszon finns i Stöd för tillgänglighetszoner.

Stöd för tillgänglig zon

Tillgänglighetszoner är fysiskt separata grupper av datacenter i varje Azure-region. När en zon misslyckas kan tjänsterna redundansväxla till en av de återstående zonerna.

Azure Database for PostgreSQL stöder både zonredundanta och zonindeliga modeller för konfigurationer med hög tillgänglighet. Båda konfigurationerna med hög tillgänglighet möjliggör automatisk redundans med noll dataförlust under både planerade och oplanerade händelser.

• Zon-redundant. Zonredundant system med hög tillgänglighet distribuerar en standby-replika i en annan zon med automatisk failover-funktion. Zonredundans ger den högsta tillgänglighetsnivån, men du måste konfigurera programredundans mellan zoner. Därför väljer du zonredundans när du vill ha skydd mot fel på tillgänglighetsnivå och när svarstiden mellan tillgänglighetszonerna är acceptabel. Det kan finnas viss fördröjningspåverkan på skrivningar och incheckningar på grund av synkron replikering, men det påverkar inte läsfrågor. Den här effekten är specifik för dina arbetsbelastningar, den SKU-typ du väljer och regionen.

  Du kan välja region och tillgänglighetszoner för både primära servrar och väntelägesservrar. Väntelägesreplikservern etableras i den valda tillgänglighetszonen i samma region med en liknande beräknings-, lagrings- och nätverkskonfiguration som den primära servern. Datafiler och transaktionsloggfiler (loggar för framåtskrivning, även kallade WAL) lagras på lokalt redundant lagring (LRS) i varje tillgänglighetszon och lagrar automatiskt tre datakopior. En zonredundant konfiguration ger fysisk isolering av hela stacken mellan primära servrar och väntelägesservrar.

  

Alternativet zonredundant är endast tillgängligt i regioner som har stöd för tillgänglighetszoner.

Zonredundant stöds inte för:

• Burstbar beräkningsnivå

• Regioner med tillgänglighet i en enda zon

• Zonindelning. Välj en zonindelad distribution när du vill uppnå den högsta tillgänglighetsnivån i en enda tillgänglighetszon, men med den lägsta nätverksfördröjningen. Du kan välja region och tillgänglighetszon för att distribuera både den primära databasservern. En reservreplikserver etableras och hanteras automatiskt i samma tillgänglighetszon – med liknande beräknings-, lagrings- och nätverkskonfiguration – som den primära servern. En zonindelad konfiguration skyddar dina databaser från fel på nodnivå och hjälper även till att minska programavbrott under planerade och oplanerade driftstopp. Data från den primära servern replikeras till väntelägesrepliken i synkront läge. Om det uppstår några störningar på den primära servern växlar servern automatiskt över till standby-repliken.

  

Alternativet zonindelad distribution är tillgängligt i alla Azure-regioner där du kan distribuera flexibel server.

Konfigurera zonindelad återhämtning i portalen

Du kan konfigurera hög tillgänglighet (HA) på två sätt: zonredundant ha, vilket placerar väntelägesservern i en annan tillgänglighetszon för maximal återhämtning eller ha i samma zon, som distribuerar väntelägesservern i samma zon som den primära servern för att minimera svarstiden.

För att förenkla konfigurationen och säkerställa zonindelad återhämtning tillhandahåller portalen ett zonindelad återhämtningsalternativ med två alternativknappar: Aktiverad och Inaktiverad. Om du väljer Aktiverad försöker du skapa väntelägesservern i en annan tillgänglighetszon (zonredundant HA-läge). Om regionen inte stöder zonredundant HA kan du markera kryssrutan för fallback (markerad i följande bild) för att aktivera HA i samma zon i stället.

När du markerar återfallskryssrutan skapar systemet standby-servern i samma zon och utlöser senare ett automatiskt migreringsarbetsflöde under en underhållsperiod för att flytta den till en annan zon så fort kapacitet blir tillgänglig. Om du inte markerar kryssrutan och zonindelningskapaciteten inte är tillgänglig misslyckas HA-aktiveringen. Den här designen framtvingar zonredundant hög tillgänglighet som standard, samtidigt som den ger en kontrollerad fallback för hög tillgänglighet inom samma zon, vilket säkerställer att arbetsbelastningar så småningom uppnår fullständig zonresiliens utan manuella åtgärder.

Funktioner för hög tillgänglighet

• En standby-replik distribueras i samma VM-konfiguration – inklusive virtuella kärnor, lagring och nätverksinställningar – som den primära servern.

• Du kan lägga till stöd för tillgänglighetszoner för en befintlig databasserver.

• Du kan ta bort väntelägesrepliken genom att inaktivera hög tillgänglighet.

• Du kan välja tillgänglighetszoner för dina primära och väntelägesdatabasservrar för zonredundant tillgänglighet.

• Åtgärder som att stoppa, starta och starta om utförs samtidigt på både den primära servern och standby-servern.

• I zonredundanta modeller och zonindelningsmodeller utför den primära databasservern regelbundet automatiska säkerhetskopieringar. Samtidigt arkiverar standby-repliken kontinuerligt transaktionsloggarna i lagringen för säkerhetskopior. Om regionen stöder tillgänglighetszoner lagras säkerhetskopierade data på zonredundant lagring (ZRS). I regioner som inte stöder tillgänglighetszoner lagras säkerhetskopieringsdata på lokal redundant lagring (LRS).

• Klienterna ansluter alltid till det slutgiltiga hostnamnet för den primära databasservern.

• Eventuella ändringar av serverparametrarna tillämpas också på väntelägesrepliken.

• Du kan starta om servern för att hämta eventuella ändringar av statiska serverparametrar.

• Periodiska underhållsaktiviteter, till exempel delversionsuppgraderingar, sker först i vänteläge. För att minska stilleståndstiden höjs vänteläget upp till primärt så att arbetsbelastningarna kan fortsätta medan underhållsaktiviteterna tillämpas på den återstående noden.

Övervaka hög tillgänglighetshälsa

Övervakning av hälsostatus med hög tillgänglighet (HA) i Azure Database for PostgreSQL ger en kontinuerlig översikt över hälsotillståndet och beredskapen för HA-aktiverade instanser. Den här övervakningsfunktionen tillämpar Azures RAMVERK för resurshälsokontroll (RHC) för att identifiera och varna om eventuella problem som kan påverka databasens redundansberedskap eller övergripande tillgänglighet. Genom att utvärdera viktiga mått som anslutningsstatus, redundanstillstånd och datareplikeringshälsa möjliggör övervakning av ha-hälsostatus proaktiv felsökning och hjälper till att upprätthålla databasens drifttid och prestanda.

Använd övervakning av ha-hälsostatus för att:

• Få insikter i realtid om hälsotillståndet för både primära och sekundära repliker, med statusindikatorer som visar potentiella problem, till exempel försämrad prestanda eller nätverksblockering.
• Konfigurera aviseringar för meddelanden i tid om ändringar i HA-status, så att du kan vidta omedelbara åtgärder för att åtgärda potentiella störningar.
• Optimera redundansberedskapen genom att identifiera och åtgärda problem innan de påverkar databasåtgärderna.

En detaljerad guide om hur du konfigurerar och tolkar ha-hälsostatus finns i Övervakning av hälsostatus för hög tillgänglighet (HA) för Azure Database for PostgreSQL.

Begränsningar för hög tillgänglighet

• På grund av synkron replikering till väntelägesservern, särskilt med en zonredundant konfiguration, kan program uppleva förhöjd skriv- och incheckningssvarstid.

• Du kan inte använda väntelägesrepliken för läsförfrågningar.

• Beroende på arbetsbelastningen och aktiviteten på den primära servern kan failover-processen ta längre tid än 120 sekunder eftersom standby-replikan måste återställas innan den kan promoveras.

• Väntelägesservern återställer vanligtvis WAL-filer på 40 MB/s. För större versioner kan den här hastigheten öka till så mycket som 200 MB/s. Om din arbetsbelastning överskrider den här gränsen kan du stöta på längre tid för återställningen att slutföras antingen under redundansväxlingen eller efter att du har upprättat ett nytt vänteläge.

• Om du startar om den primära databasservern startas även standby-repliken om.

• Du kan inte konfigurera ett extra vänteläge.

• Du kan inte schemalägga kundinitierade hanteringsuppgifter under det hanterade underhållsfönstret.

• Planerade händelser som skalningsbaserad databehandling och skalningslagring sker först i vänteläge och sedan på den primära servern. För närvarande redundansväxlar inte servern för dessa planerade åtgärder.

• Om logisk avkodning eller logisk replikering har konfigurerats på en HA-aktiverad flexibel server.

  • I PostgreSQL 16 och tidigare bevaras inte logiska replikeringsplatser på väntelägesservern efter en redundansväxling som standard.
  • För att säkerställa att logisk replikering fortsätter att fungera efter redundansväxlingen måste du aktivera pg_failover_slots tillägget och konfigurera stödinställningar som hot_standby_feedback = on.
  • Från och med PostgreSQL 17 stöds facksynkronisering internt. Om du aktiverar rätt PostgreSQL-konfigurationer (sync_replication_slots, hot_standby_feedback) bevaras logiska replikeringsfack automatiskt efter redundansväxlingen och inget tillägg krävs.
  • Information om konfigurationssteg och krav finns i dokumentationen om PG_Failover_Slots-tillägget .

• Det går inte att konfigurera tillgänglighetszoner mellan privata (virtuella nätverk) och offentlig åtkomst med privata slutpunkter. Du måste konfigurera tillgänglighetszoner i ett virtuellt nätverk (som sträcker sig över tillgänglighetszoner i en region) eller offentlig åtkomst med privata slutpunkter.

• Du kan bara konfigurera tillgänglighetszoner i en enda region. Du kan inte konfigurera tillgänglighetszoner mellan regioner.

SLA

• Zonal-modellen erbjuder en drifttid på ett SLA på cirka 99%.

• Zonredundansmodellen erbjuder en drifttid för ett serviceavtal för cirka 99%.

Skapa en Azure Database for PostgreSQL med tillgänglighetszonen aktiverad

Information om hur du skapar en Azure Database for PostgreSQL för hög tillgänglighet med tillgänglighetszoner finns i Snabbstart: Skapa en Azure Database for PostgreSQL i Azure-portalen.

Omdistribution och migrering av tillgänglighetszoner

Information om hur du aktiverar eller inaktiverar konfiguration med hög tillgänglighet på den flexibla servern i både zonredundanta och zonindelande distributionsmodeller finns i Hantera hög tillgänglighet i Flexibel server.

Komponenter och arbetsflöden med hög tillgänglighet

Slutförande av transaktion

Applikationstransaktionstriggad skrivning omarbetar första loggen till WAL på den primära servern. Den primära servern strömmar loggarna till väntelägesservern med postgres-strömningsprotokollet. När väntelägesserverlagringen bevarar loggarna bekräftar den primära servern att skrivningen har slutförts. Programmet genomför sin transaktion först efter den här bekräftelsen. Den här extra nätverksresan adderar latens till din applikation. Effektprocenten beror på programmet. Den här bekräftelseprocessen väntar inte på att loggarna ska tillämpas på väntelägesservern. Väntelägesservern förblir i återställningsläge tills den har befordrats.

Hälsokontroll

Flexibel serverhälsoövervakning kontrollerar regelbundet hälsotillståndet för både de primära servrarna och väntelägesservrarna. Om hälsoövervakning upptäcker att en primär server inte kan nås efter flera pingar initierar tjänsten en automatisk redundansväxling till väntelägesservern. Algoritmen för hälsoövervakning använder flera datapunkter för att undvika falska positiva situationer.

Failover-lägen

Flexibel server stöder två redundanslägen, planerad redundans och oplanerad redundans. När replikeringen bryts i båda lägena kör väntelägesservern återställning före befordran som primär och öppnas för läsning/skrivning. Med automatiska DNS-poster uppdaterade med den nya primära serverslutpunkten kan program ansluta till servern med hjälp av samma slutpunkt. En ny väntelägesserver upprättas i bakgrunden, så att programmet kan upprätthålla anslutningen.

Status för hög tillgänglighet

Systemet övervakar kontinuerligt hälsotillståndet för primära servrar och väntelägesservrar. Den vidtar lämpliga åtgärder för att åtgärda problem, inklusive att utlösa en redundansväxling till väntelägesservern. I följande tabell visas möjliga statusar för hög tillgänglighet:

Drift i jämviktsläge

PostgreSQL-klientprogram ansluter till den primära servern med hjälp av DB-servernamnet. Den primära servern hanterar programläsningar direkt. Samtidigt får programmet bekräftelse av incheckningar och skrivningar först efter att loggdata sparats på både den primära servern och standby-repliken. På grund av den här extra rundresan kan applikationer förvänta sig förhöjd svarstid för skrivningar och commits. Du kan övervaka hög tillgänglighetsstatusen på portalen.

1. Klienter ansluter till den flexibla servern och utför skrivåtgärder.
2. Ändringar replikeras till väntelägesplatsen.
3. Primären tar emot en bekräftelse.
4. Skrivningar och incheckningar bekräftas.

Återställning vid en given tidpunkt för hög tillgänglighet servrar

För flexibla servrar som konfigurerats med hög tillgänglighet replikerar systemet loggdata i realtid till väntelägesservern. Eventuella användarfel på den primära servern , till exempel en oavsiktlig borttagning av en tabell eller felaktiga datauppdateringar, replikeras till väntelägesrepliken. Därför kan du inte använda vänteläget för att återhämta sig från sådana logiska fel. För att återställa från sådana fel måste du utföra en återställning till en tidigare tidpunkt från säkerhetskopian. Genom att använda en skalbar servers återställningsmöjlighet vid given tidpunkt kan du återställa till tiden innan felet inträffade. En ny databasserver återställs som en flexibel server med en zon med ett nytt servernamn som tillhandahålls av användaren för databaser som har konfigurerats med hög tillgänglighet. Du kan använda den återställde servern för flera användningsfall:

• Använd den återställde servern för produktion och aktivera eventuellt hög tillgänglighet med väntelägesreplik i samma zon eller i en annan zon i samma region.

• Om du vill återställa ett objekt exporterar du det från den återställde databasservern och importerar det till din produktionsdatabasserver.

• Om du vill klona din databasserver för testning och utvecklingsändamål eller för att återställa för andra syften kan du utföra en återställning till en viss tidpunkt.

Information om hur du gör en återställning till tidpunkt för en flexibel server finns i Återställning till tidpunkt för en flexibel server.

Stöd för redundans

Planerad överflyttning

Planerade avbrottshändelser omfattar schemalagda periodiska programuppdateringar i Azure och delversionsuppgraderingar. Du kan också använda en planerad redundansväxling för att returnera den primära servern till en önskad tillgänglighetszon. När du konfigurerar hög tillgänglighet gäller de här åtgärderna först för väntelägesrepliken medan program fortsätter att komma åt den primära servern. När processen uppdaterar väntelägesrepliken töms primära serveranslutningar och utlöser en redundansväxling som aktiverar väntelägesrepliken som den primära servern med samma databasservernamn. Klientprogram återansluter med samma databasservernamn till den nya primära servern och kan återuppta sina åtgärder. Processen etablerar en ny väntelägesserver i samma zon som den gamla primära.

För andra användarinitierade åtgärder, till exempel skalningsberäkning eller skalningslagring, tillämpar processen först ändringar i vänteläge och sedan primärt. För närvarande sker ingen omkoppling av tjänsten till reservsystemet. Medan skalningsåtgärden körs på den primära servern uppstår därför korta avbrott i programmen.

Du kan också använda den här funktionen för redundansväxling till väntelägesservern med kortare stilleståndstid. Din primära server kan till exempel befinna sig i en annan tillgänglighetszon än applikationen efter en oplanerad felövergång. Du vill ta den primära servern tillbaka till den föregående zonen för att samlokalisera med ditt program.

När du kör den här funktionen förbereder processen först väntelägesservern för att se till att den kommer ikapp de senaste transaktionerna, så att programmet kan fortsätta utföra läsningar och skrivningar. Processen främjar standbyläget och bryter anslutningarna till den primära enheten. Programmet kan fortsätta att skriva till den primära medan processen etablerar en ny väntelägesserver i bakgrunden. I följande tabell beskrivs de steg som ingår i planerad redundansväxling:

Programavbrott startar i steg 3 och kan återuppta åtgärden efter steg 5. Resten av stegen sker i bakgrunden utan att påverka skrivoperationer och bekräftelser i applikationen.

En lista över möjliga planerade stilleståndstidshändelser finns i Händelser med planerad stilleståndstid.

Oplanerad omkoppling

Oplanerade driftstopp kan uppstå till följd av oförutsedda störningar, till exempel underliggande maskinvarufel, nätverksproblem och programvarubuggar. Om databasservern som har konfigurerats med hög tillgänglighet oväntat går ner aktiverar processen standby-repliken och klienterna kan återuppta sina åtgärder. Om du inte konfigurerar hög tillgänglighet (HA) och omstartsförsöket misslyckas etablerar processen automatiskt en ny databasserver. Det går inte att undvika en oplanerad stilleståndstid, men flexibel server hjälper till att minska stilleståndstiden genom att automatiskt utföra återställningsåtgärder utan att kräva mänsklig inblandning.

Information om oplanerade redundansväxlingar och driftstopp, inklusive möjliga scenarier, finns i Oplanerad nedtidsreducering.

Redundanstestning (tvingad redundans)

Med en tvingad failover kan du simulera ett oplanerat avbrottsscenario när du kör din produktionsmiljö och observera applikationens driftstopp. Du kan också använda en tvingad redundans när den primära servern inte svarar.

En tvingad redundans leder till att den primära servern stängs av och initierar arbetsflödet för redundansväxling där åtgärden för uppflytt av vänteläge utförs. När reserven har slutfört återställningsprocessen för den senaste angivna datan, befordras den till den primära servern. DNS-poster uppdateras och programmet kan ansluta till den upphöjda primära servern. Ditt program kan fortsätta att skriva till den primära medan en ny väntelägesserver upprättas i bakgrunden, vilket inte påverkar drifttiden.

I följande tabell beskrivs stegen under tvingad redundansväxling:

Programavbrott startar efter steg 1 och fortsätter tills steg 6 har slutförts. De andra stegen körs i bakgrunden utan att påverka programskrivningar och commits.

Överväganden vid framtvingade omkopplingar

• Den totala drifttiden från slutpunkt till slutpunkt kan vara längre än den faktiska stilleståndstid som programmet upplever.

  Viktigt!

  Observera alltid stilleståndstiden ur programperspektiv!

• Utför inte omedelbara och på varandra följande övergångar. Vänta i minst 15–20 minuter mellan failover-processer, så att den nya standby-servern kan upprättas helt.

• Utför en tvingad redundans under en låg aktivitetsperiod för att minska stilleståndstiden.

Metodtips för PostgreSQL-statistik efter redundansväxling

Efter en PostgreSQL-redundansväxling innebär upprätthållandet av optimala databasprestanda att förstå pg_statistic och pg_stat_* tabellernas distinkta roller. Tabellen pg_statistic lagrar optimerarstatistik, vilket är avgörande för frågehanteraren. Den här statistiken omfattar datadistributioner i tabeller och förblir intakta efter ett failover, vilket säkerställer att optimeraren kan fortsätta att optimera frågeexekveringen effektivt baserat på korrekt och historisk information om datadistribution.

Tabellerna pg_stat_* , som däremot registrerar aktivitetsstatistik, till exempel antalet genomsökningar, tupplar som lästs och uppdateringar, återställs vid redundansväxling. Ett exempel på en sådan tabell är pg_stat_user_tables, som spårar aktivitet för användardefinierade tabeller. Den här återställningen återspeglar den nya primärens drifttillstånd korrekt, men innebär också förlust av historiska aktivitetsmått som kan ligga till grund för autovacuumprocessen och andra operativa effektivitetsvinster.

Med den här skillnaden kör du ANALYZE efter en PostgreSQL-redundansväxling. Den här åtgärden uppdaterar tabellerna pg_stat_* , till exempel pg_stat_user_tables, med ny aktivitetsstatistik, vilket hjälper autovacuumprocessen och säkerställer att databasprestandan förblir optimal i sin nya roll. Det här proaktiva steget överbryggar klyftan mellan att bevara viktig optimeringsstatistik och uppdatera aktivitetsmått så att de överensstämmer med databasens aktuella tillstånd.

Avslappningsupplevelse

Zonindelning: Om du vill återställa från ett fel på zonnivå kan du utföra återställning till tidpunkt med hjälp av säkerhetskopian. Du kan välja en anpassad återställningspunkt med den senaste tiden för att återställa de senaste data. En ny flexibel server distribueras i en annan icke-påverkad zon. Den tid det tar att återställa beror på den tidigare säkerhetskopieringen och volymen av transaktionsloggar som ska återställas.

För mer information om återställning till tidpunkt, se "Säkerhetskopiering och återställning i Azure Database for PostgreSQL-Flexible Server".

Zonredundant: Flexibel server redundansväxlar automatiskt till väntelägesservern inom 60–120 sekunder utan dataförlust.

Konfigurationer utan tillgänglighetszoner

Även om det inte rekommenderas kan du konfigurera din flexibla server utan hög tillgänglighet aktiverad. För flexibla servrar som konfigurerats utan hög tillgänglighet tillhandahåller tjänsten lokalt redundant lagring med tre kopior av data, zonredundant säkerhetskopiering (i regioner där den stöds) och inbyggd serveråterhämtning för att automatiskt starta om en kraschad server och flytta servern till en annan fysisk nod. Den här konfigurationen erbjuder ett serviceavtal för drifttid på 99,9%. Under planerade eller oplanerade redundanshändelser, om servern slutar fungera, underhåller tjänsten servrarnas tillgänglighet med hjälp av följande automatiserade procedur:

1. En ny virtuell Linux-beräkningsmaskin tillhandahålls.
2. Lagringen med datafiler mappas till den nya virtuella datorn.
3. PostgreSQL-databasmotorn är online på den nya virtuella datorn.

Följande bild visar övergången mellan virtuell dator och lagringsfel.

Haveriberedskap och affärskontinuitet mellan regioner

Om en regionomfattande katastrof inträffar kan Azure skydda mot regionala eller stora geografiska katastrofer med katastrofåterställning genom att använda en annan region. Mer information om Azures arkitektur för haveriberedskap finns i Arkitektur för haveriberedskap från Azure till Azure.

Flexibel server innehåller funktioner som skyddar data och minskar stilleståndstiden för dina verksamhetskritiska databaser under planerade och oplanerade driftstopp. Den flexibla servern bygger på Azure-infrastrukturen som erbjuder robust återhämtning och tillgänglighet och erbjuder funktioner för affärskontinuitet som ger felskydd, åtgärdar krav på återställningstid och minskar exponeringen för dataförlust. När du utformar dina program bör du överväga avbrottstoleransen – målet för återställningstid (RTO) och exponering för dataförlust – målet för återställningspunkten (RPO). Din affärskritiska databas kräver till exempel striktare drifttid än en testdatabas.

Haveriberedskap i geografi för flera regioner

Geografiskt redundant säkerhetskopiering och återställning

Geo-redundant säkerhetskopiering och återställning ger dig möjlighet att återställa servern i en annan region om en katastrof inträffar. Det ger också minst 99,99999999999999999999 procent (16 nior) hållbarhet för säkerhetskopieringsobjekt under ett år.

Du kan bara konfigurera geo-redundant säkerhetskopiering när du skapar servern. När du konfigurerar servern med geo-redundant säkerhetskopiering kopieras säkerhetskopieringsdata och transaktionsloggar till den kopplade regionen asynkront via lagringsreplikering.

Mer information om geo-redundant säkerhetskopiering och återställning finns i geo-redundant säkerhetskopiering och återställning.

Läs repliker

Du kan distribuera läsrepliker mellan regioner för att skydda dina databaser mot fel på regionsnivå. Läsrepliker uppdateras asynkront med postgreSQL:s fysiska replikeringsteknik, och de kan fördröja den primära. Allmänna användnings- och minnesoptimerade beräkningsnivåer stöder läsrepliker.

Mer information om funktioner och överväganden för läsrepliker finns i Läsrepliker.

Identifiering, avisering och hantering av avbrott

Om du konfigurerar servern med geo-redundant säkerhetskopiering kan du utföra geo-återställning i den kopplade regionen. En ny server etableras och återställs till de senast tillgängliga data som kopierades till den här regionen.

Du kan också använda läsrepliker över flera regioner. Om ett fel i regionen inträffar kan du utföra en haveriåterställningsåtgärd genom att befordra din läsreplik till en fristående skrivbar server. RPO förväntas vara upp till 5 minuter (dataförlust möjlig), förutom vid allvarliga regionala fel då RPO kan motsvara replikeringsfördröjningen vid tidpunkten för felet.

Mer information om oplanerad stilleståndstidsreducering och återställning efter regional katastrof finns i Oplanerad nedtidsreducering.

Relaterat innehåll

• Dokumentation för Azure Database for PostgreSQL
• Tillförlitlighet i Azure