Hoge beschikbaarheid (betrouwbaarheid) in Azure Database for PostgreSQL

In dit artikel wordt hoge beschikbaarheid in Azure Database for PostgreSQL beschreven, waaronder beschikbaarheidszones en herstel in meerdere regio's en bedrijfscontinuïteit. Zie Azure-betrouwbaarheid voor een gedetailleerder overzicht van betrouwbaarheid in Azure.

Azure Database for PostgreSQL biedt ondersteuning voor hoge beschikbaarheid door fysiek gescheiden primaire en stand-byreplica's in te richten, hetzij binnen dezelfde beschikbaarheidszone (zonegebonden) of in meerdere beschikbaarheidszones (zone-redundant). Dit model voor hoge beschikbaarheid is ontworpen om ervoor te zorgen dat vastgelegde gegevens nooit verloren gaan tijdens storingen. Bij het instellen van hoge beschikbaarheid (HA) worden gegevens synchroon doorgevoerd op zowel de primaire als stand-byservers. Het model is zo ontworpen dat de database geen single point of failure wordt in uw softwarearchitectuur. Voor meer informatie over hoge beschikbaarheid en ondersteuning voor beschikbaarheidszones, zie Ondersteuning voor beschikbaarheidszones.

Ondersteuning voor beschikbaarheidszones

Beschikbaarheidszones zijn fysiek afzonderlijke groepen datacenters binnen elke Azure-regio. Wanneer één zone uitvalt, kunnen services een failover uitvoeren naar een van de resterende zones.

Azure Database for PostgreSQL ondersteunt zone-redundante en zonegebonden modellen voor configuraties met hoge beschikbaarheid. Beide configuraties met hoge beschikbaarheid maken automatische failover mogelijk met geen gegevensverlies tijdens geplande en ongeplande gebeurtenissen.

• Zone-redundant. Zoneredundante hoge beschikbaarheid zorgt voor de inzet van een stand-byreplica in een andere zone met automatische failovercapaciteit. Zoneredundantie biedt het hoogste beschikbaarheidsniveau, maar u moet toepassingsredundantie tussen zones configureren. Kies daarom zoneredundantie wanneer u bescherming wilt tegen storingen op beschikbaarheidszoneniveau en wanneer latentie in de beschikbaarheidszones acceptabel is. Hoewel er enige latentie van invloed kan zijn op schrijf- en doorvoerbewerkingen vanwege synchrone replicatie, heeft dit geen invloed op leesquery's. Deze impact is specifiek voor uw workloads, het SKU-type dat u selecteert en de regio.

  U kunt de regio en de beschikbaarheidszones kiezen voor zowel primaire als stand-byservers. De stand-byreplicaserver wordt ingericht in de gekozen beschikbaarheidszone in dezelfde regio met een vergelijkbare reken-, opslag- en netwerkconfiguratie als de primaire server. Gegevensbestanden en transactielogboekbestanden (write-ahead-logboeken, ook wel wal genoemd) worden opgeslagen in lokaal redundante opslag (LRS) binnen elke beschikbaarheidszone, en slaan automatisch drie gegevenskopieën op. Een zone-redundante configuratie biedt fysieke isolatie van de hele stack tussen primaire en stand-byservers.

  

De zone-redundante optie is alleen beschikbaar in regio's die ondersteuning hebben voor beschikbaarheidszones.

Zone-redundant wordt niet ondersteund voor:

• Burstable berekeningslaag

• Regio's met beschikbaarheid in één zone

• Zonaal. Kies een zonegebonden implementatie wanneer u het hoogste beschikbaarheidsniveau binnen één beschikbaarheidszone wilt bereiken, maar met de laagste netwerklatentie. U kunt de regio en de beschikbaarheidszone kiezen om zowel uw primaire databaseserver te implementeren. Een stand-byreplicaserver wordt automatisch ingericht en beheerd in dezelfde beschikbaarheidszone, met vergelijkbare reken-, opslag- en netwerkconfiguratie, als de primaire server. Een zonegebonden configuratie beschermt uw databases tegen storingen op knooppuntniveau 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 de synchrone modus. als er onderbrekingen zijn op de primaire server, voert de server automatisch een failover uit naar de stand-byreplica.

  

