Tillförlitlighet i Azure Database for PostgreSQL

Azure Database for PostgreSQL är en fullständigt hanterad databastjänst som har utformats för att ge dig detaljerad kontroll och flexibilitet över databashanteringsfunktioner och konfigurationsinställningar. Tjänsten tillhandahåller funktioner för hög tillgänglighet och haveriberedskap baserat på dina krav.

När du använder Azure är tillförlitlighet ett delat ansvar. Microsoft tillhandahåller en rad funktioner för att stödja återhämtning och återställning. Du ansvarar för att förstå hur dessa funktioner fungerar inom alla tjänster som du använder och välja de funktioner du behöver för att uppfylla dina affärsmål och drifttidsmål.

I den här artikeln beskrivs hur du gör Azure Database for PostgreSQL motståndskraftigt mot en mängd olika potentiella avbrott och problem, inklusive tillfälliga fel, avbrott i tillgänglighetszonen, regionstopp och serviceunderhåll. Den beskriver också hur du kan använda säkerhetskopior för att återställa från andra typer av problem och visar viktig information om serviceavtalet för Azure Database for PostgreSQL (SLA).

Rekommendationer för produktionsdistribution

Mer information om hur du distribuerar Azure Database for PostgreSQL för att stödja lösningens tillförlitlighetskrav och hur tillförlitlighet påverkar andra aspekter av arkitekturen finns i Metodtips för arkitektur för Azure Database for PostgreSQL i Azure Well-Architected Framework.

Översikt över tillförlitlighetsarkitektur

I det här avsnittet beskrivs några av de viktiga aspekterna av hur tjänsten fungerar som är mest relevant ur ett tillförlitlighetsperspektiv. I avsnittet beskrivs den logiska arkitekturen, som innehåller några av de resurser och funktioner som du distribuerar och använder. Den diskuterar också den fysiska arkitekturen, som innehåller information om hur tjänsten fungerar under täcket.

Logisk arkitektur

När du arbetar med Azure Database for PostgreSQL distribuerar du en server som representerar de beräknings- och lagringsresurser som krävs för att stödja databasservern. Du distribuerar en eller flera databaser till servern.

Servrar kan distribueras på flera beräkningsnivåer: Burstable, General Purpose och Memory Optimized, som var och en är optimerade för olika typer av arbetsbelastningar. I vissa Azure-regioner kan du distribuera servrar med Konfidentiell databehandling i Azure.

Mer information om den allmänna tjänstarkitekturen och distributionsmodellerna finns i Vad är Azure Database for PostgreSQL?.

Fysisk arkitektur

• Beräknings- och lagringsavgränsning: Azure Database for PostgreSQL använder en beräknings- och lagringsavgränsningsarkitektur för att stödja hög tillgänglighet. Databasmotorn körs på en virtuell Linux-dator, medan datafiler lagras i Azure Storage, vilket upprätthåller tre lokalt redundanta synkrona kopior av databasfilerna för att säkerställa datahållbarhet.

• Hög tillgänglighet: Du kan också aktivera en konfiguration med hög tillgänglighet på servern. När du aktiverar konfigurationen med hög tillgänglighet etablerar och underhåller tjänsten en varm väntelägesserver. Dataändringar på den primära servern replikeras synkront till väntelägesservern för att säkerställa noll dataförlust vid fel på den primära servern.

  Arkitekturen separerar beräkningslagret från lagringslagret så att tjänsten kan hantera olika typer av fel på rätt sätt. För högre återhämtning kan du sprida servrarna mellan tillgänglighetszoner.

  

  En väntelägesserver distribueras i samma VM-konfiguration som den primära servern, inklusive virtuella kärnor, lagring och nätverksinställningar.

  Du kan växla mellan servrar genom att utföra en övergång. Det finns två typer av redundans: framtvingade redundansväxlingar som används när den primära servern misslyckas och planerade redundansväxlingar som används under vissa underhållsåtgärder och i andra scenarier där du behöver minimera programavbrott under en redundansväxling.

  Åtgärder som att stoppa, starta och starta om utförs samtidigt på både den primära servern och standby-servern. 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.

  Mer information finns i Hög tillgänglighet i Azure Database for PostgreSQL.

• Säkerhetskopior: Azure Database for PostgreSQL skapar automatiskt serversäkerhetskopior. Mer information finns i Säkerhetskopiering och återställning.

