Overzicht van bedrijfscontinuïteit met Azure Database for PostgreSQL - één server

  • Artikel

VAN TOEPASSING OP: Azure Database for PostgreSQL - enkele server

Belangrijk

Azure Database for PostgreSQL - Enkele server bevindt zich op het buitengebruikstellingspad. We raden u ten zeerste aan om een upgrade uit te voeren naar Azure Database for PostgreSQL - Flexible Server. Zie Wat gebeurt er met Azure Database for PostgreSQL Enkele server voor meer informatie over migreren naar Azure Database for PostgreSQL - Flexible Server.

In dit overzicht worden de mogelijkheden beschreven die Azure Database for PostgreSQL biedt voor bedrijfscontinuïteit en herstel na noodgevallen. Meer informatie over opties voor het herstellen van verstorende gebeurtenissen die gegevensverlies kunnen veroorzaken of waardoor uw database en toepassing niet meer beschikbaar zijn. Meer informatie over wat u moet doen wanneer een gebruiker of toepassingsfout van invloed is op de gegevensintegriteit, een Azure-regio heeft een storing of dat uw toepassing onderhoud vereist.

Functies die u kunt gebruiken om bedrijfscontinuïteit te bieden

Wanneer u uw bedrijfscontinuïteitsplan ontwikkelt, moet u de maximaal acceptabele tijd begrijpen voordat de toepassing volledig herstelt na de verstorende gebeurtenis. Dit is uw RTO (Recovery Time Objective). U moet ook inzicht krijgen in de maximale hoeveelheid recente gegevensupdates (tijdsinterval) die de toepassing kan tolereren bij het herstellen na de verstorende gebeurtenis. Dit is uw Recovery Point Objective (RPO).

Azure Database for PostgreSQL biedt functies voor bedrijfscontinuïteit die geografisch redundante back-ups bevatten met de mogelijkheid om geo-herstel te initiëren en leesreplica's in een andere regio te implementeren. Elke functie heeft verschillende kenmerken voor de hersteltijd en het potentiële gegevensverlies. Met de functie Geo-herstel wordt een nieuwe server gemaakt met behulp van de back-upgegevens die vanuit een andere regio worden gerepliceerd. De totale tijd die nodig is om te herstellen, is afhankelijk van de grootte van de database en de hoeveelheid logboeken die moeten worden hersteld. De totale tijd voor het inrichten van de server varieert van enkele minuten tot enkele uren. Met leesreplica's worden transactielogboeken van de primaire replica asynchroon naar de replica gestreamd. In het geval van een storing in de primaire database vanwege een fout op zone- of regioniveau, biedt een failover naar de replica een kortere RTO en minder gegevensverlies.

Notitie

De vertraging tussen de primaire en de replica is afhankelijk van de latentie tussen de sites, de hoeveelheid gegevens die moet worden verzonden en het belangrijkste op de schrijfworkload van de primaire server. Zware schrijfworkloads kunnen aanzienlijke vertraging genereren.

Vanwege asynchrone aard van replicatie die wordt gebruikt voor leesreplica's, moeten ze niet worden beschouwd als een hoge beschikbaarheidsoplossing omdat de hogere vertragingen een hogere RTO en RPO kunnen betekenen. Alleen voor workloads waarbij de vertraging kleiner blijft door de piek- en niet-piektijden van de workload, kunnen leesreplica's fungeren als alternatief voor hoge beschikbaarheid. Anders zijn leesreplica's bedoeld voor echte leesschaal voor gebruiksklare zware werkbelastingen en noodherstelscenario's.

In de volgende tabel worden RTO en RPO vergeleken in een typisch workloadscenario :

Mogelijkheid Basic Algemeen doel Geoptimaliseerd voor geheugen
Herstel naar een bepaald tijdstip vanuit back-up Elk herstelpunt binnen de bewaarperiode
RTO - varieert
RPO < 15 min.		 Elk herstelpunt binnen de bewaarperiode
RTO - varieert
RPO < 15 min.		 Elk herstelpunt binnen de bewaarperiode
RTO - varieert
RPO < 15 min.
Geo-herstel vanuit geo-gerepliceerde back-ups Niet ondersteund RTO - varieert
RPO < 1 h		 RTO - varieert
RPO < 1 h
Leesreplica's RTO - Minuten*
RPO < 5 min*		 RTO - Minuten*
RPO < 5 min*		 RTO - Minuten*
RPO < 5 min*