De zonegebonden implementatieoptie is beschikbaar in alle Azure-regio's waar u Flexibele server kunt implementeren.

Zonegebonden tolerantie configureren in de portal

U kunt hoge beschikbaarheid (HA) op twee manieren configureren: zone-redundante ha, die de stand-byserver in een andere beschikbaarheidszone plaatst voor maximale tolerantie, of hoge beschikbaarheid van dezelfde zone, waarmee de stand-byserver in dezelfde zone als de primaire server wordt geïmplementeerd om de latentie te minimaliseren.

Om de configuratie te vereenvoudigen en zonegebonden tolerantie te garanderen, biedt de portal een optie Zonegebonden tolerantie met twee keuzerondjes: Ingeschakeld en Uitgeschakeld. Als u Ingeschakeld selecteert, wordt geprobeerd de stand-byserver te maken in een andere beschikbaarheidszone (zone-redundante HA-modus). Als de regio geen zone-redundante HA ondersteunt, kunt u het selectievakje voor terugval aanvinken (gemarkeerd in de volgende afbeelding) om HA in dezelfde zone in te schakelen.

Wanneer u het selectievakje voor terugval inschakelt, maakt het systeem de stand-byserver in dezelfde zone en activeert het later een automatische migratiewerkstroom tijdens een onderhoudsvenster om deze naar een andere zone te verplaatsen zodra de capaciteit beschikbaar is. Als u het selectievakje niet inschakelt en zonegebonden capaciteit niet beschikbaar is, mislukt het inschakelen van hoge beschikbaarheid. Dit ontwerp handhaaft zone-redundante hoge beschikbaarheid (HA) als de standaardinstelling en biedt een gecontroleerde terugval voor dezelfde-zone HA, waardoor workloads uiteindelijk volledige zoneresilientie bereiken zonder handmatige tussenkomst.

Functies voor hoge beschikbaarheid

• Een stand-byreplica wordt geïmplementeerd in dezelfde VM-configuratie, waaronder vCores, opslag en netwerkinstellingen, als de primaire server.

• U kunt ondersteuning voor beschikbaarheidszones toevoegen voor een bestaande databaseserver.

• U kunt de stand-by-replica verwijderen door de hoge beschikbaarheid uit te schakelen.

• U kunt beschikbaarheidszones kiezen voor uw primaire en stand-bydatabaseservers voor zone-redundante beschikbaarheid.

• Bewerkingen zoals stoppen, starten en opnieuw opstarten worden tegelijkertijd uitgevoerd op zowel de primaire server als stand-bydatabaseservers.

• In zoneredundante en zonegebonden modellen voert de primaire databaseserver periodiek automatische back-ups uit. Tegelijkertijd archiveert de stand-byreplica continu de transactielogboeken in de back-up opslag. Als de regio beschikbaarheidszones ondersteunt, worden back-upgegevens opgeslagen in zone-redundante opslag (ZRS). In regio's die geen ondersteuning bieden voor beschikbaarheidszones, worden back-upgegevens opgeslagen op lokale redundante opslag (LRS).

• Clients maken altijd verbinding met de hostnaam van de primaire databaseserver.

• Wijzigingen in de serverparameters worden ook toegepast op de stand-byreplica.

• U kunt de server opnieuw opstarten om eventuele wijzigingen in de parameter van de statische server op te halen.

• Periodieke onderhoudsactiviteiten zoals secundaire versie-upgrades worden eerst uitgevoerd op de stand-by. Door de stand-by server te promoveren tot de primaire server, kunnen workloads doorgaan terwijl de onderhoudstaken worden uitgevoerd op het resterende knooppunt om de downtime te verminderen.

De gezondheid van hoge beschikbaarheid monitoren

Statuscontrole met hoge beschikbaarheid (HA) in Azure Database for PostgreSQL biedt een doorlopend overzicht van de status en gereedheid van instanties met hoge beschikbaarheid. Deze bewakingsfunctie past het RHC-framework (Resource Health Check) van Azure toe om problemen te detecteren en te waarschuwen die van invloed kunnen zijn op de failovergereedheid of algemene beschikbaarheid van uw database. Het bewaken van de gezondheid van de HA-status maakt het mogelijk om belangrijke metrische gegevens zoals verbindingsstatus, failoverstatus en status van gegevensreplicatie te beoordelen, waardoor u proactief problemen kunt oplossen en de uptime en prestatie van uw database kunt waarborgen.