Motståndskraft mot tillfälliga fel

Tillfälliga fel är kortvariga, intermittenta fel i komponenter. De förekommer ofta i en distribuerad miljö som molnet, och de är en normal del av åtgärderna. Tillfälliga fel korrigerar sig själva efter en kort tidsperiod. Det är viktigt att dina program kan hantera tillfälliga fel, vanligtvis genom att försöka igen.

Alla molnbaserade program bör följa vägledningen för tillfälliga felhantering i Azure när de kommunicerar med molnbaserade API:er, databaser och andra komponenter. Mer information finns i Rekommendationer för hantering av tillfälliga fel.

Dina program måste hantera tillfälliga anslutningsfel som kan inträffa under underhåll, skalningsåtgärder eller nätverksavbrott. Följ dessa rekommendationer:

• När programmet stöter på tillfälliga fel försöker du utföra åtgärden igen med exponentiell backoff. Öka fördröjningen mellan återförsök och begränsa antalet försök. Om åtgärden fortfarande misslyckas efter de maximala återförsöken behandlar du den som ett fel.
• Om möjligt använder du klientbibliotek (kallas även drivrutiner) som automatiskt hanterar återförsök.
• Tillfälliga fel som uppstår under skrivåtgärder kräver mer noggrant övervägande. Överväg att göra dina skrivoperationer idempotenta, så att de kan utföras säkert flera gånger.

Mer information finns i Hantera tillfälliga anslutningsfel i Azure Database for PostgreSQL.

Motståndskraft mot fel i tillgänglighetszonen

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

Du kan välja din typ av stöd för tillgänglighetszoner genom konfigurationen med hög tillgänglighet . När du aktiverar hög tillgänglighet distribueras en väntelägesserver tillsammans med din primära server. Den här modellen med hög tillgänglighet hjälper till att säkerställa att incheckade data aldrig går förlorade vid fel. Oavsett vilken hög tillgänglighetsdistributionsmodell som servern använder, skrivs data synkront till både den primära servern och väntelägesservern. Om det uppstår ett avbrott på den primära servern redundansväxlar servern automatiskt till väntelägesservern.

Datafiler och loggloggar (WAL) lagras på premiumhanterade diskar inom varje tillgänglighetszon, med lokalt redundant lagring (LRS) som automatiskt lagrar tre datakopior inom varje zon.

Azure Database for PostgreSQL stöder två konfigurationstyper för tillgänglighetszoner när du använder hög tillgänglighet:

• Zonredundant hög tillgänglighet: Zonredundans ger den högsta nivån av zonresiliens genom att distribuera en primär server i en tillgänglighetszon och en väntelägesserver i en annan tillgänglighetszon. Väntelägesservern använder liknande beräknings-, lagrings- och nätverkskonfiguration som den primära. En zonredundant konfiguration ger fysisk isolering av hela stacken mellan primära servrar och väntelägesservrar.

  Du kan antingen välja tillgänglighetszonerna för de primära servrarna och väntelägesservrarna eller låta Microsoft välja dem.

  Vi rekommenderar zonredundanta distributioner för produktionsservrar.

  

  Skrivåtgärder kan uppleva en liten ökning av fördröjning vid bekräftelse eftersom tjänsten replikerar data synkront till standby-servern. Effekten varierar beroende på arbetsbelastning, vald SKU och region.

• Zonindelad (samma zon) hög tillgänglighet: De primära servrarna och väntelägesservrarna använder samma tillgänglighetszon. Om ett avbrott uppstår på den primära servern, men zonen fortfarande är felfri, redundansväxlar servern automatiskt till väntelägesservern. En zonindelad distribution ger dig hög tillgänglighet i en enda tillgänglighetszon. Den skyddar dig mot fel på nodnivå och hjälper även till med att minska programavbrott under planerade och oplanerade driftstopp. Det skyddar dock inte mot ett avbrott i den zonen.

  

  Zonindelad (samma zon) hög tillgänglighet är endast tillgänglig i följande situationer:

  • Regionen stöder inte tillgänglighetszoner. Regionen fungerar effektivt som en enda zon, så den enda konfigurationen med hög tillgänglighet som du kan välja är samma zon.
  • Om en region inte har tillräcklig kapacitet för en zonredundant distribution kan tjänsten först placera båda servrarna i samma tillgänglighetszon och automatiskt migrera dem till separata zoner när kapaciteten blir tillgänglig. Det här alternativet är tillgängligt när du använder Azure-portalen eller Azure CLI för att distribuera en server. Mer information finns i Konfigurera affärskritiska alternativ (hög tillgänglighet).

  Eftersom servrarna finns i samma zon kan det minska skrivfördröjningen för program som du distribuerar inom samma zon.