* RTO en RPO kunnen in sommige gevallen veel hoger zijn, afhankelijk van verschillende factoren, waaronder latentie tussen sites, de hoeveelheid gegevens die moet worden verzonden en belangrijke primaire databaseschrijfworkload.

Een server herstellen na een gebruikers- of toepassingsfout

U kunt de back-ups van de service gebruiken om een server te herstellen van verschillende verstorende gebeurtenissen. Een gebruiker kan per ongeluk bepaalde gegevens verwijderen, per ongeluk een belangrijke tabel verwijderen of zelfs een hele database verwijderen. Een toepassing kan per ongeluk goede gegevens overschrijven met slechte gegevens vanwege een toepassingsfout, enzovoort.

U kunt een herstel naar een bepaald tijdstip uitvoeren om een kopie van uw server naar een bekend goed tijdstip te maken. Dit tijdstip moet binnen de retentieperiode voor back-ups liggen die u voor uw server hebt geconfigureerd. Nadat de gegevens zijn hersteld naar de nieuwe server, kunt u de oorspronkelijke server vervangen door de zojuist herstelde server of de benodigde gegevens van de herstelde server naar de oorspronkelijke server kopiëren.

U wordt aangeraden Azure-resourcevergrendeling te gebruiken om onbedoeld verwijderen van uw server te voorkomen. Als u uw server per ongeluk hebt verwijderd, kunt u deze mogelijk herstellen als de verwijdering in de afgelopen 5 dagen is gebeurd. Zie Een verwijderde Azure Database for PostgreSQL-server herstellen voor meer informatie.

Herstellen van een storing in een Azure-datacenter

Hoewel zeldzaam, kan er een storing optreden in een Azure-datacenter. Wanneer er een storing optreedt, veroorzaakt dit een bedrijfsonderbreking die slechts een paar minuten kan duren, maar uren kan duren.

Een optie is om te wachten tot uw server weer online is wanneer de datacentrumstoring voorbij is. Dit werkt voor toepassingen die de server gedurende een bepaalde periode offline kunnen hebben, bijvoorbeeld een ontwikkelomgeving. Wanneer een datacenter een storing heeft, weet u niet hoe lang de storing kan duren. Deze optie werkt dus alleen als u uw server een tijdje niet nodig hebt.

Geo-herstel

Met de functie geo-herstel wordt de server hersteld met geografisch redundante back-ups. De back-ups worden gehost in de gekoppelde regio van uw server. U kunt deze back-ups herstellen naar een andere regio. Met geo-herstel wordt een nieuwe server gemaakt met de gegevens uit de back-ups. Meer informatie over geo-herstel vanuit het artikel over back-up- en herstelconcepten.

Belangrijk

Geo-herstel is alleen mogelijk als u de server hebt ingericht met geografisch redundante back-upopslag. Als u wilt overschakelen van lokaal redundante back-ups naar geografisch redundante back-ups voor een bestaande server, moet u een dump maken met behulp van pg_dump van uw bestaande server en deze herstellen naar een zojuist gemaakte server die is geconfigureerd met geografisch redundante back-ups.

Leesreplica's in meerdere regio's

U kunt leesreplica's in meerdere regio's gebruiken om uw bedrijfscontinuïteit en planning voor herstel na noodgevallen te verbeteren. Leesreplica's worden asynchroon bijgewerkt met behulp van de fysieke replicatietechnologie van PostgreSQL en kunnen de primaire replica vertraging oplopen. Meer informatie over leesreplica's, beschikbare regio's en hoe u een failover uitvoert vanuit het artikel met concepten voor leesreplica's.

Veelgestelde vragen

Waar worden klantgegevens opgeslagen in Azure Database for PostgreSQL?

In Azure Database for PostgreSQL worden standaard geen klantgegevens verplaatst of opgeslagen uit de regio waarin deze is geïmplementeerd. Klanten kunnen er echter ook voor kiezen om geografisch redundante back-ups in te schakelen of leesreplica's tussen regio's te maken voor het opslaan van gegevens in een andere regio.

Volgende stappen