Gebruik gezondheidsstatusmonitoring met hoge beschikbaarheid om:

• Krijg realtime inzicht in de status van zowel primaire als stand-byreplica's, met statusindicatoren die potentiële problemen blootleggen, zoals verminderde prestaties of netwerkblokkering.
• Stel waarschuwingen in voor tijdige meldingen over wijzigingen in de hoge beschikbaarheidsstatus, zodat u onmiddellijk actie kunt ondernemen om potentiële onderbrekingen aan te pakken.
• Optimaliseer de failovergereedheid door problemen te identificeren en op te lossen voordat ze van invloed zijn op databasebewerkingen.

Zie De monitoring van de HA-status voor Azure Database for PostgreSQL voor een uitgebreide handleiding over het configureren en interpreteren van HA-statussen.

Beperkingen van hoge beschikbaarheid

• Vanwege synchrone replicatie naar de stand-byserver, met name met een zone-redundante configuratie, kunnen toepassingen een verhoogde schrijf- en doorvoerlatentie ervaren.

• U kunt de standby-replica niet gebruiken voor leesqueries.

• Afhankelijk van de workload en activiteit op de primaire server kan het failoverproces langer duren dan 120 seconden, omdat de stand-byreplica moet worden hersteld voordat deze kan worden gepromoveerd.

• De stand-byserver herstelt doorgaans WAL-bestanden op 40 MB/s. Voor grotere versies kan dit tarief oplopen tot maximaal 200 MB/s. Als uw werkbelasting deze limiet overschrijdt, kunt u een langere tijd nodig hebben om het herstelproces te voltooien tijdens de failover of nadat u een nieuwe standby hebt ingesteld.

• Als u de primaire databaseserver opnieuw opstart, wordt ook de stand-byreplica opnieuw opgestart.

• U kunt geen extra stand-by configureren.

• U kunt door de klant geïnitieerde beheertaken niet plannen tijdens het venster beheerd onderhoud.

• Geplande gebeurtenissen, zoals het schalen van computing en schaalopslag, vinden eerst plaats op de stand-by en vervolgens op de primaire server. De server voert momenteel geen failover uit voor deze geplande bewerkingen.

• Op een flexibele server met hoge beschikbaarheid is logische decodering of logische replicatie geconfigureerd.

  • In PostgreSQL 16 en eerder worden logische replicatieslots niet standaard behouden op de stand-byserver na een failover.
  • Om ervoor te zorgen dat logische replicatie na een failover blijft functioneren, moet u de pg_failover_slots extensie inschakelen en ondersteunende instellingen configureren, zoals hot_standby_feedback = on.
  • Vanaf PostgreSQL 17 wordt sitesynchronisatie systeemeigen ondersteund. Als u de juiste PostgreSQL-configuraties (sync_replication_slots, hot_standby_feedback) inschakelt, worden logische replicatieslots automatisch behouden na een failover en is geen extensie vereist.
  • Raadpleeg de documentatie voor de PG_Failover_Slots-extensie voor installatiestappen en -vereisten.

• Het configureren van beschikbaarheidszones tussen privé (virtueel netwerk) en openbare toegang met privé-eindpunten wordt niet ondersteund. U moet beschikbaarheidszones in een virtueel netwerk configureren (verspreid over beschikbaarheidszones binnen een regio) of openbare toegang met privé-eindpunten.

• U kunt alleen beschikbaarheidszones binnen één regio configureren. U kunt geen beschikbaarheidszones configureren tussen regio's.

SLA

• Het zonegebonden model biedt een uptime voor een SLA voor ongeveer 99%.

• Het zoneredundantiemodel biedt een uptime voor een SLA voor ongeveer 99%.

Een Azure Database for PostgreSQL maken waarvoor beschikbaarheidszone is ingeschakeld

Voor meer informatie over het maken van een Azure Database for PostgreSQL voor hoge beschikbaarheid met beschikbaarheidszones, raadpleegt u quickstart: Een Azure Database for PostgreSQL maken in Azure Portal.

Opnieuw implementeren en migreren van beschikbaarheidszone