Om du konfigurerar servern utan hög tillgänglighet körs den på en enda server. Om servern eller dess zon slutar fungera är servern inte tillgänglig. Mer information finns i Konfigurationer utan tillgänglighetszoner.

Requirements

• Regionstöd: Azure Database for PostgreSQL:s stöd för konfigurationer av tillgänglighetszoner skiljer sig mellan Azure-regioner. En fullständig lista över regioner och typer av stöd för tillgänglighetszoner och eventuella specifika överväganden för den regionen finns i Azure-regioner.

• Beräkningsnivå: I följande tabell visas stöd för beräkningsnivå för varje typ av stöd för tillgänglighetszoner:

  Prisnivå	Zone-redundant	Zonindelning (samma zon)
  Överbelastningsbar	Stöds ej	Supported
  Generell användning	Supported	Supported
  Minnesoptimerad	Supported	Supported

• Tjänstnivå: Zonredundans kräver nivåerna Allmänt ändamål eller Minnesoptimerad.

  Zonindelade distributioner (samma zon) stöds på alla prisnivåer.

Överväganden

Regionkapacitet: Om en region inte har tillräcklig kapacitet för en zonredundant distribution kan tjänsten först placera båda servrarna i samma tillgänglighetszon och automatiskt migrera dem till separata zoner när kapaciteten blir tillgänglig. Det här alternativet är tillgängligt när du använder Azure-portalen eller Azure CLI för att distribuera en server. Mer information finns i Konfigurera affärskritiska alternativ (hög tillgänglighet).

Kostnad

När du aktiverar hög tillgänglighet skapas och faktureras väntelägesservern med samma hastighet som den primära servern. Konfigurationen av tillgänglighetszonen påverkar inte kostnaden. Det finns inga avgifter för datareplikering inom eller mellan tillgänglighetszoner. Beroende på din lagringsvolym för säkerhetskopiering kan du också debiteras för lagring av säkerhetskopior. Detaljerad prisinformation finns i Prissättning för Azure Database for PostgreSQL.

Konfigurera stöd för tillgänglighetszoner

Om du vill konfigurera stöd för tillgänglighetszoner för en server konfigurerar du inställningarna för hög tillgänglighet.

• Skapa en zonredundant server: Information om hur du skapar en server med hög tillgänglighet och zonredundans aktiverad finns i Snabbstart: Skapa en Azure Database for PostgreSQL i Azure-portalen.

• Ändra konfigurationen av tillgänglighetszonen för befintliga servrar: Du kan ändra konfigurationen av tillgänglighetszonen för befintliga servrar genom att ändra inställningarna för hög tillgänglighet. Detaljerade steg finns i Aktivera hög tillgänglighet för befintliga servrar.

  Du kan inte ändra zonen som används för den primära servern eller väntelägesservern när de har skapats. Du måste återskapa servern.

  Tips/Råd

  Det är en bra idé att vänta tills serveraktiviteten är låg innan du ändrar konfigurationen för hög tillgänglighet.

• Inaktivera hög tillgänglighet: Om du inaktiverar hög tillgänglighet avlägsnas väntelägesservern så att servern inte är motståndskraftig mot avbrott i tillgänglighetszonen. Mer information finns i Inaktivera hög tillgänglighet.

Beteende när alla zoner är felfria

I det här avsnittet beskrivs vad du kan förvänta dig när servrar konfigureras med stöd för hög tillgänglighet och tillgänglighetszon och alla tillgänglighetszoner är i drift.

• Åtgärd mellan zoner: PostgreSQL-klientprogram ansluter till den primära servern med hjälp av databasservernamnet. Azure Database for PostgreSQL använder en aktiv/passiv konfiguration där alla databasanslutningar och frågor hanteras av den primära servern i den primära tillgänglighetszonen. Väntelägesservern hanterar inte klienttrafik under normal drift.

