Kommentar
Åtkomst till den här sidan kräver auktorisering. Du kan prova att logga in eller ändra kataloger.
Åtkomst till den här sidan kräver auktorisering. Du kan prova att ändra kataloger.
Affärskontinuitet i Azure Database for PostgreSQL refererar till de mekanismer, principer och procedurer som gör det möjligt för ditt företag att fortsätta sin verksamhet vid störningar, särskilt dess infrastruktur för databehandling. I de flesta fall hanterar Azure Database for PostgreSQL störande händelser som kan inträffa i molnmiljön och håller dina program och affärsprocesser igång. Vissa händelser kan dock inte hanteras automatiskt, till exempel:
- En användare tar bort eller uppdaterar en rad i en tabell av misstag.
- En jordbävning orsakar ett strömavbrott och inaktiverar tillfälligt en tillgänglighetszon eller en region.
- Databaskorrigering krävs för att åtgärda ett fel eller säkerhetsproblem.
Azure Database for PostgreSQL innehåller funktioner som skyddar data och minskar stilleståndstiden för dina verksamhetskritiska databaser under planerade och oplanerade driftstopp. Azure Database for PostgreSQL bygger på Azure-infrastrukturen som erbjuder robust återhämtning och tillgänglighet och har funktioner för affärskontinuitet som ger ett annat 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.
I följande tabell visas de funktioner som Azure Database for PostgreSQL erbjuder.
| Feature | Beskrivning | Överväganden |
|---|---|---|
| Automatiska säkerhetskopieringar | En flexibel Azure Database for PostgreSQL-serverinstans utför automatiskt dagliga säkerhetskopieringar av dina databasfiler och säkerhetskopierar kontinuerligt transaktionsloggar. Du kan behålla säkerhetskopior från 7 dagar upp till 35 dagar. Du kan återställa databasservern till valfri tidpunkt inom kvarhållningsperioden för säkerhetskopior. RTO beror på storleken på de data som ska återställas plus tiden för att utföra loggåterställning. Det kan vara från några minuter upp till 12 timmar. Mer information finns i Begrepp – Säkerhetskopiering och återställning. | Säkerhetskopieringsdata finns kvar i regionen. |
| Zone-redundant hög tillgänglighet | Du kan distribuera en Azure Database for PostgreSQL flexibel serverinstans med konfiguration med zonredundant hög tillgänglighet (HA) där primära servrar och väntelägesservrar distribueras i två olika tillgänglighetszoner i en region. Den här HA-konfigurationen skyddar dina databaser från fel på zonnivå 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äxlas servern automatiskt över till standby-repliken. RTO förväntas i de flesta fall vara mindre än 120 sekunder. RPO förväntas vara noll (ingen dataförlust). Mer information finns i Begrepp – Hög tillgänglighet. | Stöds i generell användning och minnesoptimerade beräkningsnivåer. Endast tillgängligt i regioner där flera zoner är tillgängliga. |
| Hög tillgänglighet i samma zon | Du kan distribuera en Azure Database for PostgreSQL flexibel serverinstans med samma konfiguration med hög tillgänglighet (HA) där primära servrar och väntelägesservrar distribueras i samma tillgänglighetszon i en region. Den här HA-konfigurationen 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äxlas servern automatiskt över till standby-repliken. RTO förväntas i de flesta fall vara mindre än 120 sekunder. RPO förväntas vara noll (ingen dataförlust). Mer information finns i [Begrepp – hög tillgänglighet]/azure/reliability/reliability-postgresql-flexible-server. | Stöds i generell användning och minnesoptimerade beräkningsnivåer. |
| Premiumhanterade diskar | Databasfiler lagras i en mycket hållbar och tillförlitlig lagringstjänst av premiumkvalitet. Den här lagringen ger dataredundans med tre kopior av repliken som lagras i en tillgänglighetszon med funktioner för automatisk dataåterställning. Mer information finns i dokumentationen om hanterade diskar. | Data som lagras i en tillgänglighetszon. |
| Zonredundant säkerhetskopiering | Säkerhetskopieringar av flexibel Azure Database for PostgreSQL-serverinstans lagras automatiskt och säkert i en zonredundant lagring i en region, om regionen stöder tillgänglighetszoner. Vid ett fel på zonnivå i den zon där servern har etablerats kan du fortfarande återställa databasen med hjälp av den senaste återställningspunkten i en annan zon, om servern inte har konfigurerats med zonredundans. Mer information finns i Begrepp – Säkerhetskopiering och återställning. | Gäller endast i regioner där flera zoner är tillgängliga. |
| Georedundant säkerhetskopiering | Säkerhetskopior av Azure Database for PostgreSQL flexibel server kopieras till en fjärrregion. Den här funktionen underlättar katastrofåterställning om den primära serverregionen ligger nere. | Den här funktionen är för närvarande aktiverad i valda regioner. Det kräver en längre RTO och ett högre RPO beroende på datamängdens storlek och mängden återställningsarbete som måste utföras. |
| Läs replik | 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 kan fördröja den primära replikeringen. Mer information finns i Begrepp – Läs repliker. | Stöds i generell användning och minnesoptimerade beräkningsnivåer. |
I följande tabell jämförs RTO och RPO i ett typiskt arbetsbelastningsscenario :
| Förmåga | överbelastningsbar | Produktions-SKU (generell användning/minnesoptimerad) |
|---|---|---|
| Återställning till en specifik tidpunkt från säkerhetskopia | Vilken som helst återställningspunkt inom kvarhållningsperioden RTO – varierar RPO < 5 minuter |
Vilken som helst återställningspunkt inom kvarhållningsperioden RTO – varierar RPO < 5 minuter |
| Geo-återställning från geo-replikerade säkerhetskopior | RTO – varierar RPO < 1 timme |
RTO – varierar RPO < 1 timme |
| Läs repliker | Ej tillämpligt | RTO – minuter* RPO – vanligtvis från 30 sekunder till 5 minuter* |
| Hög tillgänglighet | Ej tillämpligt | RTO < 120 sek RPO = 0 |
Planerade driftstopp
I följande tabell beskrivs några vanliga scenarier för planerat underhåll. Dessa händelser orsakar vanligtvis några minuters stilleståndstid, men de orsakar inte dataförlust.
| Scenario | Bearbeta |
|---|---|
| Beräkningsskalning (användarinitierad) | Under beräkningsskalningsåtgärden tillåter processen att aktiva kontrollpunkter slutförs, tömmer klientanslutningar, avbryter eventuella ej utförda transaktioner, kopplar från lagring och stänger sedan av. Processen etablerar en ny Azure Database for PostgreSQL flexibel serverinstans med samma databasservernamn men med den skalbara beräkningskonfigurationen. Processen kopplar lagringen till den nya servern och startar databasen, som utför återställning vid behov innan klientanslutningar godkänns. |
| Skala upp lagring (användarinitierad) | När du initierar en uppskalning av lagringsåtgärden kan aktiva kontrollpunkter slutföras, klientanslutningar töms och eventuella ogenomförda transaktioner avbryts. Därefter stängs servern av. Processen skalar lagringen till önskad storlek och kopplar den sedan till den nya servern. Processen utför återställning om det behövs innan klientanslutningar accepteras. Observera att nedskalning av lagringsstorleken inte stöds. |
| Ny programvarudistribution (Azure-initierad) | Tjänsten distribuerar automatiskt nya funktioner eller felkorrigeringar som en del av planerat underhåll. Du kan schemalägga när dessa aktiviteter inträffar. För mer information, kontrollera din portal. |
| Delversionsuppgraderingar (Azure-initierade) | Azure Database for PostgreSQL korrigerar automatiskt databasservrar till den delversion som bestäms av Azure. Den här korrigeringen sker som en del av tjänstens planerade underhåll. Processen startar automatiskt om databasservern med den nya delversionen. För mer information, se dokumentationen. Du kan också kontrollera din portal. |
När du konfigurerar Azure Database for PostgreSQL flexibel serverinstans med hög tillgänglighet utför tjänsten först skalning och underhållsåtgärder på väntelägesservern. Mer information finns i [Begrepp – hög tillgänglighet]/azure/reliability/reliability-postgresql-flexible-server.
Hantering av oplanerade driftstopp
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 går ner aktiverar tjänsten standby-repliken och klienterna kan återuppta sina åtgärder. Om du inte konfigurerar servern med hög tillgänglighet (HA) etablerar tjänsten automatiskt en ny databasserver om omstartsförsöket misslyckas. Du kan inte undvika oplanerad stilleståndstid, men Azure Database for PostgreSQL hjälper till att minska stilleståndstiden genom att automatiskt utföra återställningsåtgärder utan att kräva mänsklig inblandning.
Även om teknikteamet kontinuerligt strävar efter att tillhandahålla hög tillgänglighet, finns det tillfällen då Azure Database for PostgreSQL orsakar ett avbrott som orsakar otillgänglighet för databaserna och därmed påverkar ditt program. När tjänstövervakningen identifierar problem som orsakar omfattande anslutningsfel, fel eller prestandaproblem deklarerar tjänsten automatiskt ett avbrott för att hålla dig informerad.
Tjänstavbrott
Om en Azure Database for PostgreSQL flexibel serverinstans slutar fungera kan du hitta mer information om avbrotten på följande platser:
- Azure portalbanderoll: Om din prenumeration påverkas visar Azure portalmeddelanden en avisering om avbrott för ett tjänstproblem.
- Hjälp + support eller support + felsökning: När du skapar ett supportärende från Hjälp + support eller Support + felsökning innehåller portalen information om eventuella problem som påverkar dina resurser. Välj Visa avbrottsinformation för mer information och en sammanfattning av påverkan. Sidan Ny supportbegäran innehåller också en avisering.
- Service Health: Sidan Service Health i Azure-portalen innehåller information om Azure datacenterstatus globalt. Sök efter "tjänsthälsa" i sökfältet i Azure-portalen och visa sedan tjänstproblem i kategorin Aktiva händelser. Du kan också visa hälsotillståndet för enskilda resurser på sidan Resurshälsa för alla resurser under hjälpmenyn . Följande skärmbild av sidan Service Health visar information om ett aktivt tjänstproblem i Sydostasien.
- E-postavisering: Om du konfigurerar aviseringar får du ett e-postmeddelande när ett tjänstavbrott påverkar din prenumeration och resurs. E-postmeddelandena kommer från "azure-noreply@microsoft.com". Brödtexten i e-postmeddelandet börjar med "Aktivitetsloggaviseringen ... utlöstes av ett tjänstproblem för Azure-prenumerationen...". Mer information om aviseringar om tjänsthälsa finns i Ta emot aktivitetsloggaviseringar på Azure tjänstaviseringar med hjälp av Azure portalen.
Viktigt!
Som namnet antyder används tillfälliga tabellområden i PostgreSQL för tillfälliga objekt, samt andra interna databasåtgärder, till exempel sortering. Skapa därför inte användarschemaobjekt i ett tillfälligt tabellområde, eftersom hållbarheten för dessa objekt efter serveromstarter, HA-redundans och liknande händelser inte garanteras.
Oplanerad stilleståndstid: felscenarier och tjänståterställning
I följande tabell beskrivs vanliga oplanerade felscenarier och återställningsprocessen.
| Scenario |
Återställningsprocess [Servrar som konfigurerats utan zonredundant HA] |
Återställningsprocess [Servrar som konfigurerats med zonredundant HA] |
|---|---|---|
| Databasserverfel | Om databasservern slutar att fungera, försöker Azure starta om databasservern. Om det försöket misslyckas startar Azure om databasservern på en annan fysisk nod. Återställningstiden (RTO) beror på olika faktorer, inklusive aktiviteten vid tidpunkten för felet, till exempel en stor transaktion och den återställningsvolym som ska utföras under startprocessen för databasservern. Program som använder PostgreSQL-databaserna måste identifiera och försöka ta bort anslutningar och misslyckade transaktioner igen. |
Om databasserverfelet identifieras redundansväxlar servern till väntelägesservern, vilket minskar stilleståndstiden. Mer information finns på sidan [HA-begrepp]/azure/reliability/reliability-postgresql-flexible-server. RTO förväntas vara 60–120 sekunder, med noll dataförlust. |
| Lagringsfel | Program ser ingen inverkan på några lagringsrelaterade problem, till exempel ett diskfel eller en fysisk blockskada. Eftersom data lagras i tre kopior tillhandahåller den återstående lagringen datakopian. Det skadade datablocket repareras automatiskt och en ny kopia av data skapas automatiskt. | Vid sällsynta och oåterställbara fel, till exempel när hela lagringssystemet är otillgängligt, växlar Azure Database for PostgreSQL Flexible Server-instansen över till standby-repliken för att minska stilleståndstiden. Mer information finns på sidan [HA-begrepp]/azure/reliability/reliability-postgresql-flexible-server. |
| Logiska fel eller användarfel | Om du vill återställa efter användarfel, till exempel tabeller som av misstag har tagits bort eller data som har uppdaterats felaktigt, utför du en återställning till en viss tidpunkt (PITR). När du utför återställningsåtgärden anger du den anpassade återställningspunkten, vilket är tiden precis innan felet inträffade. Om du bara vill återställa en delmängd av databaser eller specifika tabeller i stället för alla databaser i databasservern kan du återställa databasservern i en ny instans, exportera tabellerna via pg_dump och sedan använda pg_restore för att återställa tabellerna till databasen. |
Dessa användarfel skyddas inte av hög tillgänglighet eftersom alla ändringar replikeras till väntelägesrepliken synkront. Du måste utföra en återställning till en viss tidpunkt för att återhämta dig från sådana fel. |
| Fel i tillgänglighetszon | Om du vill återställa efter ett fel på zonnivå utför du återställning till en viss tidpunkt med hjälp av säkerhetskopian och väljer en anpassad återställningspunkt med den senaste tidpunkten för att återställa de senaste uppgifterna. Distribuera en ny Azure Database for PostgreSQL flexibel serverinstans i en annan zon som inte påverkas. Den tid det tar att återställa beror på den tidigare säkerhetskopieringen och volymen av transaktionsloggar som ska återställas. | En Azure Database for PostgreSQL flexibel serverinstans redundansväxlar automatiskt till väntelägesservern inom 60–120 sekunder utan dataförlust. Mer information finns på sidan [HA-begrepp]/azure/reliability/reliability-postgresql-flexible-server. |
| Regionsfel | Om servern har konfigurerats med geo-redundant säkerhetskopiering kan du utföra geo-återställning i den kopplade regionen. Azure skapar och återställer en ny server med de senaste tillgängliga data som kopierades till den här regionen. Du kan också använda läsrepliker över flera regioner. Vid fel i en region kan du utföra en katastrofåterställning genom att uppgradera din läsreplik till en fristående server för läsning och skrivning. RPO förväntas vara upp till fem 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. |
Samma process. |
Konfigurera databasen efter återställning från regionalt fel
- Om du använder geoåterställning eller georeplik för att återhämta dig efter ett avbrott, se till att anslutningen till den nya servern är korrekt konfigurerad så att programmets normala funktion kan återupptas. Följ uppgifterna efter återställningen.
- Om du tidigare har konfigurerat en diagnostikinställning på den ursprungliga servern måste du göra samma sak på målservern om det behövs enligt beskrivningen i Konfigurera och komma åt loggar i Azure Database for PostgreSQL.
- Om du vill konfigurera telemetriaviseringar kontrollerar du att dina befintliga aviseringsregelinställningar har uppdaterats så att de mappas till den nya servern. Mer information om aviseringsregler finns i Använda Azure-portalen för att konfigurera aviseringar för mått för Azure Database for PostgreSQL.
Viktigt!
Du kan återställa borttagna servrar. Om du tar bort servern följer du anvisningarna i Återställa en borttagen server för att återställa. Använd Azure-resurslås för att förhindra oavsiktlig borttagning av servern.