Overzicht van bedrijfscontinuïteit in Azure Database for PostgreSQL flexibele server

Bedrijfscontinuïteit in Azure Database for PostgreSQL verwijst naar de mechanismen, beleidsregels en procedures waarmee uw bedrijf kan blijven werken in het gezicht van onderbrekingen, met name naar de computerinfrastructuur. In de meeste gevallen verwerkt Azure Database for PostgreSQL verstorende gebeurtenissen die zich kunnen voordoen in de cloudomgeving en blijven uw toepassingen en bedrijfsprocessen actief. Sommige gebeurtenissen kunnen echter niet automatisch worden verwerkt, zoals:

  • Een gebruiker verwijdert of werkt per ongeluk een rij in een tabel bij.
  • Een aardbeving veroorzaakt een stroomstoring en schakelt tijdelijk een beschikbaarheidszone of een regio uit.
  • Databasepatching vereist om een bug of beveiligingsprobleem op te lossen.

Azure Database for PostgreSQL biedt functies die gegevens beschermen en downtime beperken voor uw bedrijfskritieke databases tijdens geplande en ongeplande downtimegebeurtenissen. Azure Database for PostgreSQL is gebouwd op basis van de Azure-infrastructuur die robuuste tolerantie en beschikbaarheid biedt, heeft functies voor bedrijfscontinuïteit die een andere foutbeveiliging bieden, hersteltijdvereisten aanpakken en blootstelling aan gegevensverlies verminderen. Houd bij het ontwerpen van uw toepassingen rekening met de downtimetolerantie ( de beoogde hersteltijd (RTO) en blootstelling aan gegevensverlies - de beoogde herstelpunt (RPO). Uw bedrijfskritieke database vereist bijvoorbeeld strengere uptime dan een testdatabase.

In de volgende tabel ziet u de functies die Azure Database for PostgreSQL biedt.

Feature Beschrijving Overwegingen
Automatische back-ups Een exemplaar van een flexibele Azure Database for PostgreSQL-server voert automatisch dagelijkse back-ups van uw databasebestanden uit en maakt continu een back-up van transactielogboeken. U kunt back-ups bewaren van 7 dagen tot 35 dagen. U kunt uw databaseserver herstellen naar een bepaald tijdstip binnen de bewaarperiode voor back-ups. RTO is afhankelijk van de grootte van de gegevens die moeten worden hersteld plus de tijd die nodig is om logboekherstel uit te voeren. Het kan een paar minuten tot 12 uur duren. Zie Concepten - Back-up en herstel voor meer informatie. Back-upgegevens blijven binnen de regio.
Zone-redundante hoge beschikbaarheid U kunt een Azure Database for PostgreSQL exemplaar van een flexibele server implementeren met een zone-redundante hoge beschikbaarheidsconfiguratie waarbij primaire en stand-byservers worden geïmplementeerd in twee verschillende beschikbaarheidszones binnen een regio. Deze ha-configuratie beveiligt uw databases tegen fouten op zoneniveau en helpt ook de downtime van toepassingen te verminderen tijdens geplande en ongeplande downtimegebeurtenissen. Gegevens van de primaire server worden gerepliceerd naar de stand-byreplica in de synchrone modus. In het geval van een verstoring van de primaire server wordt er automatisch een failover uitgevoerd naar de stand-by-replica. In de meeste gevallen is RTO naar verwachting minder dan 120 seconden. De RPO is naar verwachting nul (geen gegevensverlies). Zie Concepten - Hoge beschikbaarheid voor meer informatie. Ondersteund in rekenlagen voor algemeen gebruik en geoptimaliseerd voor geheugen. Alleen beschikbaar in regio's waar meerdere zones beschikbaar zijn.
Dezelfde zone met hoge beschikbaarheid U kunt een Azure Database for PostgreSQL exemplaar van een flexibele server implementeren met dezelfde hoge beschikbaarheidsconfiguratie voor zones waarbij primaire en stand-byservers worden geïmplementeerd in dezelfde beschikbaarheidszone in een regio. Deze ha-configuratie beveiligt uw databases tegen storingen op knooppuntniveau en helpt ook de downtime van toepassingen te verminderen tijdens geplande en ongeplande downtimegebeurtenissen. Gegevens van de primaire server worden gerepliceerd naar de stand-byreplica in de synchrone modus. In het geval van een verstoring van de primaire server wordt er automatisch een failover uitgevoerd naar de stand-by-replica. In de meeste gevallen is RTO naar verwachting minder dan 120 seconden. De RPO is naar verwachting nul (geen gegevensverlies). Zie [Concepten - Hoge beschikbaarheid]/azure/betrouwbaarheid/betrouwbaarheid-postgresql-flexible-server voor meer informatie. Ondersteund in rekenlagen voor algemeen gebruik en geoptimaliseerd voor geheugen.
Premium beheerde schijven Databasebestanden worden opgeslagen in een uiterst duurzame en betrouwbare, eersteklas beheerde opslag. Deze opslag biedt gegevensredundantie met drie kopieën van de replica die zijn opgeslagen in een beschikbaarheidszone met automatische mogelijkheden voor gegevensherstel. Zie de documentatie voor beheerde schijven voor meer informatie. Gegevens die zijn opgeslagen in een beschikbaarheidszone.
Zoneredundante backup Back-ups van flexibele Azure Database voor PostgreSQL-serverinstanties worden automatisch en veilig opgeslagen in een zone-redundante opslag in de regio, indien de regio beschikbaarheidszones ondersteunt. Tijdens een fout op zoneniveau waarin uw server is ingericht en als uw server niet is geconfigureerd met zoneredundantie, kunt u uw database nog steeds herstellen met behulp van het meest recente herstelpunt in een andere zone. Voor meer informatie, zie Concepten - Back-up en herstel. Alleen van toepassing in regio's waar meerdere zones beschikbaar zijn.
Geografisch redundante back-up Back-ups van flexibele servers van Azure Database for PostgreSQL worden gekopieerd naar een externe regio. Deze functie helpt bij herstel na noodgevallen in het geval dat de primaire serverregio uitvalt. Deze functie is momenteel ingeschakeld in geselecteerde regio's. Afhankelijk van de grootte van de gegevens en de hoeveelheid herstel die moet worden uitgevoerd, kan het langer duren om het RTO-niveau te bereiken en kan het RPO-niveau hoger zijn.
Leesreplica U kunt leesreplica's in meerdere regio's implementeren om uw databases te beschermen tegen storingen op regioniveau. Leesreplica’s worden asynchroon bijgewerkt met gebruikmaking van de fysieke replicatietechnologie van PostgreSQL en kunnen achterlopen op de primaire instantie. Zie Concepten - Leesreplica's voor meer informatie. Ondersteund in rekenlagen voor algemeen gebruik en geoptimaliseerd voor geheugen.

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

Vermogen Burstable Productie-SKU (Algemeen Gebruik/Geheugen Geoptimaliseerd)
Herstel naar een bepaald tijdstip vanuit back-up Elk herstelpunt binnen de bewaarperiode
RTO - varieert
RPO < 5 minuten		 Elk herstelpunt binnen de bewaarperiode
RTO - varieert
RPO < 5 minuten
Geo-herstel vanuit geo-gerepliceerde back-ups RTO - varieert
RPO < 1 uur		 RTO - varieert
RPO < 1 uur
Leeskopieën Niet van toepassing RTO - Minuten*
RPO: meestal variërend van 30 seconden tot 5 minuten*
Hoge beschikbaarheid Niet van toepassing RTO < 120 seconden
RPO = 0

Geplande uitvaltijdevenementen

In de volgende tabel worden enkele veelvoorkomende scenario's voor gepland onderhoud beschreven. Deze gebeurtenissen veroorzaken doorgaans een paar minuten downtime, maar ze veroorzaken geen gegevensverlies.

Scenario Verwerken
Rekenkracht schalen (door de gebruiker geïnitieerd) Tijdens de rekenbewerking kan het proces actieve controlepunten voltooien, clientverbindingen leegmaken, eventuele niet-doorgevoerde transacties annuleren, opslag loskoppelen en vervolgens afsluiten. Het proces richt een nieuw Azure Database for PostgreSQL exemplaar van een flexibele server in met dezelfde databaseservernaam, maar met de geschaalde rekenconfiguratie. Het proces koppelt de opslag aan de nieuwe server en start de database, die indien nodig herstel uitvoert voordat clientverbindingen worden geaccepteerd.
Opslag omhoog schalen (door de gebruiker geïnitieerd) Wanneer u een opslagbewerking voor omhoog schalen start, kunnen actieve controlepunten worden voltooid, clientverbindingen leegmaken en eventuele niet-doorgevoerde transacties worden geannuleerd. Daarna wordt de server afgesloten. Het proces schaalt de opslag naar de gewenste grootte en koppelt deze vervolgens aan de nieuwe server. Het proces voert indien nodig herstel uit voordat clientverbindingen worden geaccepteerd. Houd er rekening mee dat omlaag schalen van de opslaggrootte niet wordt ondersteund.
Nieuwe software-implementatie (door Azure geïnitieerd) De service implementeert automatisch nieuwe functies of bugfixes als onderdeel van gepland onderhoud. U kunt plannen wanneer deze activiteiten plaatsvinden. Raadpleeg uw portal voor meer informatie.
Secundaire versie-upgrades (door Azure geïnitieerd) In Azure Database for PostgreSQL worden databaseservers automatisch gepatcht naar de secundaire versie die wordt bepaald door Azure. Deze patch vindt plaats als onderdeel van het geplande onderhoud van de service. Het proces start de databaseserver automatisch opnieuw op met de nieuwe secundaire versie. Zie de documentatie voor meer informatie. U kunt ook uw portal controleren.

Wanneer u het exemplaar van Azure Database for PostgreSQL Flexible Server configureert met hoge beschikbaarheid, voert de service de schaal- en onderhoudsbewerkingen eerst uit op de stand-byserver. Zie [Concepten - Hoge beschikbaarheid]/azure/betrouwbaarheid/betrouwbaarheid-postgresql-flexible-server voor meer informatie.

Niet-geplande uitvaltijd beperken

Niet-geplande downtime kan optreden als gevolg van onvoorziene onderbrekingen, zoals onderliggende hardwarestoringen, netwerkproblemen en softwarefouten. Als de databaseserver die is geconfigureerd met hoge beschikbaarheid onverwacht uitvalt, activeert de service de stand-byreplica en kunnen de clients hun bewerkingen hervatten. Als u de server niet configureert met hoge beschikbaarheid (HA), richt de service automatisch een nieuwe databaseserver in als de poging tot opnieuw opstarten mislukt. Hoewel u niet-geplande downtime niet kunt voorkomen, helpt Azure Database for PostgreSQL de downtime te beperken door automatisch herstelbewerkingen uit te voeren zonder menselijke tussenkomst.

Hoewel het technische team continu streeft naar hoge beschikbaarheid, zijn er momenten waarop Azure Database for PostgreSQL een storing ondervindt die de beschikbaarheid van de databases veroorzaakt en dus van invloed is op uw toepassing. Wanneer de servicebewaking problemen detecteert die veelvoorkomende connectiviteitsfouten, storingen of prestatieproblemen veroorzaken, declareert de service automatisch een storing om u op de hoogte te houden.

Service-onderbreking

Als een exemplaar van een flexibele server van Azure Database for PostgreSQL uitvalt, vindt u meer details over de storing op de volgende locaties:

  • Azure portalbanner: Als uw abonnement wordt beïnvloed, worden in de Azure portalmeldingen een waarschuwing over een storing weergegeven voor een serviceprobleem.

Schermopname van meldingen in Azure Portal.

  • Help + ondersteuning of ondersteuning+ probleemoplossing: wanneer u een ondersteuningsticket maakt vanuit Help + ondersteuning of ondersteuning + probleemoplossing, bevat de portal informatie over eventuele problemen die van invloed zijn op uw resources. Selecteer Onderbrekingsdetails weergeven voor meer informatie en een samenvatting van de impact. De pagina Nieuwe ondersteuningsaanvraag bevat ook een waarschuwing.

Schermopname van Meldingen over Help-ondersteuning in Azure Portal.

  • ServiceStatus: De pagina Servicestatus in de Azure-portal bevat informatie over Azure status van het datacenter wereldwijd. Zoek in de zoekbalk in de Azure-portal naar servicestatus en bekijk vervolgens serviceproblemen in de categorie Actieve gebeurtenissen. U kunt ook de status van afzonderlijke resources bekijken op de pagina Resourcestatus van elke resource in het menu Help . In de volgende schermopname van de pagina Service Health ziet u informatie over een actief serviceprobleem in Zuidoost-Azië.

Schermopname van servicestoring in het Service Health-portaal.

  • E-mailmelding: Als u waarschuwingen instelt, ontvangt u een e-mailmelding wanneer een servicestoring van invloed is op uw abonnement en resource. De e-mailberichten zijn afkomstig van 'azure-noreply@microsoft.com'. De hoofdtekst van het e-mailbericht begint met 'De waarschuwing voor het activiteitenlogboek... is geactiveerd door een serviceprobleem voor het Azure-abonnement...". Zie Waarschuwingen in het activiteitenlogboek ontvangen voor Azure-servicemeldingen via Azure Portal voor meer informatie over waarschuwingen over de servicestatus.

Belangrijk

Zoals de naam al aangeeft, worden tijdelijke tabelruimten in PostgreSQL gebruikt voor tijdelijke objecten, evenals andere interne databasebewerkingen, zoals sorteren. Maak daarom geen gebruikersschemaobjecten in tijdelijke tabelruimte, omdat duurzaamheid van deze objecten na het opnieuw opstarten van de server, hoge beschikbaarheidsfailovers en soortgelijke gebeurtenissen niet wordt gegarandeerd.

Ongeplande uitvaltijd: foutscenario's en hersteldiensten

In de volgende tabel worden veelvoorkomende scenario's met niet-geplande fouten en het herstelproces beschreven.

Scenario Herstelproces
[Servers geconfigureerd zonder zone-redundante hoge beschikbaarheid]		 Herstelproces
[Servers geconfigureerd met zone-redundante HA]
Databaseserverfout Als de databaseserver uitvalt, probeert Azure de databaseserver opnieuw op te starten. Als deze poging mislukt, Azure de databaseserver opnieuw opstarten op een ander fysiek knooppunt.

De hersteltijd (RTO) is afhankelijk van verschillende factoren, waaronder de activiteit op het moment van de fout, zoals een grote transactie, en het volume van herstel dat moet worden uitgevoerd tijdens het opstarten van de databaseserver.

Toepassingen die gebruikmaken van de PostgreSQL-databases moeten verwijderde verbindingen en mislukte transacties detecteren en opnieuw proberen.		 Als de databaseserverfout wordt gedetecteerd, voert de server een failover uit naar de stand-byserver, waardoor de downtime wordt verminderd. Zie de [HA-conceptenpagina]/azure/reliability/reliability-postgresql-flexible-server voor meer informatie. RTO is naar verwachting 60-120 seconden, zonder gegevensverlies.
Opslagfout Toepassingen zien geen gevolgen van opslaggerelateerde problemen, zoals een schijffout of een beschadiging van een fysiek blok. Omdat de gegevens in drievoud worden opgeslagen, bevat de resterende opslag de kopie van de gegevens. Het beschadigde gegevensblok wordt automatisch hersteld en er wordt automatisch een nieuwe kopie van de gegevens gemaakt. Bij zeldzame, niet-herstelbare fouten, bijvoorbeeld wanneer de volledige opslag ontoegankelijk is, schakelt het flexibele serverexemplaar van Azure Database for PostgreSQL over op de stand-byreplica om de uitvaltijd te beperken. Zie de [HA-conceptenpagina]/azure/reliability/reliability-postgresql-flexible-server voor meer informatie.
Logische of gebruikersfouten Als u wilt herstellen van gebruikersfouten, zoals per ongeluk verwijderde tabellen of onjuist bijgewerkte gegevens, voert u een herstel naar een bepaald tijdstip (PITR) uit. Tijdens het uitvoeren van de herstelbewerking geeft u het aangepaste herstelpunt op. Dit is het tijdstip waarop de fout zich voordeed.

Als u alleen een subset van databases of specifieke tabellen wilt herstellen in plaats van alle databases op de databaseserver, kunt u de databaseserver in een nieuw exemplaar herstellen, de tabellen exporteren via pg_dump en vervolgens pg_restore gebruiken om deze tabellen in uw database te herstellen.		 Deze gebruikersfouten worden niet beveiligd door hoge beschikbaarheid, omdat alle wijzigingen synchroon worden gerepliceerd naar de stand-byreplica. U moet een herstel naar een specifiek tijdstip uitvoeren om van dergelijke fouten te herstellen.
Fout in beschikbaarheidszone Als u wilt herstellen na een fout op zoneniveau, voert u herstel naar een bepaald tijdstip uit met behulp van de back-up en kiest u een aangepast herstelpunt met de laatste tijd om de meest recente gegevens te herstellen. Implementeer een nieuwe Azure Database for PostgreSQL flexibele serverinstantie in een andere niet-beïnvloede zone. De tijd die nodig is om te herstellen, is afhankelijk van de vorige back-up en het volume van transactielogboeken dat moet worden hersteld. Een Azure Database for PostgreSQL flexibele serverinstantie voert automatisch een failover uit naar de stand-byserver binnen 60-120 seconden zonder gegevensverlies. Zie de [HA-conceptenpagina]/azure/reliability/reliability-postgresql-flexible-server voor meer informatie.
Regionstoring Als uw server is geconfigureerd met geografisch redundante back-up, kunt u geo-herstel uitvoeren in de gekoppelde regio. Azure richt een nieuwe server in en herstelt deze met de laatst beschikbare gegevens die naar deze regio zijn gekopieerd.

U kunt ook leesreplica's in meerdere regio's gebruiken. Bij uitval van een regio kunt u een disaster recovery uitvoeren door uw leesreplica te promoveren naar een zelfstandige server met lees- en schrijftoegang. RPO duurt naar verwachting maximaal vijf minuten (mogelijk gegevensverlies), behalve in het geval van ernstige regionale storingen wanneer de RPO dicht bij de replicatievertraging kan liggen op het moment van storing.		 Hetzelfde proces.

Uw database configureren na herstel van regio-uitval

Belangrijk

U kunt verwijderde servers herstellen. Als u de server verwijdert, volgt u de richtlijnen in Een verwijderde server herstellen om te herstellen. Gebruik Azure-resourcevergrendeling om te voorkomen dat uw server per ongeluk wordt verwijderd.

Verwante inhoud

  • Last updated on