• Datareplikering mellan zoner: Ändringar i data replikeras synkront mellan de primära servrarna och väntelägesservrarna. Transaktioner anses inte vara slutförda förrän både de primära servrarna och väntelägesservrarna bekräftar skrivning.

  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 bekräftelseprocessen väntar inte på att loggarna ska tillämpas på väntelägesservern.

  Effekterna av replikering skiljer sig beroende på konfigurationen av tillgänglighetszonen som servern använder:

  • Zonredundant: Eftersom servrarna finns i separata zoner garanterar den här metoden noll dataförlust vid ett zonfel. Den här situationen kallas också ibland för att uppnå ett återställningspunktmål (RPO) på noll vid zonfel.

    Replikering mellan zoner kan dock medföra en liten mängd extra svarstider. Effekten av svarstiden beror på programmet och för de flesta program är det försumbart.

  • Zonindelad: Eftersom båda servrarna finns i samma zon replikeras ingen trafik mellan zoner.

  Anmärkning

  Systemet replikerar 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ägesservern. Därför kan du inte använda vänteläget för att återhämta sig från den här typen av fel och du måste utföra en återställning till en viss tidpunkt från säkerhetskopian. Mer information finns i Säkerhetskopiering och återställning.

Beteende vid ett zonfel

I det här avsnittet beskrivs vad du kan förvänta dig när servrar konfigureras med hög tillgänglighet och stöd för tillgänglighetszoner, och det inträffar ett avbrott i en tillgänglighetszon.

• Identifiering och svar: Azure kontrollerar regelbundet hälsotillståndet för både primära servrar och väntelägesservrar. 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.

  I händelse av ett zonfel skiljer sig beteendet beroende på vilken konfiguration av tillgänglighetszonen som servern använder:

  • Zone-redundant: Azure Database for PostgreSQL identifierar automatiskt fel i tillgänglighetszoner. Information om hur du visar möjliga statustyper för hög tillgänglighet finns i Statustyper för hög tillgänglighet. När en zon misslyckas initierar Azure en tvingad redundansväxling till väntelägesservern utan att du behöver vidta åtgärder.

  • Zonal: Om tillgänglighetszonen som är värd för en zonindelad server blir otillgänglig är både de primära servrarna och väntelägesservrarna inte tillgängliga. I det här scenariot tillhandahåller tjänsten inte automatisk redundans. Du ansvarar för att identifiera zonavbrottet och utföra återställningsåtgärder, till exempel återställa zonredundanta säkerhetskopieringar till en separat server i en annan tillgänglighetszon eller region.

• Anmälan: Ö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. Övervakningsfunktionen bygger på Azure Resource Health och kan identifiera och avisera om eventuella problem som kan påverka databasens redundansberedskap eller övergripande tillgänglighet. Utvärdera viktiga mått som anslutningsstatus, redundanstillstånd och datareplikeringshälsa för att aktivera proaktiv felsökning och hjälper till att upprätthålla databasens drifttid och prestanda.

  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.

• Aktiva begäranden: När en tillgänglighetszon blir otillgänglig kan eventuella pågående begäranden till servrar i den berörda zonen avslutas. Applikationer måste försöka dessa förfrågningar igen. Om klienterna hanterar tillfälliga fel på rätt sätt genom att försöka igen efter en kort tidsperiod undviker de vanligtvis betydande påverkan.

• Förväntad dataförlust: Mängden dataförlust beror på vilken konfiguration av tillgänglighetszonen som servern använder.

  • Zonredundant: Ingen dataförlust förväntas under zonredundans på grund av synkron replikering mellan de primära servrarna och väntelägesservrarna i olika zoner.

  • Zonal: Data på servrar i den berörda zonen är inte tillgängliga förrän zonen återställs.

• Förväntad stilleståndstid: Mängden stilleståndstid beror på konfigurationen av tillgänglighetszonen som servern använder.

  • Zonredundant: Redundansväxlingen slutförs vanligtvis inom 60–120 sekunder. Om klienterna hanterar tillfälliga fel på rätt sätt genom att försöka igen efter en kort tidsperiod undviker de vanligtvis betydande påverkan.

  • Zonal: Servrar i en påverkad zon är inte tillgängliga förrän tillgänglighetszonen återställs.

