Hög tillgänglighet (tillförlitlighet) i Azure Database for PostgreSQL – flexibel server
GÄLLER FÖR: 
Azure Database for PostgreSQL – flexibel server
Den här artikeln beskriver hög tillgänglighet i Azure Database for PostgreSQL – flexibel server, 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 – Flexibel server erbjuder stöd för 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. Modellen är också 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änglighetszon
Azure-tillgänglighetszoner är minst tre fysiskt separata grupper av datacenter i varje Azure-region. Datacenter i varje zon är utrustade med oberoende infrastruktur för ström, kylning och nätverk. Om det uppstår ett fel i den lokala zonen är tillgänglighetszoner utformade så att regionala tjänster, kapacitet och hög tillgänglighet stöds av de återstående två zonerna om den ena zonen påverkas.
Fel kan vara allt från programvaru- och maskinvarufel till händelser som jordbävningar, översvämningar och bränder. Tolerans mot fel uppnås med redundans och logisk isolering av Azure-tjänster. Mer detaljerad information om tillgänglighetszoner i Azure finns i Regioner och tillgänglighetszoner.
Azure-tillgänglighetszoner-aktiverade tjänster är utformade för att ge rätt nivå av tillförlitlighet och flexibilitet. De kan konfigureras på två sätt. De kan vara antingen zonredundanta, med automatisk replikering mellan zoner eller zoninstanser, med instanser fästa på en specifik zon. Du kan också kombinera dessa metoder. Mer information om zon- och zonredundant arkitektur finns i Rekommendationer för användning av tillgänglighetszoner och regioner.
Azure Database for PostgreSQL – Flexibel server 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.
Zonredundant. Zonredundant hög tillgänglighet distribuerar en standby-replik i en annan zon med automatisk redundans. Zonredundans ger den högsta tillgänglighetsnivån, men kräver att du konfigurerar 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.
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 (loggloggar före skrivning, a.k.a WAL) lagras på lokalt redundant lagring (LRS) inom 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.
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. I händelse av störningar på den primära servern redigeras servern automatiskt över till standby-repliken.
Kommentar
Både zon- och zonredundanta distributionsmodeller fungerar arkitektoniskt på samma sätt. Olika diskussioner i följande avsnitt gäller för båda om inget annat anges.
Förutsättningar
Zonredundans:
Alternativet zonredundans är endast tillgängligt i regioner som stöder tillgänglighetszoner.
Zonredundans stöds inte för:
- Azure Database for PostgreSQL – enkel server-SKU.
- Burstbar beräkningsnivå.
- Regioner med en zontillgänglighet.
Zonal:
- Alternativet zonindelad distribution är tillgängligt i alla Azure-regioner där du kan distribuera flexibel server.
Funktioner för hög tillgänglighet
En väntelägesreplik distribueras i samma VM-konfiguration – inklusive virtuella kärnor, lagring, nätverksinställningar – som primär server.
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örs automatiska säkerhetskopieringar regelbundet från den primära databasservern. Samtidigt arkiveras transaktionsloggarna kontinuerligt i lagringen för säkerhetskopiering från standby-repliken. 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).
Klienter ansluter alltid till slutvärden för den primära databasservern.
Eventuella ändringar av serverparametrarna tillämpas också på väntelägesrepliken.
Servern kan startas om så att ändringar av statiska serverparametrar tillämpas.
Periodiska underhållsaktiviteter som delversionsuppgraderingar sker först i vänteläge och 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.
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.
Standby-repliken kan inte användas för läsfrågor.
Beroende på arbetsbelastningen och aktiviteten på den primära servern kan redundansväxlingen ta längre tid än 120 sekunder på grund av återställningen i väntelägesrepliken innan den kan höjas upp.
Väntelägesservern återställer vanligtvis WAL-filer på 40 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.
Att konfigurera för tillgänglighetszoner medför viss svarstid för skrivningar och incheckningar, medan det inte ger någon inverkan på läsning av frågor. Prestandapåverkan varierar beroende på arbetsbelastningen. Som en allmän riktlinje kan påverkan på skrivning och incheckning vara runt 20–30 %.
Om du startar om den primära databasservern startas även standby-repliken om.
Det går inte att konfigurera ett extra vänteläge.
Det går inte att schemalägga konfiguration av kundinitierade hanteringsuppgifter under fönstret hanterat underhåll.
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 med en tillgänglighetskonfigurerad flexibel server kopieras inte de logiska replikeringsplatserna till väntelägesservern i händelse av en redundansväxling till väntelägesservern. För att upprätthålla logiska replikeringsfack och säkerställa datakonsekvens efter en redundansväxling rekommenderar vi att du använder tillägget PG-redundansfack. Mer information om hur du aktiverar det här tillägget finns i dokumentationen.
Det går inte att konfigurera tillgänglighetszoner mellan privat (VNET) 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.
Tillgänglighetszoner konfigureras endast inom en enda region. Tillgänglighetszoner kan inte konfigureras mellan regioner.
SLA
Zonindelad modell erbjuder serviceavtal för drifttid på 99,95 %.
Zonredundansmodellen erbjuder serviceavtal för drifttid på 99,99 %.
Skapa en Azure Database for PostgreSQL – flexibel server med tillgänglighetszon aktiverad
Information om hur du skapar en Azure Database for PostgreSQL – flexibel server för hög tillgänglighet med tillgänglighetszoner finns i Snabbstart: Skapa en Azure Database for PostgreSQL – flexibel server i Azure-portalen.
Omdistribution och migrering av tillgänglighetszon
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
Programtransaktionsutlösta skrivningar och incheckningar loggas först till WAL på den primära servern. Dessa strömmas sedan till väntelägesservern med postgres-strömningsprotokollet. När loggarna har sparats i väntelägesserverlagringen bekräftas den primära servern för slutförande av skrivning. Först då bekräftas programmet att transaktionen har genomförts. Den här ytterligare rundturen ger mer svarstid till ditt program. Procentandelen av påverkan beror på programmet. Den här bekräftelseprocessen väntar inte på att loggarna ska tillämpas på väntelägesservern. Väntelägesservern är permanent i återställningsläge tills den har befordrats.
Hälsokontroll
Flexibel serverhälsoövervakning söker regelbundet efter både primär och väntelägeshälsa. 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 baseras på flera datapunkter för att undvika falska positiva situationer.
Redundanslägen
Flexibel server stöder två redundanslägen, planerad redundans och oplanerad redundans. När replikeringen har brutits i båda lägena kör väntelägesservern återställningen innan den höjs upp 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 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
Hälsotillståndet för primära servrar och väntelägesservrar övervakas kontinuerligt och lämpliga åtgärder vidtas för att åtgärda problem, inklusive att utlösa en redundansväxling till väntelägesservern. Tabellen nedan visar möjliga statusar för hög tillgänglighet:
| Status | Beskrivning |
|---|---|
| Initierar | Under processen att skapa en ny väntelägesserver. |
| Replikera data | När vänteläget har skapats kommer det ikapp den primära. |
| Frisk | Replikeringen är i stabilt tillstånd och felfri. |
| Rederover | Databasservern håller på att växla över till vänteläge. |
| Tar bort vänteläge | Under borttagningen av väntelägesservern. |
| Inte aktiverat | Hög tillgänglighet är inte aktiverat. |
Kommentar
Du kan aktivera hög tillgänglighet när servern skapas eller vid ett senare tillfälle. Om du aktiverar eller inaktiverar hög tillgänglighet under fasen efter skapande rekommenderar vi att du arbetar när den primära serveraktiviteten är låg.
Åtgärder med stabilt tillstånd
PostgreSQL-klientprogram är anslutna till den primära servern med hjälp av DB-servernamnet. Programläsningar hanteras direkt från den primära servern. Samtidigt bekräftas incheckningar och skrivningar till programmet först efter att loggdata sparats på både den primära servern och väntelägesrepliken. På grund av den här extra rundturen kan program förvänta sig förhöjd svarstid för skrivningar och incheckningar. Du kan övervaka hälsotillståndet för den höga tillgängligheten på portalen.
- Klienter ansluter till den flexibla servern och utför skrivåtgärder.
- Ändringar replikeras till väntelägesplatsen.
- Primärt tar emot en bekräftelse.
- Skrivningar/incheckningar bekräftas.
Återställning till tidpunkt för servrar med hög tillgänglighet
För flexibla servrar som konfigurerats med hög tillgänglighet replikeras 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äge för att återställa från sådana logiska fel. Om du vill återställa från sådana fel måste du utföra en återställning till tidpunkt från säkerhetskopian. Med hjälp av en flexibel servers återställningsfunktion för 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 några användningsfall:
Du kan använda den återställde servern för produktion och eventuellt aktivera 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 databasservern för testning och utveckling eller för att återställa för andra ändamål kan du utföra återställningen till 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 redundans
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 de konfigureras med hög tillgänglighet tillämpas de här åtgärderna först på väntelägesrepliken medan programmen fortsätter att komma åt den primära servern. När väntelägesrepliken har uppdaterats töms primära serveranslutningar och en redundans utlöses, vilket aktiverar väntelägesrepliken till att vara den primära med samma databasservernamn. Klientprogram måste återansluta med samma databasservernamn till den nya primära servern och kan återuppta sina åtgärder. En ny väntelägesserver upprättas i samma zon som den gamla primära servern.
För andra användarinitierade åtgärder, till exempel skalningsberäkning eller skalningslagring, tillämpas ändringarna först i vänteläge följt av den primära. För närvarande redundas inte tjänsten över till vänteläge, och när skalningsåtgärden utförs på den primära servern uppstår en kort stilleståndstid för program.
Du kan också använda den här funktionen för redundansväxling till väntelägesservern med kortare stilleståndstid. Din primära kan till exempel finnas i en annan tillgänglighetszon än programmet efter en oplanerad redundansväxling. 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örbereds väntelägesservern först för att se till att den har fastnat i de senaste transaktionerna, så att programmet kan fortsätta utföra läsningar/skrivningar. Vänteläget höjs sedan upp och anslutningarna till den primära är avskurna. Programmet kan fortsätta att skriva till den primära medan en ny väntelägesserver upprättas i bakgrunden. Följande är de steg som ingår i planerad redundansväxling:
| Steg | Beskrivning | Förväntades appens stilleståndstid? |
|---|---|---|
| 1 | Vänta tills väntelägesservern har kommit ikapp den primära servern. | Nej |
| 2 | Det interna övervakningssystemet initierar arbetsflödet för redundans. | Nej |
| 3 | Programskrivningar blockeras när väntelägesservern är nära det primära loggsekvensnumret (LSN). | Ja |
| 4 | Väntelägesservern befordras till en oberoende server. | Ja |
| 5 | DNS-posten uppdateras med den nya väntelägesserverns IP-adress. | Ja |
| 6 | Program för att återansluta och återuppta läsning/skrivning med ny primär. | Nej |
| 7 | En ny väntelägesserver i en annan zon upprättas. | Nej |
| 8 | Väntelägesservern börjar återställa loggar (från Azure Blob) som den missade under etableringen. | Nej |
| 9 | Ett stabilt tillstånd mellan den primära servern och väntelägesservern upprättas. | Nej |
| 10 | Den planerade redundansprocessen är klar. | Nej |
Programavbrott startar i steg 3 och kan återuppta åtgärden efter steg 5. Resten av stegen sker i bakgrunden utan att påverka programskrivningar och incheckningar.
Dricks
Med flexibel server kan du schemalägga Azure-initierade underhållsaktiviteter genom att välja ett 60-minutersfönster på en dag där aktiviteterna i databaserna förväntas vara låga. Azure-underhållsaktiviteter som korrigering eller delversionsuppgraderingar skulle inträffa under det fönstret. Om du inte väljer ett anpassat fönster, väljs ett system allokerat 1-timmarsfönster mellan 23:00 och 07:00 lokal tid för servern. Dessa Azure-initierade underhållsaktiviteter utförs också på standby-repliken för flexibla servrar som har konfigurerats med tillgänglighetszoner.
En lista över möjliga planerade stilleståndstidshändelser finns i Händelser med planerad stilleståndstid.
Oplanerad redundans
Oplanerade driftstopp kan uppstå till följd av oförutsedda störningar, till exempel underliggande maskinvarufel, nätverksproblem och programvarubuggar. Om databasservern som konfigurerats med hög tillgänglighet oväntat minskar aktiveras standby-repliken och klienterna kan återuppta sina åtgärder. Om den inte har konfigurerats med hög tillgänglighet (HA) etableras en ny databasserver automatiskt om omstartsförsöket misslyckas. 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.
Redundanstester (tvingad redundans)
Med en tvingad redundansväxling kan du simulera ett oplanerat avbrottsscenario när du kör produktionsarbetsbelastningen och observera programmets 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 vänteläget har slutfört återställningsprocessen tills de senast allokerade datan har slutförts 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.
Följande är stegen under tvingad redundansväxling:
| Steg | Beskrivning | Förväntades appens stilleståndstid? |
|---|---|---|
| 1 | Den primära servern stoppas strax efter att redundansbegäran har tagits emot. | Ja |
| 2 | Programmet stöter på stilleståndstid när den primära servern är nere. | Ja |
| 3 | Det interna övervakningssystemet identifierar felet och initierar en redundansväxling till väntelägesservern. | Ja |
| 4 | Väntelägesservern går in i återställningsläge innan den höjs upp helt som en oberoende server. | Ja |
| 5 | Redundansväxlingen väntar tills väntelägesåterställningen har slutförts. | Ja |
| 6 | När servern är igång uppdateras DNS-posten med samma värdnamn men med hjälp av väntelägets IP-adress. | Ja |
| 7 | Programmet kan återansluta till den nya primära servern och återuppta åtgärden. | Nej |
| 8 | En väntelägesserver i önskad zon upprättas. | Nej |
| 9 | Väntelägesservern börjar återställa loggar (från Azure Blob) som den missade under etableringen. | Nej |
| 10 | Ett stabilt tillstånd mellan den primära servern och väntelägesservern upprättas. | Nej |
| 11 | Den framtvingade redundansprocessen är klar. | Nej |
Programavbrott förväntas starta efter steg 1 och kvarstår tills steg 6 har slutförts. Resten av stegen sker i bakgrunden utan att påverka programmets skrivningar och incheckningar.
Viktigt!
Redundansväxlingen från slutpunkt till slutpunkt omfattar (a) redundansväxling till väntelägesservern efter det primära felet och (b) upprätta en ny väntelägesserver i stabilt tillstånd. Eftersom programmet medför stilleståndstid tills redundansväxlingen till vänteläget är klar ska du mäta stilleståndstiden från program-/klientperspektivet i stället för den övergripande redundansväxlingen från slutpunkt till slutpunkt.
Överväganden vid framtvingade redundansväxlingar
Den totala drifttiden från slutpunkt till slutpunkt kan ses som längre än den faktiska stilleståndstid som programmet upplever.
Viktigt!
Observera alltid stilleståndstiden ur programperspektiv!
Utför inte omedelbara, back-to-back-redundans. Vänta i minst 15–20 minuter mellan redundansväxlingar, så att den nya väntelägesservern kan upprättas helt.
Vi rekommenderar att du 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 den primära mekanismen för att upprätthålla optimala databasprestanda att förstå de distinkta rollerna för pg_statistic och pg_stat_*- tabellerna. Tabellen pg_statistic innehåller optimerarstatistik, som är avgörande för frågehanteraren. Den här statistiken omfattar datadistributioner i tabeller och förblir intakta efter en redundansväxling, vilket säkerställer att frågehanteraren kan fortsätta att optimera frågekörningen effektivt baserat på korrekt, historisk datadistributionsinformation.
Tabellerna pg_stat_* , som registrerar aktivitetsstatistik, till exempel antalet genomsökningar, tupplar som lästs och uppdateringar, återställs däremot 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 är utformad för att korrekt återspegla den nya primärens drifttillstånd, 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 är bästa praxis efter en PostgreSQL-redundans att köra ANALYZE. 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.
Zon-down-upplevelse
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.
Mer information om återställning till tidpunkt finns i 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 lokal 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. Serviceavtal för drifttid på 99,9 % erbjuds i den här konfigurationen. Under planerade eller oplanerade redundanshändelser, om servern slutar fungera, upprätthåller tjänsten tillgängligheten för servrarna med hjälp av följande automatiserade procedur:
- En ny virtuell Linux-dator för beräkning etableras.
- Lagringen med datafiler mappas till den nya virtuella datorn.
- PostgreSQL-databasmotorn är online på den nya virtuella datorn.
Bilden nedan visar övergången mellan virtuell dator och lagringsfel.
Haveriberedskap och affärskontinuitet mellan regioner
Vid en regionomfattande katastrof kan Azure skydda mot regionala eller stora geografikatastrofer med haveriberedskap genom att använda en annan region. Mer information om Arkitektur för haveriberedskap i Azure finns i Arkitektur för haveriberedskap i 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 stilleståndstidstoleransen – mål 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
Geo-redundant säkerhetskopiering och återställning
Geo-redundant säkerhetskopiering och återställning ger möjlighet att återställa servern i en annan region i händelse av en katastrof. Det ger också minst 99,99999999999999999999 procent (16 nior) hållbarhet för säkerhetskopieringsobjekt under ett år.
Geo-redundant säkerhetskopiering kan endast konfigureras när servern skapas. När servern har konfigurerats 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.
Skrivskyddade repliker
Läsrepliker mellan regioner kan distribueras för att skydda dina databaser mot fel på regionnivå. Läsrepliker uppdateras asynkront med PostgreSQL:s fysiska replikeringsteknik och kan fördröja den primära. Läsrepliker stöds i generell användning och minnesoptimerade beräkningsnivåer.
Mer information om läsfunktioner och överväganden för repliker finns i Läsa repliker.
Identifiering, avisering och hantering av avbrott
Om servern har konfigurerats 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 skrivskyddade repliker mellan regioner. I händelse av regionfel kan du utföra haveriberedskap 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 när RPO kan vara nära replikeringsfördröjningen vid tidpunkten för felet.
Mer information om oplanerad stilleståndstidsreducering och återställning efter regional katastrof finns i Oplanerad nedtidsreducering.