Zie Hoge beschikbaarheid beheren in Flexibele server voor meer informatie over het in- of uitschakelen van configuratie met hoge beschikbaarheid op uw flexibele server in zowel zone-redundante als zonegebonden implementatiemodellen.

Onderdelen en werkstroom voor hoge beschikbaarheid

Transactievoltooiing

Door transacties geactiveerde schrijfbewerkingen en doorvoeringen van toepassingen worden eerst geregistreerd bij de WAL op de primaire server. De primaire server streamt deze logboeken naar de stand-byserver met behulp van het Postgres-streamingprotocol. Wanneer de opslag van de stand-byserver de logboeken persistent maakt, bevestigt de primaire server dat de schrijfbewerking is voltooid. De toepassing voert de transactie pas na deze bevestiging door. Deze extra rondreis voegt latentie toe aan uw toepassing. Het impactpercentage is afhankelijk van de toepassing. Dit bevestigingsproces wacht niet totdat de logbestanden zijn toegepast op de standby-server. De stand-byserver blijft in de herstelmodus totdat deze wordt gepromoveerd.

Gezondheidscontrole

De statuscontrole van flexibele servers controleert periodiek de status van zowel de primaire als de stand-byserver. Als na meerdere pings gezondheidsbewaking detecteert dat een primaire server niet bereikbaar is, start de service een automatische failover naar de standby-server. Het algoritme voor statuscontrole gebruikt meerdere gegevenspunten om fout-positieve situaties te voorkomen.

Failovermodussen

Flexibele server ondersteunt twee failovermodi, geplande failover en niet-geplande failover. In beide modi, zodra de replicatie is verbroken, voert de standby-server herstel uit voordat hij als primaire server wordt gepromoveerd en opent voor lezen en schrijven. Wanneer automatische DNS-vermeldingen zijn bijgewerkt met het nieuwe eindpunt van de primaire server, kunnen toepassingen verbinding maken met de server met hetzelfde eindpunt. Er wordt een nieuwe stand-byserver op de achtergrond tot stand gebracht, zodat uw toepassing verbinding kan onderhouden.

Status van hoge beschikbaarheid

Het systeem bewaakt continu de status van primaire en stand-byservers. Het neemt de juiste acties om problemen op te lossen, waaronder het activeren van een failover naar de stand-byserver. De volgende tabel bevat de mogelijke statussen voor hoge beschikbaarheid:

Onverander gebleven bewerkingen

PostgreSQL-clienttoepassingen maken verbinding met de primaire server met behulp van de databaseservernaam. De primaire server verwerkt rechtstreeks applicatie-lezingen. Tegelijkertijd ontvangt de toepassing alleen bevestiging van doorvoeringen en schrijfbewerkingen nadat de logboekgegevens zich op zowel de primaire server als de stand-byreplica bevinden. Door deze extra retourbezoek kunnen toepassingen verhoogde latentie verwachten bij schrijf- en commitbewerkingen. U kunt de status van de hoge beschikbaarheid in de portal bewaken.

1. Clients maken verbinding met de flexibele server en voeren schrijfbewerkingen uit.
2. Wijzigingen worden gerepliceerd naar de standbysite.
3. Primair ontvangt een bevestiging.
4. Schrijf- en doorvoerbewerkingen worden bevestigd.

Herstel van servers met hoge beschikbaarheid naar een specifiek tijdstip

Voor flexibele servers die zijn geconfigureerd met hoge beschikbaarheid, repliceert het systeem logboekgegevens in realtime naar de stand-byserver. Gebruikersfouten op de primaire server, zoals een onbedoelde daling van een tabel of onjuiste gegevensupdates, worden gerepliceerd naar de stand-byreplica. U kunt de stand-by dus niet gebruiken om dergelijke logische fouten te herstellen. Als u dergelijke fouten wilt herstellen, moet u een herstel op een bepaald tijdstip uitvoeren vanuit de back-up. Door de functie voor herstel naar een bepaald tijdstip van een flexibele server te gebruiken, kunt u herstellen naar het tijdstip voordat de fout is opgetreden. Een nieuwe databaseserver wordt hersteld als een flexibele server met één zone met een nieuwe door de gebruiker verstrekte servernaam voor databases die zijn geconfigureerd met hoge beschikbaarheid. U kunt de herstelde server gebruiken voor verschillende gebruiksvoorbeelden:

• Gebruik de herstelde server voor productie en schakel indien gewenst hoge beschikbaarheid in met een stand-byreplica in dezelfde zone of een andere zone binnen dezelfde regio.

• Als u een object wilt herstellen, exporteert u het van de herstelde databaseserver en importeert u het naar de productiedatabaseserver.

• Als u uw databaseserver wilt klonen voor test- en ontwikkelingsdoeleinden of voor andere doeleinden wilt herstellen, kunt u het herstel naar een bepaald tijdstip uitvoeren.

Als u wilt weten hoe u een flexibele server naar een bepaald tijdstip kunt herstellen, zie Herstel naar een bepaald tijdstip van een flexibele server.

Failover-ondersteuning

Geplande overdracht

Geplande downtime-gebeurtenissen omvatten geplande periodieke software-updates en secundaire versie-upgrades van Azure. U kunt ook een geplande failover gebruiken om de primaire server te retourneren naar een beschikbaarheidszone van voorkeur. Wanneer u hoge beschikbaarheid configureert, zijn deze bewerkingen eerst van toepassing op de stand-byreplica terwijl toepassingen toegang blijven krijgen tot de primaire server. Zodra het proces de stand-byreplica bijwerkt, wordt de primaire serververbindingen verwijderd en wordt een failover geactiveerd die de stand-byreplica activeert als de primaire server met dezelfde databaseservernaam. Clienttoepassingen maken opnieuw verbinding met dezelfde databaseservernaam op de nieuwe primaire server en kunnen hun bewerkingen hervatten. Met het proces wordt een nieuwe stand-byserver in dezelfde zone als de oude primaire server tot stand gebracht.

Voor andere door de gebruiker geïnitieerde bewerkingen, zoals scale-compute of scale-storage, past het proces eerst wijzigingen toe op de stand-by en vervolgens de primaire bewerking. Op dit moment voert de service geen failover uit naar de stand-by. Dus terwijl de schaalbewerking wordt uitgevoerd op de primaire server, hebben toepassingen korte downtime.

U kunt deze functie ook gebruiken om een failover uit te voeren naar de stand-byserver met verminderde downtime. Uw primaire server kan zich bijvoorbeeld in een andere beschikbaarheidszone bevinden dan de toepassing na een niet-geplande failover. U wilt de primaire server terugplaatsen naar de vorige zone zodat deze samen met uw toepassing wordt geplaatst.

Wanneer u deze functie uitvoert, bereidt het proces eerst de stand-byserver voor om ervoor te zorgen dat deze bij recente transacties wordt ingehaald, zodat de applicatie kan blijven lezen en schrijven. Het proces bevordert de stand-by en breekt de verbindingen met de primaire. Uw toepassing kan blijven schrijven naar de primaire server terwijl het proces een nieuwe stand-byserver op de achtergrond tot stand brengt. In de volgende tabel worden de stappen beschreven die betrekking hebben op geplande failover:

Downtime van toepassingen begint bij stap 3 en kan na stap 5 de bewerking hervatten. De rest van de stappen worden op de achtergrond uitgevoerd zonder dat dit van invloed is op schrijf- en doorvoerbewerkingen van toepassingen.

Zie Geplande downtime-gebeurtenissen voor een lijst met mogelijke geplande downtime-gebeurtenissen.

Niet-geplande failover

Ongeplande downtime kan optreden als gevolg van onvoorziene onderbrekingen, zoals onderliggende hardwarefouten, netwerkproblemen en softwarefouten. Als de databaseserver die is geconfigureerd met hoge beschikbaarheid onverwacht uitvalt, activeert het proces de stand-byreplica en kunnen clients hun bewerkingen hervatten. Als u hoge beschikbaarheid (HA) niet configureert en de poging tot opnieuw opstarten mislukt, wordt automatisch een nieuwe databaseserver ingericht. Hoewel een niet-geplande downtime niet kan worden vermeden, helpt flexibele server de downtime te beperken door automatisch herstelbewerkingen uit te voeren zonder menselijke tussenkomst.

Zie Niet-geplande downtime beperking voor informatie over niet-geplande failovers en downtime, inclusief mogelijke scenario's.