• Omfördelning: Hur trafiken omdirigeras beror på vilken konfiguration av tillgänglighetszonen som servern använder.

  • Zone-redundant: Efter failover blir den tidigare standby-servern den nya primära servern och börjar acceptera nya anslutningar. Azure etablerar automatiskt en ny väntelägesserver i den ursprungliga primära zonen när den har återställts. Fullständig information finns i Tvingad redundansväxling.

  • Zonal: När en zon inte är tillgänglig är servern inte tillgänglig. Om du har en separat server som du har skapat i en annan tillgänglighetszon eller region ansvarar du för att omdirigera trafik till den servern.

Zonåterställning

Zonens återställningsbeteende beror på konfigurationen av tillgänglighetszonen som servern använder.

• Zonredundant: När tillgänglighetszonen återställs återskapar Azure Database for PostgreSQL automatiskt väntelägesservern i den återställda zonen och synkroniserar den med den aktuella primära. Den återställda zonen fungerar sedan som väntelägesplats. Tjänsten flyttar inte automatiskt tillbaka den primära rollen till den ursprungliga zonen för att undvika onödiga störningar. Du kan initiera en planerad redundansväxling manuellt om du vill returnera den primära till den ursprungliga zonen.

• Zonal: När zonen är felfri är servrar i zonen tillgängliga igen. Du ansvarar för alla procedurer för zonåterställning och datasynkronisering som dina arbetsbelastningar kräver.

Test för zonfel

Alternativen för testning av zonfel beror på konfigurationen av tillgänglighetszonen som din instans använder.

• Zonredundant: Du kan testa programmets motståndskraft mot felövergång genom att initiera en tvingad felövergång. Med en tvingad redundans kan du simulera ett oplanerat avbrottsscenario när du kör arbetsbelastningen och observera programmets driftstopp. Vi rekommenderar att du kör simuleringar i en icke-produktionsmiljö eller vid en tyst tidpunkt. För mer information, se Initiera en tvungen omkoppling.

• Zonal: Du kan inte simulera ett fullständigt zonstopp, men du kan simulera att servern inte är tillgänglig på ett liknande sätt som vid ett zonstopp. Mer information finns i Stoppa beräkningen av en server.

Motståndskraft mot regionomfattande fel

Azure Database for PostgreSQL stöder läsrepliker mellan regioner, som du kan använda för att underhålla en synkroniserad kopia av databasen i en annan region för snabbare återställning.

Du kan också använda geo-redundanta säkerhetskopior i regioner som stöds för att tillhandahålla återställning mellan regioner. Säkerhetskopieringar innebär dock vanligtvis mer stilleståndstid och dataförlust än replikering. Mer information finns i Säkerhetskopiering och återställning.

Läsrepliker mellan regioner

Du kan distribuera läsrepliker för att skydda dina databaser mot fel på regionnivå. Varje läsreplik är en separat Azure Database for PostgreSQL-server. När du placerar en läsreplik i en andra Azure-region kan databasservern ge motståndskraft mot ett regionomfattande problem. Du kan distribuera upp till fem läsreplikat, som valfritt kan placeras i olika Azure-regioner. PostgreSQL:s uppdateringar av den fysiska replikeringstekniken läser repliker asynkront, och de kan fördröja den primära replikeringen. Skrivskyddade repliker mellan regioner kan valfritt användas för att hantera läsarbetsbelastningar och därmed minska svarstiden för globalt distribuerade program eller avlasta lästrafik från den primära servern. Mer information om funktioner och överväganden för läsrepliker finns i Läsrepliker.

Virtuella slutpunkter tillhandahåller läs-och skrivbara och skrivskyddade slutpunkter och omdirigerar automatiskt trafik när en replik främjas, vilket hjälper till att minimera stilleståndstiden under failover-händelser. Vi rekommenderar starkt att du använder virtuella slutpunkter med läsrepliker mellan regioner för att förbättra programresiliensen. Mer information finns i Virtuella slutpunkter för läsrepliker i Azure Database for PostgreSQL.

Om den primära regionen misslyckas kan du utlösa en befordran så att den sekundära repliken blir den primära. Det finns olika typer av failover som du kan utlösa beroende på hur du använder läsrepliker. När du använder läsrepliker för att öka motståndskraften mot regionfel använder du vanligtvis metoden främja till primär server, som uppdaterar din virtuella slutpunkt. Under ett regionsavbrott måste du utföra en tvingad uppgradering, vilket kan leda till viss dataförlust för oreplikerade data. I planerade situationer där den primära regionen fungerar korrekt, kan du välja att utföra en planerad uppgradering för att undvika dataförlust. Mer information finns i Främja läsrepliker i Azure Database for PostgreSQL.

