Overzicht van bedrijfscontinuïteit met Azure Database for PostgreSQL - Flexible Server

Belangrijk

Azure Database for PostgreSQL - Flexible Server is als preview-versie beschikbaar

Bedrijfscontinuïteit in Azure Database for PostgreSQL - Flexibele server verwijst naar de mechanismen, beleidsregels en procedures waarmee uw bedrijf kan blijven werken bij onderbrekingen, met name voor de computerinfrastructuur. In de meeste gevallen verwerkt flexibele server de verstorende gebeurtenissen die kunnen plaatsvinden in de cloudomgeving en blijven uw toepassingen en bedrijfsprocessen actief. Er zijn echter enkele gebeurtenissen die niet automatisch kunnen worden verwerkt, zoals:

  • De gebruiker verwijdert per ongeluk een rij in een tabel of werkt deze bij.
  • Een aardbeving veroorzaakt een stroomstoring en een datacenter of een beschikbaarheidszone wordt tijdelijk uitgeschakeld.
  • Databasepatching is vereist om een fout of beveiligingsprobleem op te lossen.

Flexibele server biedt functies die gegevens beschermen en downtime voor uw bedrijfskritieke databases beperken in het geval van geplande en ongeplande downtimegebeurtenissen. De flexibele server is gebaseerd op de Azure-infrastructuur die al robuuste tolerantie en beschikbaarheid biedt en beschikt over functies voor bedrijfscontinuïteit die extra foutbeveiliging bieden, vereisten voor hersteltijd aanpakken en blootstelling van gegevensverlies verminderen. Wanneer u uw toepassingen ontwerpt, moet u rekening houden met de downtimetolerantie ( RTO (Recovery Time Objective) en blootstelling van gegevensverlies. Dit is het RPO (Recovery Point Objective). Uw bedrijfskritieke database vereist bijvoorbeeld veel strengere uptimevereisten in vergelijking met een testdatabase.

Belangrijk

Sla (Service Level Agreement) voor uptime %wordt niet aangeboden tijdens de preview.

In de onderstaande tabel ziet u de functies die Flexibele server biedt.

Functie Beschrijving Overwegingen
Automatische back-ups Flexibele servers maken automatisch dagelijkse back-ups van uw databasebestanden en maken continu back-ups van transactielogboeken. Back-ups kunnen worden bewaard van 7 dagen tot 35 dagen. U kunt uw databaseserver op elk moment in de retentieperiode van uw back-up herstellen. RTO is afhankelijk van de grootte van de gegevens die moeten worden hersteld en de tijd die nodig is om logboekherstel uit te voeren. Dit kan enkele minuten tot 12 uur duren. Zie Concepten - Back-up maken en herstellen voor meer informatie. Back-upgegevens blijven binnen de regio.
Zone-redundante hoge beschikbaarheid Flexibele servers kunnen worden geïmplementeerd met een configuratie voor zone-redundante hoge beschikbaarheid (HA), waarbij primaire en stand-byservers worden geïmplementeerd in twee verschillende beschikbaarheidszones binnen een regio. Deze ha-configuratie beschermt uw databases tegen storingen op zoneniveau en helpt ook bij het verminderen van de downtime van toepassingen tijdens geplande en ongeplande downtimegebeurtenissen. Gegevens van de primaire server worden gerepliceerd naar de stand-byreplica in synchrone modus. In het geval van een onderbreking van de primaire server wordt automatisch een failedover uitgevoerd naar de stand-byreplica. RTO is in de meeste gevallen naar verwachting minder dan 120.000. 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.
Premium beheerde schijven Databasebestanden worden opgeslagen in een uiterst duurzame en betrouwbare premium beheerde opslag. Dit biedt gegevens redundantie met drie kopieën van replica's die zijn opgeslagen in een beschikbaarheidszone met automatische mogelijkheden voor gegevensherstel. Zie documentatie voor beheerde schijven voor meer informatie. Gegevens die zijn opgeslagen in een beschikbaarheidszone.
Zone-redundante back-up Back-ups van flexibele servers worden automatisch en veilig opgeslagen in een zone-redundante opslag binnen een regio. Tijdens een storing op zoneniveau waarbij uw server is ingericht en als uw server niet is geconfigureerd met zone-redundantie, kunt u uw database nog steeds herstellen met behulp van het meest recente herstelpunt in een andere zone. Zie Concepten - Back-up maken en herstellen voor meer informatie. Alleen van toepassing in regio's waar meerdere zones beschikbaar zijn.

Geplande downtimegebeurtenissen

Hieronder vindt u enkele scenario's voor gepland onderhoud. Deze gebeurtenissen veroorzaken doorgaans tot enkele minuten downtime en zonder gegevensverlies.

Scenario Proces
Schaalbaarheid berekenen (door de gebruiker geïnitieerd) Tijdens het schalen van de rekenkracht kunnen actieve controlepunten worden voltooid, worden clientverbindingen leeggemaakt, worden niet-doorgestuurde transacties geannuleerd, wordt de opslag losgekoppeld en wordt deze afgesloten. Er wordt een nieuwe flexibele server met dezelfde databaseservernaam ingericht met de schaalbare rekenconfiguratie. De opslag wordt vervolgens gekoppeld aan de nieuwe server en de database wordt gestart. Hiermee wordt indien nodig herstel uitgevoerd voordat clientverbindingen worden geaccepteerd.
Opslag omhoog schalen (door de gebruiker geïnitieerd) Wanneer een opslagbewerking voor omhoog schalen wordt gestart, kunnen actieve controlepunten worden voltooid, worden clientverbindingen leeggemaakt, worden niet-doorgestuurde transacties geannuleerd en wordt deze afgesloten. De opslag wordt geschaald naar de gewenste grootte en vervolgens gekoppeld aan de nieuwe server. Indien nodig wordt een herstel uitgevoerd 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 implementatie van nieuwe functies of oplossingen voor fouten vindt automatisch plaats als onderdeel van het geplande onderhoud van de service en u kunt plannen wanneer deze activiteiten plaatsvinden. Raadpleeg uw portal voor meer informatie.
Kleine versie-upgrades (door Azure geïnitieerd) Azure Database for PostgreSQL worden databaseservers automatisch gepatcht naar de secundaire versie die wordt bepaald door Azure. Dit gebeurt als onderdeel van het geplande onderhoud van de service. De databaseserver wordt automatisch opnieuw opgestart met de nieuwe secundaire versie. Zie de documentatie voor meer informatie. U kunt ook uw portal controleren.

Wanneer de flexibele server is geconfigureerd met zone-redundante hoge beschikbaarheid, voert de flexibele server eerst de schaal- en onderhoudsbewerkingen op de stand-byserver uit. Zie Concepten - Hoge beschikbaarheid voor meer informatie.

Niet-geplande uitvaltijd beperken

Niet-geplande downtime kan optreden als gevolg van onvoorziene onderbrekingen, zoals onderliggende hardwarefouten, netwerkproblemen en softwarefouten. Als de databaseserver die is geconfigureerd met hoge beschikbaarheid onverwacht uitgaat, wordt de stand-byreplica geactiveerd en kunnen de clients hun bewerkingen hervatten. Als deze niet is geconfigureerd met hoge beschikbaarheid (HA), wordt er automatisch een nieuwe databaseserver ingericht als de herstart mislukt. Hoewel niet-geplande downtime niet kan worden vermeden, helpt flexibele servers de downtime te beperken door automatisch herstelbewerkingen uit te voeren zonder menselijke tussenkomst.

Niet-geplande downtime: foutscenario's en serviceherstel

Hieronder vindt u enkele niet-geplande foutscenario's en het herstelproces.

Scenario Herstelproces [niet-HA] Herstelproces [HA]
Databaseserverfout Als de databaseserver niet beschikbaar is, probeert Azure de databaseserver opnieuw op te starten. Als dat mislukt, wordt de databaseserver opnieuw opgestart op een ander fysiek knooppunt.

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

Toepassingen die gebruikmaken van de PostgreSQL-databases moeten zo worden gebouwd dat ze uitgevallen verbindingen en mislukte transacties detecteren en opnieuw proberen.
Als er een fout in de databaseserver wordt gedetecteerd, wordt er een failed over-naar-de-stand-byserver uitgevoerd, waardoor de downtime wordt verminderd. Zie de pagina ha-concepten voor meer informatie. RTO is naar verwachting 60 tot 120, zonder gegevensverlies.
Opslagfout Toepassingen hebben geen gevolgen voor opslagproblemen, zoals een schijffout of beschadiging van een fysiek blok. Omdat de gegevens in drie kopieën worden opgeslagen, wordt de kopie van de gegevens bediend door de nabestaande opslag. Het beschadigde gegevensblok wordt automatisch hersteld en er wordt automatisch een nieuwe kopie van de gegevens gemaakt. Voor zeldzame en niet-herstelbare fouten, zoals dat de volledige opslag niet toegankelijk is, wordt er een failed over-uitval uitgevoerd naar de stand-byreplica om de downtime te verminderen. Zie de pagina ha-concepten voor meer informatie.
Logische/gebruikersfouten Als u wilt herstellen van gebruikersfouten, zoals per ongeluk verwijderde tabellen of onjuist bijgewerkte gegevens, moet u herstel naar een bepaald tijdstip uitvoeren. Tijdens het uitvoeren van de herstelbewerking geeft u het aangepaste herstelpunt op. Dit is het tijdstip voordat 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_dumpen vervolgens pg_restore gebruiken om deze tabellen in uw database te herstellen.
Deze gebruikersfouten worden niet beveiligd met hoge beschikbaarheid omdat alle wijzigingen synchroon naar de stand-byreplica worden gerepliceerd. U moet herstel naar een bepaald tijdstip uitvoeren om dergelijke fouten te herstellen.
Fout in beschikbaarheidszone Als u wilt herstellen van een fout op zoneniveau, kunt u herstel naar een bepaald tijdstip uitvoeren met behulp van de back-up en een aangepast herstelpunt kiezen met de meest recente tijd om de meest recente gegevens te herstellen. Er wordt een nieuwe flexibele server geïmplementeerd in een andere zone zonder gevolgen. De tijd die nodig is om te herstellen, is afhankelijk van de vorige back-up en het volume van transactielogboeken die moeten worden hersteld. Er wordt binnen 60-120 automatisch een failed overgeslagen naar de stand-byserver, zonder gegevensverlies. Zie de pagina met ha-concepten voor meer informatie.
Regiofout Leesreplica's voor verschillende regio's en geo-herstel van back-upfuncties worden nog niet ondersteund in de preview-versie.

Belangrijk

Verwijderde servers kunnen niet worden hersteld. Als u de server verwijdert, worden alle databases die deel uitmaken van de server ook verwijderd en kunnen ze niet worden hersteld. Gebruik Azure-resourcevergrendeling om onbedoeld verwijderen van uw server te voorkomen.

Volgende stappen