Failovertesten (geforceerde failover)

Met een geforceerde failover kunt u een ongepland storingsscenario simuleren tijdens het uitvoeren van uw productieworkload en de downtime van uw toepassing observeren. U kunt ook een geforceerde failover gebruiken wanneer uw primaire server niet meer reageert.

Een geforceerde failover legt de primaire server plat en initieert de failoverwerkstroom waarin de standby-promotiebewerking wordt uitgevoerd. Zodra de standby-server het herstelproces heeft voltooid tot de laatste vastgelegde gegevens, wordt deze gepromoveerd tot de primaire server. DNS-records worden bijgewerkt en uw toepassing kan verbinding maken met de gepromoveerde primaire server. Uw toepassing kan blijven schrijven naar de primaire server terwijl er een nieuwe stand-byserver op de achtergrond wordt ingesteld, wat geen invloed heeft op de uptime.

In de volgende tabel worden de stappen beschreven tijdens geforceerde failover:

Downtime van toepassingen wordt gestart na stap 1 en gaat door totdat stap 6 is voltooid. De andere stappen worden op de achtergrond uitgevoerd zonder dat dit van invloed is op schrijf- en doorvoerbewerkingen van toepassingen.

Overwegingen bij het uitvoeren van geforceerde failovers

• De totale end-to-end-bewerkingstijd kan langer zijn dan de werkelijke downtime die de toepassing ondervindt.

  Belangrijk

  Bekijk altijd de downtime vanuit het perspectief van de toepassing.

• Voer geen directe back-to-back-failovers uit. Wacht ten minste 15-20 minuten tussen failovers, zodat de nieuwe stand-byserver volledig tot stand kan worden gebracht.

• Voer een geforceerde failover uit tijdens een periode met weinig activiteit om de downtime te verminderen.

Best practices voor PostgreSQL-statistieken na een failover

Na een PostgreSQL-failover moeten de optimale databaseprestaties worden onderhouden door inzicht te krijgen in de verschillende rollen van pg_statistic en de pg_stat_* -tabellen. In pg_statistic de tabel worden optimalisatiestatistieken opgeslagen, die cruciaal zijn voor de queryplanner. Deze statistieken omvatten gegevensdistributies in tabellen en blijven intact na een failover, zodat de queryplanner de uitvoering van query's effectief kan blijven optimaliseren op basis van nauwkeurige, historische gegevensdistributiegegevens.

In tegenstelling tot de tabellen pg_stat_*, die activiteitsstatistieken vastleggen zoals het aantal scans, gelezen tuples en updates, worden deze opnieuw ingesteld bij failover. Een voorbeeld van een dergelijke tabel is pg_stat_user_tables, waarmee activiteiten voor door de gebruiker gedefinieerde tabellen worden bijgehouden. Deze reset weerspiegelt nauwkeurig de operationele status van de nieuwe primaire, maar betekent ook het verlies van historische activiteitsgegevens die het autovacuumproces en andere operationele efficiëntie kunnen informeren.

Voer ANALYZE uit na een PostgreSQL-failover gezien dit onderscheid. Met deze actie worden de pg_stat_* tabellen, zoals pg_stat_user_tables, bijgewerkt met nieuwe activiteitsstatistieken, waardoor het autovacuumproces wordt geholpen en ervoor wordt gezorgd dat de databaseprestaties optimaal blijven in de nieuwe rol. Deze proactieve stap overbrugt de kloof tussen het behouden van essentiële optimizer-statistieken en het vernieuwen van metrische gegevens over activiteit, zodat deze overeenkomt met de huidige status van de database.

Ontspanervaring

Zonale: Als u wilt herstellen na een fout op zoneniveau, kunt u een herstel naar een bepaald tijdstip uitvoeren met de back-up. U kunt een aangepast herstelpunt kiezen met de laatste tijd om de meest recente gegevens te herstellen. Er wordt een nieuwe flexibele server geïmplementeerd in een andere niet-betrokken 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.

Voor meer informatie over herstel naar een bepaald tijdstip, zie Back-up en herstel in Azure Database for PostgreSQL-Flexible Server.

Zone-redundant: Flexibele server voert automatisch een failover uit naar de stand-byserver binnen 60-120 seconden zonder gegevensverlies.