Anmärkning

Det här avsnittet sammanfattar en del av den viktiga informationen om hur läsrepliker kan stödja motståndskraft mot regionomfattande fel. Du kan också använda läsrepliker för att förbättra prestanda och stödja storskaliga geografiskt distribuerade användarbaser. Mer information finns i Läsa repliker.

Requirements

• Regionstöd: Du kan skapa läsrepliker mellan regioner i valfri region som stöder Azure Database for PostgreSQL. Du är inte begränsad till azure-kopplade regioner.

• Beräkningsnivåer: Beräkningsnivåerna Allmänt ändamål och Minnesoptimerad stöder läsrepliker. Nivån Burstable stöder inte läsrepliker.

Överväganden

• Konfigurationsskillnader: Läsrepliker kanske inte ärver alla konfigurationsinställningar från den primära servern. Planera för att konfigurera nödvändiga inställningar efter failover. Din primära server och repliker bör vara symmetriska, vilket innebär att de måste ha samma nivåer, lagringsstorlekar och värden för vissa inställningar. Vid regionfel kan det symmetriska serverkravet undantas från tvingade uppgraderingar, men det är en bra idé att ha symmetrisk konfiguration där det är möjligt för att undvika oväntade problem. Mer information finns i Konfigurationshantering.

• Övervaka replikeringsfördröjning: Den asynkrona replikeringsprocessen kräver en replikeringsfördröjning, som kan variera beroende på ett antal faktorer. När replikeringsfördröjningen är mycket hög kan servern få problem. Det är viktigt att övervaka replikeringsfördröjningen så att du kan åtgärda problem innan de eskaleras. Mer information finns i Övervaka replikering.

• Hög tillgänglighet: Läsrepliker kan inte ha hög tillgänglighet aktiverat, och när de höjs upp har de inte heller hög tillgänglighet. Du ansvarar för att konfigurera hög tillgänglighet när du har marknadsfört en replik.

Ytterligare överväganden som gäller för befordran finns i Främja läsrepliker i Azure Database for PostgreSQL – Överväganden.

Kostnad

Läsrepliker medför beräknings- och lagringskostnader samt avgifter för dataöverföring mellan regioner för replikering. Detaljerad prisinformation finns i Prissättning för Azure Database for PostgreSQL och prissättning för bandbredd.

Konfigurera stöd för flera regioner

• Skapa en läsreplik: Information om hur du skapar en läsreplik finns i Skapa en läsreplik. Repliker kan konfigureras när den primära servern har skapats, så länge den primära servern körs och är tillgänglig.

  Information om hur du skapar en virtuell slutpunkt finns i Skapa virtuella slutpunkter.

• Ta bort en läsreplik: Information om hur du tar bort en läsreplik finns i Ta bort en läsreplik.

Beteende när alla regioner är felfria

I det här avsnittet beskrivs vad du kan förvänta dig när servern har konfigurerats med en läsreplik i en annan region och en virtuell slutpunkt, och alla regioner fungerar:

• Trafikroutning mellan regioner: I normala åtgärder dirigerar den virtuella slutpunkten trafik för läs-skriv-slutpunkten till den primära servern i den primära regionen. Om du också använder den virtuella slutpunktens skrivskyddade slutpunkt dirigeras trafiken till den replik som du konfigurerar.

• Datareplikering mellan regioner: Läsrepliker mellan regioner använder asynkron replikering för att minimera påverkan på den primära serverns prestanda. Mängden replikeringsfördröjning beror på ett antal faktorer, inklusive skrivbelastningen och svarstiden mellan den primära servern och replikerna. Replikeringsfördröjningen är vanligtvis minst flera minuter, men det kan ta mycket längre tid. Mer information finns i Övervaka replikering.

Beteende under ett regionfel

Det här avsnittet beskriver vad du kan förvänta dig när servern har konfigurerats med en läsreplik i en annan region och en virtuell slutpunkt, och det finns ett avbrott i den primära regionen:

• Identifiering och svar: Du ansvarar för att identifiera ett avbrott i den primära regionen och manuellt främja en läsreplik för att bli den nya primära servern. Under ett regionstopp måste du utföra en framtvingad befordran, vilket resulterar i förlust av otillfördelade data.

  Viktigt!

  Du ansvarar för att utlösa befordran. Azure främjar inte läsreplikor automatiskt, även om det uppstår ett regionavbrott.

  Detaljerade steg för att initiera en uppgradering finns i Växla över läsreplik till primär.

• Anmälan: Microsoft meddelar dig inte automatiskt när en region är nere. Du kan dock använda Azure Service Health för att förstå tjänstens övergripande hälsotillstånd, inklusive eventuella regionfel, och du kan konfigurera Service Health-aviseringar för att meddela dig om problem.

• Aktiva begäranden: Alla aktiva anslutningar till den primära regionen tas bort. Applikationer behöver försöka ansluta till den främjade repliken igen efter att främjandeprocessen är klar.

• Förväntad dataförlust: Under ett regionstopp måste du utföra en framtvingad befordran, vilket resulterar i permanent förlust av opublicerade data.

  Mängden dataförlust beror på replikeringsfördröjningen vid tidpunkten för avbrottet. Replikeringsfördröjningen är vanligtvis minst flera minuter, men det kan ta mycket längre tid. Mer information finns i Övervaka replikering.

• Förväntad stilleståndstid: Framtvingad befordran slutförs vanligtvis inom 1–3 minuter efter att den utlösts. Program kan också behöva återansluta till rätt slutpunkt. Virtuella slutpunkter uppdateras som en del av processen för framtvingad uppgradering. Programmen bör respektera TTL (time-to-live) för slutpunktens DNS-poster för att säkerställa att de snabbt återansluter till rätt replika när promotion är färdig.

• Omdistribution av trafik: Den virtuella slutpunkten för servern omdirigerar automatiskt programtrafik till den nya primära repliken.

  Anmärkning

  När en läsreplik har befordrats till den primära servern har den inte konfiguration med hög tillgänglighet aktiverad. Du måste aktivera konfiguration med hög tillgänglighet manuellt eller lägga till den i dina egna automatiseringsprocesser.

Regionåterställning

När du använder virtuella slutpunkter, när den primära regionen har återställts, konfigureras den gamla primära servern automatiskt som en läsreplik. Du kan utföra en annan åtgärd för att återföra de primära funktionerna till den önskade primära regionen.

Test för regionfel

Testa regelbundet procedurerna för uppgradering av läsreplik för att säkerställa att dina processer är giltiga och att funktionerna uppfyller dina RTO- och RPO-krav.

Du kan när som helst höja upp en läsreplik så att den blir den primära servern, även om alla regioner är felfria. För testning:

• Du kan utföra tvingat promotionstest. Vi rekommenderar att du utför dessa tester i en icke-produktionsmiljö eftersom det kan leda till dataförlust. Testning av tvungen uppgradering hjälper till att simulera det beteende som du ser under ett regionalt avbrott.
• För planerat underhåll eller testscenarier där du vill undvika dataförlust använder du en planerad befordran i stället. Tänk på att planerad befordran följer en annan process än befordran under ett regionstopp.

Stegvisa instruktioner finns i Växla över läsreplik till primär.

Som en del av din strategi för haveriberedskap kör du regelbundet fullständiga återställningstest. Dessa övningar bör omfatta dataverifiering, testning av programfunktioner och dokumenterade återställningsprocedurer.

Säkerhetskopiering och återställning

Azure Database för PostgreSQL utför automatiskt säkerhetskopieringar som erbjuder funktioner för återställning till en specifik tidpunkt och hjälper dig att skydda mot oavsiktlig korruption och borttagning av data. Säkerhetskopior hanteras helt av Microsoft, avbryter inte serverns tillgänglighet och omfattar både fullständiga säkerhetskopior och säkerhetskopior av transaktionsloggar.

• Lagring av säkerhetskopior: Om servern har konfigurerats med zonredundant hög tillgänglighet lagras säkerhetskopior i zonredundant lagring (ZRS). För servrar som konfigurerats utan hög tillgänglighet eller med zonindelad (en zon) hög tillgänglighet lagras säkerhetskopior i lokalt redundant lagring (LRS).

  I Azure-regioner med par kan du konfigurera geo-redundant backup-lagring (GRS) vid skapandet av servern för att replikera säkerhetskopior till den parade Azure-regionen för ytterligare skydd mot regionfel. Säkerhetskopior replikeras asynkront.

  Standardperioden för kvarhållning av säkerhetskopior är 7 dagar, med möjlighet att utöka kvarhållningen upp till 35 dagar. Du kan också använda Azure Backup för långsiktig lagring av manuella säkerhetskopior i upp till 10 år. Alla säkerhetskopior krypteras.

• Återställa: Punkt i tid-återställning gör det möjligt att återställa databasen vid vilken tidpunkt som helst under säkerhetskopieringsperioden. Återställningsprocessen skapar en ny databasserver med ett nytt servernamn som tillhandahålls av användaren, som du sedan kan använda as-is eller kopiera data från.

  När du återställer en geo-redundant säkerhetskopia skapar du en ny server i den kopplade regionen.

  Den här funktionen är användbar för att återställa från oavsiktliga dataändringar, programfel eller testscenarier.

För de flesta lösningar bör du inte enbart förlita dig på säkerhetskopior. Använd i stället de andra funktionerna som beskrivs i den här guiden för att stödja dina återhämtningskrav. Säkerhetskopior skyddar dock mot vissa risker som andra metoder inte gör. Mer information finns i Vad är redundans, replikering och säkerhetskopiering?.

Mer information finns i Säkerhetskopiering och återställning i Azure Database for PostgreSQL.

Motståndskraft mot serviceunderhåll

Azure Database for PostgreSQL hanterar automatiskt kritiska serviceuppgifter, inklusive korrigering av den underliggande maskinvaran, operativsystemet och databasmotorn. Tjänsten innehåller säkerhetsuppdateringar, programuppdateringar och delversionsuppgraderingar som en del av planerat underhåll.

Följ dessa rekommendationer för att säkerställa att servern förblir tillgänglig under underhållsperioder:

• Aktivera hög tillgänglighet: Under underhållet kan servern behöva startas om som en del av uppdateringsprocessen. Om du har hög tillgänglighet aktiverad använder underhållsåtgärder vanligtvis löpande uppdateringar för att minimera stilleståndstiden. Periodiska underhållsaktiviteter såsom delversionsuppgraderingar sker först på standby-replikan. 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. Den här sekvenseringen gäller om servern använder zonredundant eller zonindelad hög tillgänglighet.

  För servrar utan hög tillgänglighet aktiverad kan du förvänta dig kort stilleståndstid under underhållsåtgärder. Med hög tillgänglighet aktiverad slutförs underhållsåtgärder vanligtvis med minimal eller ingen stilleståndstid.

• Konfigurera anpassade underhållsfönster: Du kan konfigurera underhållsschemat så att det är systemhanterat eller definiera ett anpassat underhållsfönster för att minimera påverkan på din verksamhet. Schemalägg underhåll under perioder med låg aktivitet för att minimera påverkan på verksamheten. Mer information finns i Underhållsschema.

• Implementera logik för återförsök: Se till att dina program kan hantera korta anslutningsavbrott som kan inträffa under omstarter av underhåll. Information om hur du gör dina program motståndskraftiga mot dessa typer av problem finns i Vägledning om motståndskraft mot tillfälliga fel .

Serviceavtal

Serviceavtal (SLA) för Azure-tjänster beskriver den förväntade tillgängligheten för varje tjänst och de villkor som din lösning måste uppfylla för att uppnå den tillgänglighetsförväntningen. Mer information finns i Serviceavtal för onlinetjänster.

Azure Database for PostgreSQL tillhandahåller olika tillgänglighets serviceavtal baserat på serverns konfiguration:

• Servrar konfigurerade med hög tillgänglighet med zonredundans.
• Servrar som har konfigurerats med zonindelad (en zon) hög tillgänglighet.
• Servrar som konfigurerats utan hög tillgänglighet.

Relaterat innehåll

• Azure-tillförlitlighet
• Metodtips för arkitektur för Azure Database for PostgreSQL
• Översikt över affärskontinuitet med Azure Database for PostgreSQL
• Geo-katastrofåterställning i Azure Database for PostgreSQL
• Azure Database for PostgreSQL Resiliency Solution Accelerator – Terraform-skript för att implementera många av principerna för återhämtning och återställning som beskrivs i den här artikeln.