Configuraties zonder beschikbaarheidszones

Hoewel het niet wordt aanbevolen, kunt u uw flexibele server configureren zonder hoge beschikbaarheid ingeschakeld. Voor flexibele servers die zijn geconfigureerd zonder hoge beschikbaarheid, biedt de service lokaal redundante opslag met drie kopieën van gegevens, zone-redundante back-up (in regio's waar deze wordt ondersteund) en ingebouwde servertolerantie om automatisch een vastgelopen server opnieuw op te starten en de server te verplaatsen naar een ander fysiek knooppunt. Deze configuratie biedt een SLA voor uptime van 99,9%. Tijdens geplande of niet-geplande failovergebeurtenissen, als de server uitvalt, behoudt de service de beschikbaarheid van de servers met behulp van de volgende geautomatiseerde procedure:

1. Er wordt een nieuwe Linux reken-VM ingericht.
2. De opslag met gegevensbestanden wordt toegewezen aan de nieuwe virtuele machine.
3. PostgreSQL-database-engine wordt online gebracht op de nieuwe virtuele machine.

In de volgende afbeelding ziet u de overgang tussen vm en opslagfout.

Herstel na noodgevallen en bedrijfscontinuïteit tussen regio's

Als een regiobreed noodgeval is, kan Azure bescherming bieden tegen regionale of grote geografische rampen met herstel na noodgevallen door gebruik te maken van een andere regio. Zie de architectuur voor herstel na noodgevallen van Azure naar Azure voor meer informatie over de architectuur voor herstel na noodgevallen van Azure.

Flexibele server biedt functies die gegevens beschermen en downtime beperken voor uw bedrijfskritieke databases tijdens geplande en ongeplande downtimegebeurtenissen. Flexibele server is gebouwd op de Azure-infrastructuur die robuuste tolerantie en beschikbaarheid biedt, biedt functies voor bedrijfscontinuïteit die foutbeveiliging bieden, de vereisten voor hersteltijd 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.

Herstel bij rampen in meerdere regio's

Geografisch redundante back-up en herstel

Geografisch redundante back-up en herstel bieden u de mogelijkheid om uw server in een andere regio te herstellen als er zich een noodgeval voordoet. Het biedt ook ten minste 99,9999999999999999 procent (16 negens) duurzaamheid van back-upobjecten gedurende een jaar.

U kunt alleen geografisch redundante back-ups configureren wanneer u de server maakt. Wanneer u de server configureert met geografisch redundante back-up, worden de back-upgegevens en transactielogboeken asynchroon naar de gekoppelde regio gekopieerd via opslagreplicatie.

Zie geografisch redundante back-up en herstel voor meer informatie over geografisch redundante back-up en herstel.

Leeskopieën

U kunt leesreplica's in meerdere regio's implementeren om uw databases te beschermen tegen storingen op regioniveau. Leesreplica's worden asynchroon bijgewerkt met behulp van de fysieke replicatietechnologie van PostgreSQL en kunnen de primaire replica's vertraging oplopen. Algemene en geheugen-geoptimaliseerde rekenlagen ondersteunen leesreplica's.

Voor meer informatie over leesreplicafuncties en overwegingen, zie Leesreplica's.

Detectie, melding en beheer van storingen

Als u uw server configureert met geografisch redundante back-up, kunt u geo-herstel uitvoeren in de gekoppelde regio. Er wordt een nieuwe server ingericht en hersteld naar de laatst beschikbare gegevens die naar deze regio zijn gekopieerd.

U kunt ook leesreplica's in meerdere regio's gebruiken. Als er een regiofout optreedt, kunt u rampherstel uitvoeren door uw leesreplica te promoveren tot een zelfstandige lees-/schrijfbare server. RPO duurt naar verwachting maximaal 5 minuten (mogelijk gegevensverlies), behalve als er ernstige regionale fouten optreden wanneer de RPO zich op het moment van storing dicht bij de replicatievertraging kan bevinden.

Zie Ongeplande uitvaltijd beperken voor meer informatie over het beperken van ongeplande uitvaltijd en herstel na een regionale ramp.

Verwante inhoud

• Documentatie voor Azure Database for PostgreSQL
• Betrouwbaarheid in Azure