Betrouwbaarheid in Azure Database for PostgreSQL

Azure Database for PostgreSQL is een volledig beheerde databaseservice die u gedetailleerde controle en flexibiliteit biedt voor databasebeheerfuncties en configuratie-instellingen. De service biedt mogelijkheden voor hoge beschikbaarheid en herstel na noodgevallen op basis van uw vereisten.

Wanneer u Azure gebruikt, is betrouwbaarheid een gedeelde verantwoordelijkheid. Microsoft biedt een scala aan mogelijkheden ter ondersteuning van tolerantie en herstel. U bent verantwoordelijk voor het begrijpen van de werking van deze mogelijkheden binnen alle services die u gebruikt en het selecteren van de mogelijkheden die u nodig hebt om te voldoen aan uw bedrijfsdoelstellingen en beschikbaarheidsdoelen.

In dit artikel wordt beschreven hoe u Azure Database for PostgreSQL bestand maakt tegen verschillende mogelijke storingen en problemen, waaronder tijdelijke fouten, storingen in de beschikbaarheidszone, regiostoringen en serviceonderhoud. Er wordt ook beschreven hoe u back-ups kunt gebruiken om te herstellen na andere soorten problemen, en belangrijke informatie over de service-level agreement (SLA) voor Azure Database for PostgreSQL wordt belicht.

Aanbevelingen voor productie-implementatie

Zie Aanbevolen procedures voor de architectuur van Azure Database for PostgreSQL in het Azure Well-Architected Framework voor meer informatie over hoe u Azure Database for PostgreSQL implementeert ter ondersteuning van de betrouwbaarheidsvereisten van uw oplossing, en hoe de betrouwbaarheid van invloed is op andere aspecten van uw architectuur.

Overzicht van betrouwbaarheidsarchitectuur

In deze sectie worden enkele belangrijke aspecten beschreven van de werking van de service die het meest relevant is vanuit het perspectief van betrouwbaarheid. In de sectie wordt de logische architectuur geïntroduceerd, die enkele van de resources en functies bevat die u implementeert en gebruikt. Ook wordt de fysieke architectuur besproken, die details biedt over hoe de service achter de schermen werkt.

Logische architectuur

Wanneer u met Azure Database for PostgreSQL werkt, implementeert u een server, die de reken- en opslagresources vertegenwoordigt die nodig zijn ter ondersteuning van de databases die u op de server implementeert.

U kunt servers in meerdere rekenlagen implementeren: Burstable, Algemeen gebruik en Geoptimaliseerd voor geheugen. Elke laag is geoptimaliseerd voor verschillende soorten workloads. In sommige Azure-regio's kunt u servers implementeren met Azure Confidential Computing.

Zie Azure Database for PostgreSQL overzicht voor meer informatie over de algemene servicearchitectuur en implementatiemodellen.

Fysieke architectuur

• Berekenings- en opslagscheiding: Azure Database for PostgreSQL maakt gebruik van een architectuur voor reken- en opslagscheiding ter ondersteuning van hoge beschikbaarheid. De database-engine wordt uitgevoerd op een virtuele Linux-machine (VM), terwijl Azure Storage de gegevensbestanden bevat en drie lokaal redundante synchrone kopieën van de databasebestanden bewaart om de duurzaamheid van gegevens te garanderen.

• Hoge beschikbaarheid: U kunt een configuratie met hoge beschikbaarheid op uw server inschakelen. Wanneer u de configuratie voor hoge beschikbaarheid inschakelt, richt de service een warme stand-byserver in en onderhoudt deze. De primaire server repliceert synchroon gegevenswijzigingen naar de stand-byserver om ervoor te zorgen dat er geen gegevens verloren gaan tijdens een storing van de primaire server.

  De architectuur scheidt de rekenlaag van de opslaglaag, zodat de service op de juiste wijze verschillende typen fouten kan verwerken. Voor een hogere tolerantie kunt u de servers over beschikbaarheidszones verdelen.

  

  Diagram met de architectuur voor hoge beschikbaarheid voor Azure Database for PostgreSQL. Twee servers staan naast elkaar. Aan de linkerkant bevindt zich een vak met het label primaire server en in dat vak bevindt zich een virtuele machine en een schijf. Aan de rechterkant bevindt zich een overeenkomend vak met het label stand-byserver die ook een virtuele machine en een schijf bevat. Een horizontale pijl wijst van de primaire server aan de linkerkant naar de stand-byserver aan de rechterkant en de pijl heeft het label streamingreplicatie, wat een eenrichtingsrelatie aangeeft waarbij gegevens van de primaire server naar de stand-byserver stromen.

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

  U kunt schakelen tussen servers door een failover uit te voeren. Er bestaan twee typen failovers: geforceerde failovers, die worden gebruikt wanneer de primaire server uitvalt en geplande failovers, die worden gebruikt tijdens sommige onderhoudsbewerkingen en in andere scenario's waarin u de downtime van toepassingen tijdens een failover moet minimaliseren.

  Wanneer u bewerkingen uitvoert zoals stoppen, starten en opnieuw opstarten, vinden deze plaats op zowel primaire als stand-bydatabaseservers tegelijk. Geplande gebeurtenissen, zoals het schalen van rekenkracht en het schalen van opslag, vinden eerst plaats op de stand-by en vervolgens op de primaire server. Op dit moment voert de server geen failover uit voor deze geplande bewerkingen.

  Zie Hoge beschikbaarheid in Azure Database for PostgreSQL voor meer informatie.

• Backups: In Azure Database for PostgreSQL worden automatisch serverback-ups gemaakt. Zie Back-up en herstel voor meer informatie.

Tolerantie voor tijdelijke fouten

Tijdelijke fouten zijn korte, onregelmatige fouten in onderdelen. Ze vinden vaak plaats in een gedistribueerde omgeving, zoals de cloud, en ze zijn een normaal onderdeel van de bewerkingen. Tijdelijke fouten corrigeren zichzelf na een korte periode. Het is belangrijk dat uw toepassingen tijdelijke fouten kunnen afhandelen, meestal door de betreffende aanvragen opnieuw uit te voeren.

Alle cloudtoepassingen moeten de Azure richtlijnen voor tijdelijke foutafhandeling volgen wanneer ze communiceren met api's, databases en andere onderdelen die in de cloud worden gehost. Zie Aanbevelingen voor het afhandelen van tijdelijke foutenvoor meer informatie.

Uw toepassingen moeten tijdelijke verbindingsfouten afhandelen die kunnen optreden tijdens onderhoud, schaalbewerkingen of netwerkonderbrekingen. Volg deze aanbevelingen:

• Wanneer uw toepassing tijdelijke fouten ondervindt, voert u de bewerking opnieuw uit met behulp van exponentieel uitstel. Verhoog de vertraging tussen nieuwe pogingen en beperk het aantal pogingen. Als de bewerking nog steeds mislukt na de maximale nieuwe pogingen, behandelt u deze als een fout.

• Gebruik waar mogelijk clientbibliotheken (ook wel stuurprogramma's genoemd) die automatisch nieuwe pogingen verwerken.

• Tijdelijke fouten die optreden tijdens schrijfbewerkingen, moeten zorgvuldiger worden overwogen. Overweeg uw schrijfbewerkingen idempotent te maken, zodat ze veilig meerdere keren kunnen worden uitgevoerd.

Zie Tijdelijke connectiviteitsfouten verwerken in Azure Database for PostgreSQL voor meer informatie.

Tolerantie voor fouten in beschikbaarheidszones

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

Selecteer uw type ondersteuning voor beschikbaarheidszones via de configuratie voor hoge beschikbaarheid. Wanneer u hoge beschikbaarheid inschakelt, implementeert de service een stand-byserver naast uw primaire server. Dit model voor hoge beschikbaarheid zorgt ervoor dat vastgelegde gegevens nooit verloren gaan tijdens fouten. Ongeacht het implementatiemodel voor hoge beschikbaarheid dat uw server gebruikt, worden gegevens synchroon doorgevoerd op zowel de primaire als stand-byservers. Als er een onderbreking optreedt op de primaire server, voert de server automatisch een failover uit naar de stand-byserver.

In elke beschikbaarheidszone worden gegevensbestanden en schrijflogboeken (WAL's) op premium beheerde schijven opgeslagen met lokaal redundante opslag (LRS) waarin automatisch drie gegevenskopieën in elke zone worden opgeslagen.

Azure Database for PostgreSQL ondersteunt twee configuratietypen voor beschikbaarheidszones wanneer u hoge beschikbaarheid gebruikt:

• Zone-redundante hoge beschikbaarheid: Zoneredundantie biedt het hoogste niveau van zonetolerantie door een primaire server te implementeren in één beschikbaarheidszone en een stand-byserver in een andere beschikbaarheidszone. De stand-byserver maakt gebruik van reken-, opslag- en netwerkconfiguratie die vergelijkbaar is met die van de primaire server. Een zone-redundante configuratie biedt fysieke isolatie van de hele stack tussen primaire en stand-byservers.

  U kunt de beschikbaarheidszones selecteren voor de primaire en stand-byservers of Microsoft deze laten kiezen.

  We raden zone-redundante implementaties aan voor productieservers.

  

  Diagram met een zone-redundante Azure Database for PostgreSQL setup verspreid over beschikbaarheidszones. Drie zones worden bovenaan weergegeven: beschikbaarheidszone 1, beschikbaarheidszone 2 en beschikbaarheidszone 3. Onder beschikbaarheidszone 1 is een vak met het label primaire server en in dat vak is een virtuele machine en een schijf, die laat zien dat de primaire server bestaat uit rekenkracht en opslag. Onder beschikbaarheidszone 2 is er een overeenkomend vak met het label stand-byserver die ook een virtuele machine en een schijf bevat. Tussen deze twee servervakken bevindt zich een pijl naar rechts met het label Streaming-replicatie, die laat zien dat gegevenswijzigingen stromen van de primaire server aan de linkerkant naar de stand-byserver aan de rechterkant. De indeling communiceert tolerantie tussen zones: primaire en stand-by zijn gescheiden door twee beschikbaarheidszones, terwijl beschikbaarheidszone 3 ongebruikt blijft.

  Schrijfbewerkingen kunnen een kleine toename van doorvoerlatentie ervaren omdat de service synchroon gegevens repliceert naar de stand-byserver. De impact verschilt per workload, geselecteerde SKU en regio.

• Zonegebonden (dezelfde zone) hoge beschikbaarheid: De primaire en stand-byservers gebruiken dezelfde beschikbaarheidszone. Als er een onderbreking optreedt op de primaire server, maar de zone nog steeds in orde is, voert de server automatisch een failover uit naar de stand-byserver. Een zonegebonden implementatie biedt u hoge beschikbaarheid binnen één beschikbaarheidszone. Het beschermt u tegen storingen op knooppuntniveau en helpt ook bij het verminderen van de downtime van toepassingen tijdens geplande en ongeplande downtimegebeurtenissen. Het beschermt echter niet tegen een storing in die zone.

  

  Diagram met een zonegebonden Azure Database for PostgreSQL setup in één beschikbaarheidszone. Er worden drie zones weergegeven: beschikbaarheidszone 1, beschikbaarheidszone 2 en beschikbaarheidszone 3. In beschikbaarheidszone 1 zijn er twee vakken naast elkaar. Het vak aan de linkerkant heeft het label primaire server en in dat vak is een virtuele machine en een schijf. Het vak aan de rechterkant is gelabeld als stand-byserver en in dat vak is een virtuele machine en een schijf. Tussen deze twee servervakken staat een naar rechts wijzende pijl met het label 'streamingreplicatie', die laat zien dat gegevenswijzigingen van de primaire server aan de linkerkant naar de standbyserver aan de rechterkant worden doorgegeven. Beide servers bevinden zich in dezelfde beschikbaarheidszone. Beschikbaarheidszone 2 en beschikbaarheidszone 3 worden niet gebruikt.

  Zonegebonden hoge beschikbaarheid (dezelfde zone) is alleen beschikbaar in de volgende situaties:

  • De regio biedt geen ondersteuning voor beschikbaarheidszones. De regio functioneert effectief als één zone, dus de enige configuratie voor hoge beschikbaarheid die u kunt selecteren, is dezelfde zone.
  • Als een regio onvoldoende capaciteit heeft voor een zone-redundante implementatie, kan de service in eerste instantie beide servers in dezelfde beschikbaarheidszone plaatsen en deze vervolgens automatisch migreren naar afzonderlijke zones wanneer de capaciteit beschikbaar is. Deze optie is beschikbaar wanneer u Azure Portal of de Azure CLI gebruikt om een server te implementeren. Zie Opties voor bedrijfskritiek (hoge beschikbaarheid) configureren voor meer informatie.

  Het plaatsen van de servers in dezelfde zone kan de schrijflatentie verminderen voor toepassingen die u in dezelfde zone implementeert.

  Wanneer de servers zich in dezelfde zone bevinden, kan de schrijflatentie voor toepassingen die u in dezelfde zone implementeert, worden verminderd.

Als u uw server zonder hoge beschikbaarheid configureert, wordt deze uitgevoerd op één server. Als die server of de zone uitvalt, is uw server niet beschikbaar. Zie Configuraties zonder beschikbaarheidszones voor meer informatie.

Requirements

• Regioondersteuning: Azure Database for PostgreSQL ondersteunt configuraties van beschikbaarheidszones verschillend in Azure regio's. Zie Azure regio's voor een volledige lijst met regio's en de typen ondersteuning voor beschikbaarheidszones en eventuele specifieke overwegingen voor elke regio.

• Rekenlaag: De volgende tabel bevat de ondersteuning voor de rekenlaag voor elk type ondersteuning voor beschikbaarheidszones:

  Rekenlaag	Zoneredundant	Zonegebonden (dezelfde zone)
  Burstbaar	Niet ondersteund	Niet ondersteund
  Algemeen gebruik	Ondersteund	Ondersteund
  Geoptimaliseerd geheugen	Ondersteund	Ondersteund

• Servicelaag: Voor beide typen hoge beschikbaarheid zijn de lagen Algemeen gebruik of Geoptimaliseerd voor geheugen vereist.

Overwegingen

Regiocapaciteit: Als een regio onvoldoende capaciteit heeft voor een zone-redundante implementatie, kan de service in eerste instantie beide servers in dezelfde beschikbaarheidszone plaatsen en deze automatisch migreren naar afzonderlijke zones wanneer de capaciteit beschikbaar is. Deze optie is beschikbaar wanneer u Azure Portal of de Azure CLI gebruikt om een server te implementeren. Zie Opties voor bedrijfskritiek (hoge beschikbaarheid) configureren voor meer informatie.

Cost

Wanneer u hoge beschikbaarheid inschakelt, wordt er een stand-byserver gemaakt en wordt deze gefactureerd tegen hetzelfde tarief als de primaire server. De configuratie van de beschikbaarheidszone heeft geen invloed op de kosten. Er worden geen kosten in rekening gebracht voor gegevensreplicatie binnen of tussen beschikbaarheidszones. Afhankelijk van uw back-upopslagvolume, wordt u mogelijk ook gefactureerd voor back-upopslag. Zie voor gedetailleerde informatie over prijzen Azure Database for PostgreSQL prijzen.

Ondersteuning voor beschikbaarheidszones configureren

Als u ondersteuning voor beschikbaarheidszones voor een server wilt configureren, configureert u de instellingen voor hoge beschikbaarheid.

• Een zoneredundante server maken: Zie quickstart: Een Azure Database for PostgreSQL-server maken voor meer informatie over het maken van een server met hoge beschikbaarheid en zoneredundantie ingeschakeld.

• Wijzig de configuratie van de beschikbaarheidszone voor bestaande servers: Wijzig de configuratie van de beschikbaarheidszone voor bestaande servers door de instellingen voor hoge beschikbaarheid te wijzigen. Zie Hoge beschikbaarheid inschakelen voor bestaande servers voor gedetailleerde stappen.

  U kunt de zone die wordt gebruikt voor de primaire of stand-byserver niet wijzigen. U moet de server opnieuw maken.

  Aanbeveling

  U wordt aangeraden te wachten totdat de serveractiviteit laag is voordat u de configuratie voor hoge beschikbaarheid wijzigt.

• Hoge beschikbaarheid uitschakelen: Als u hoge beschikbaarheid uitschakelt, wordt de stand-byserver verwijderd, zodat uw server niet bestand is tegen storingen in de beschikbaarheidszone. Zie Hoge beschikbaarheid uitschakelen voor meer informatie.

Gedrag wanneer alle zones in orde zijn

In deze sectie wordt beschreven wat u kunt verwachten wanneer u servers configureert met ondersteuning voor hoge beschikbaarheid en beschikbaarheidszones en alle beschikbaarheidszones operationeel zijn.

• Bewerking tussen zones: PostgreSQL-clienttoepassingen maken verbinding met de primaire server met behulp van de naam van de databaseserver. Azure Database for PostgreSQL maakt gebruik van een actief-passieve configuratie waarbij de primaire server in de primaire beschikbaarheidszone alle databaseverbindingen en query's verwerkt. De stand-by-server verwerkt geen clientverkeer tijdens normale operaties.

• Replicatie van gegevens in meerdere zones: De primaire server repliceert synchroon wijzigingen in de stand-byserver. Transacties worden pas als voltooid beschouwd als de primaire en stand-byservers de schrijfbewerking bevestigen.

  Wanneer een toepassing gegevens schrijft en doorvoert, registreert PostgreSQL eerst de wijziging in de WAL op de primaire server. De primaire server streamt deze logboeken naar de stand-byserver met behulp van het PostgreSQL-streamingprotocol. Nadat de stand-byserver de WAL duurzaam heeft opgeslagen, bevestigt de primaire server de schrijfbewerking. De toepassing voert de transactie pas na deze bevestiging door. Dit bevestigingsproces wacht niet totdat de logbestanden zijn toegepast op de standby-server.

  De gevolgen van replicatie verschillen, afhankelijk van de configuratie van de beschikbaarheidszone die uw server gebruikt:

  • Zone-redundant: Omdat de servers zich in afzonderlijke zones bevinden, zorgt deze benadering ervoor dat er geen gegevens verloren gaan tijdens een zonefout. Deze situatie wordt soms ook wel het bereiken van een recovery point objective (RPO) van nul genoemd in het geval van zonefouten.

    Replicatie tussen zones kan echter een kleine hoeveelheid extra latentie veroorzaken. De impact van de latentie is afhankelijk van de toepassing. Voor de meeste toepassingen is de extra latentie verwaarloosbaar.

  • Zonegebonden: Omdat beide servers zich in dezelfde zone bevinden, wordt er geen verkeer tussen zones gerepliceerd.

  Opmerking

  Het systeem repliceert 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-byserver. U kunt de stand-by niet gebruiken om te herstellen van dit soort fouten en u moet een herstel naar een bepaald tijdstip uitvoeren vanuit de back-up. Zie Back-up en herstel voor meer informatie.

Gedrag tijdens een zonefout

In deze sectie wordt beschreven wat u kunt verwachten wanneer u servers configureert met hoge beschikbaarheid en ondersteuning voor beschikbaarheidszones, en er een storing in een beschikbaarheidszone optreedt.

• Detectie en reactie: Azure controleert regelmatig de status van de primaire en stand-byservers. 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.

  Als een beschikbaarheidszone mislukt, verschilt het gedrag, afhankelijk van de configuratie van de beschikbaarheidszone die uw server gebruikt:

  • Zone-redundant: Azure Database for PostgreSQL detecteert automatisch fouten in de beschikbaarheidszone. Als u de mogelijke statustypen voor hoge beschikbaarheid wilt bekijken, raadpleegt u statusbewaking met hoge beschikbaarheid (HA). Wanneer een zone mislukt, start Azure een geforceerde failover naar de stand-byserver zonder dat u actie hoeft te ondernemen.

  • Zonal: Als de beschikbaarheidszone die als host fungeert voor een zonegebonden server niet meer beschikbaar is, zijn zowel de primaire als de stand-byserver niet beschikbaar. In dit scenario biedt de service geen automatische failover. U bent verantwoordelijk voor het detecteren van de zonestoring en het uitvoeren van herstelacties, zoals het herstellen van zone-redundante back-ups naar een afzonderlijke server in een andere beschikbaarheidszone of regio.

• Kennisgeving: Statuscontrole met hoge beschikbaarheid in Azure Database for PostgreSQL biedt een doorlopend overzicht van de status en gereedheid van instanties met hoge beschikbaarheid. De bewakingsfunctie is gebaseerd op Azure Resource Health en kan eventuele problemen detecteren en waarschuwen die van invloed kunnen zijn op de failovergereedheid of algemene beschikbaarheid van uw database. Evalueer belangrijke metrische gegevens, zoals verbindingsstatus, failoverstatus en status van gegevensreplicatie om proactieve probleemoplossing mogelijk te maken en de uptime en prestaties van uw database te behouden.

  Zie Bewaking van de gezondheidsstatus van hoge beschikbaarheid (HA) voor een gedetailleerde handleiding voor het configureren en interpreteren van de gezondheidsstatussen van HA.

• Actieve aanvragen: Wanneer een beschikbaarheidszone niet beschikbaar is, kunnen aanvragen die worden uitgevoerd voor servers in de betrokken zone, worden beëindigd. Toepassingen moeten deze aanvragen opnieuw proberen. Als uw clients tijdelijke fouten op de juiste wijze afhandelen door het opnieuw te proberen na een korte periode, worden meestal aanzienlijke gevolgen vermeden.

• Verwachte gegevensverlies: De hoeveelheid gegevensverlies is afhankelijk van de configuratie van de beschikbaarheidszone die uw server gebruikt.

  • Zone-redundant: Er wordt geen gegevensverlies verwacht tijdens zonefailover vanwege synchrone replicatie tussen de primaire en stand-byservers in verschillende zones.

  • Zonal: Gegevens op servers in de getroffen zone zijn niet beschikbaar totdat de zone wordt hersteld.

• Verwachte downtime: De hoeveelheid downtime is afhankelijk van de configuratie van de beschikbaarheidszone die door uw server wordt gebruikt.

  • Zone-redundant: Failover wordt doorgaans binnen 60-120 seconden voltooid. Als uw clients tijdelijke fouten op de juiste wijze afhandelen door het opnieuw te proberen na een korte periode, worden meestal aanzienlijke gevolgen vermeden.

  • Zonal: Servers in een getroffen zone zijn niet beschikbaar totdat de beschikbaarheidszone wordt hersteld.

• Herverdeling: Het gedrag voor het omleiden van verkeer is afhankelijk van de configuratie van de beschikbaarheidszone die door uw server wordt gebruikt.

  • Zone-redundant: Na een failover wordt de voormalige stand-byserver de nieuwe primaire server en worden nieuwe verbindingen geaccepteerd. Azure brengt automatisch een nieuwe stand-byserver in de oorspronkelijke primaire zone tot stand nadat deze is hersteld. Zie Geforceerde failover voor meer informatie.

  • Zonal: Wanneer een zone niet beschikbaar is, is uw server niet beschikbaar. Als u een afzonderlijke server hebt die u vooraf hebt gemaakt in een andere beschikbaarheidszone of regio, bent u verantwoordelijk voor het opnieuw routeren van verkeer naar die server.

Zoneherstel

Het gedrag van zoneherstel is afhankelijk van de configuratie van de beschikbaarheidszone die door uw server wordt gebruikt.

• Zone-redundant: Wanneer de beschikbaarheidszone wordt hersteld, bouwt Azure Database for PostgreSQL de stand-byserver automatisch opnieuw op in de herstelde zone en synchroniseert deze met de huidige primaire server. De herstelde zone fungeert vervolgens als de stand-bylocatie. Om onnodige onderbrekingen te voorkomen, verplaatst de service de primaire rol niet automatisch terug naar de oorspronkelijke zone. U kunt handmatig een geplande failover starten als u de primaire zone wilt terugsturen naar de oorspronkelijke zone.

• Zonal: Nadat de zone in orde is, zijn servers in de zone weer beschikbaar. U bent verantwoordelijk voor alle zoneherstelprocedures en gegevenssynchronisatie die uw workloads nodig hebben.

Testen op zonefouten

De opties voor het testen van zonefouten zijn afhankelijk van de configuratie van de beschikbaarheidszone die door uw exemplaar wordt gebruikt.

• Zone-redundant: U kunt de tolerantie van uw toepassing voor failover testen door een geforceerde failover te starten. Met een geforceerde failover kunt u een niet-gepland storingsscenario simuleren tijdens het uitvoeren van uw workload en de downtime van uw toepassing observeren. U wordt aangeraden simulaties uit te voeren in een niet-productieomgeving of op een rustige tijd. Zie Een geforceerde failover initiëren voor meer informatie.

• Per zone: Hoewel u geen storing van een volledige zone kunt simuleren, kunt u wel simuleren dat uw server niet beschikbaar is op een manier die vergelijkbaar is met een storing van een volledige zone. Zie Rekenkracht van een server stoppen voor meer informatie.

Tolerantie voor storingen in de hele regio

Azure Database for PostgreSQL ondersteunt leesreplica's in meerdere regio's, die u kunt gebruiken om een gesynchroniseerde kopie van uw database in een andere regio te onderhouden voor sneller herstel.

U kunt ook geografisch redundante back-ups in ondersteunde regio's gebruiken om herstel tussen regio's mogelijk te maken. Back-ups hebben echter meestal meer downtime en gegevensverlies dan replicatie. Zie Back-up en herstel voor meer informatie.

Leesreplica's in meerdere regio's

U kunt leesreplica's implementeren om uw databases te beschermen tegen storingen op regioniveau. Elke leesreplica is een afzonderlijke Azure Database for PostgreSQL-server. Wanneer u een leesreplica in een tweede Azure-regio plaatst, kan uw databaseserver tolerantie bieden voor een probleem in de hele regio. U kunt maximaal vijf leesreplica's implementeren, die optioneel in verschillende Azure-regio's kunnen zijn. PostgreSQL's fysieke replicatietechnologie werkt asynchroon bij het bijwerken van leesreplica's, waardoor ze achter kunnen lopen op de primaire. Leesreplica's tussen regio's kunnen desgewenst alleen-lezenworkloads leveren om de latentie voor wereldwijd gedistribueerde toepassingen te verminderen of leesverkeer van de primaire server te offloaden. Voor meer informatie over leesreplicafuncties en overwegingen, zie Leesreplica's.

Virtuele eindpunten bieden zowel lezen-schrijven- als alleen-lezen-eindpunten en leiden het verkeer automatisch om wanneer een replica wordt gepromoveerd, waardoor de downtime tijdens failover-gebeurtenissen wordt geminimaliseerd. We raden u ten zeerste aan virtuele eindpunten te gebruiken met leesreplica's in meerdere regio's om de tolerantie van toepassingen te verbeteren. Zie Virtuele eindpunten voor leesreplica's in Azure Database for PostgreSQL voor meer informatie.

Diagram met een toepassing bovenaan. Direct daaronder bevindt zich een kader met het label lees-/schrijfeindpunt. Er is een pijl-omlaag van de toepassing naar het eindpunt, die laat zien dat de toepassing eerst het databaseverkeer naar dit eindpunt verzendt. De onderste helft van het diagram is opgesplitst in twee grote gebieden. Aan de linkerkant bevindt zich de primaire regio. In die regio bevindt zich een vak met het label primaire server en in het vak de servicenaam Azure Database for PostgreSQL server. Aan de rechterkant bevindt zich de secundaire regio. In die regio staat een overeenkomend servervak met het label 'leesreplica gepromoveerde primaire server', ook met het label 'Azure Database for PostgreSQL-server'. Er loopt een pijl van het lees-/schrijfeindpunt naar de primaire server. Een gestippelde horizontale pijl met het label asynchrone replicatie loopt van de primaire server aan de linkerkant naar de server in de secundaire regio aan de rechterkant, waarmee wordt aangegeven dat gegevenswijzigingen van de primaire server naar de replica worden gekopieerd.

Als uw primaire regio mislukt, kunt u een promotie activeren zodat uw secundaire replica de primaire replica wordt. Afhankelijk van de manier waarop u leesreplica's gebruikt, kunnen verschillende typen failover geschikt zijn. Wanneer u leesreplica's gebruikt om veerkracht te bieden bij storing in een regio, gebruikt u doorgaans de aanpak om te promoveren naar de primaire server, waarmee uw virtuele eindpunt wordt bijgewerkt. Tijdens een storing in een regio moet u een geforceerde promotie uitvoeren, wat kan leiden tot gegevensverlies voor eventuele niet-gerepliceerde gegevens. In geplande scenario's waarin de primaire regio in orde is, kunt u ervoor kiezen om een geplande promotie uit te voeren om gegevensverlies te voorkomen. Zie Leesreplica's promoveren in Azure Database for PostgreSQL voor meer informatie.

Diagram waarop bovenaan een applicatie te zien is die gegevens verzendt via een lees-/schrijfeindpunt. De onderste helft van het diagram is opgesplitst in twee grote gebieden. Aan de linkerkant bevindt zich de primaire regio. In die regio bevindt zich een vak met het label primaire server en in het vak de servicenaam Azure Database for PostgreSQL server. Er is een x boven de primaire regio, waarmee wordt aangegeven dat deze niet meer actief is. Aan de rechterkant bevindt zich de secundaire regio. Binnen die regio bevindt zich een overeenkomstig servervak met het label 'leesreplica gepromoveerde primaire server', ook met het label 'Azure Database for PostgreSQL-server'. Een pijl loopt van het lees-/schrijfeindpunt naar de secundaire regio. Een gestreepte horizontale pijl met het label asynchrone replicatie die wordt uitgevoerd van de primaire regio naar de secundaire regio, wordt gedekt door een x, waarmee wordt aangegeven dat de replicatie niet meer actief is.

Opmerking

In deze sectie vindt u een overzicht van enkele belangrijke informatie over hoe leesreplica's tolerantie voor storingen in de hele regio kunnen ondersteunen. U kunt ook leesreplica's gebruiken om de prestaties te verbeteren en om grote, geografisch gedistribueerde gebruikersgroepen te ondersteunen. Zie Leesreplica's voor meer informatie.

Requirements

• Regioondersteuning: U kunt leesreplica's in meerdere regio's maken in elke regio die ondersteuning biedt voor Azure Database for PostgreSQL. U bent niet beperkt tot Azure gekoppelde regio's.

• Rekenlagen: De rekenlagen General Purpose en Memory Optimized ondersteunen leesreplica's. De laag Burstable biedt geen ondersteuning voor leesreplica's.

Overwegingen

• Configuratieverschillen: Leesreplica's nemen mogelijk niet alle configuratie-instellingen van de primaire server over. Plan om de benodigde instellingen te configureren na een failover. Uw primaire server en replica's moeten symmetrisch zijn, wat betekent dat ze dezelfde lagen, opslaggrootten en waarden moeten hebben voor sommige instellingen. Tijdens regiofouten kan worden afgezien van de symmetrische serververeiste voor geforceerde promoties, maar het is een goede gewoonte om waar mogelijk symmetrische configuratie te hebben om onverwachte problemen te voorkomen. Zie Configuratiebeheer voor meer informatie.

• Replicatievertraging bewaken: Voor het asynchrone replicatieproces is een replicatievertraging vereist, die kan variëren, afhankelijk van veel factoren. Wanneer de replicatievertraging hoog is, kan uw server problemen ondervinden. Het is belangrijk om de replicatievertraging te bewaken, zodat u problemen kunt beperken voordat ze escaleren. Zie voor meer informatie Replicatie bewaken.

• Hoge beschikbaarheid: Leesreplica's kunnen geen hoge beschikbaarheid ingeschakeld hebben, en wanneer ze worden gepromoveerd, hebben ze eveneens geen hoge beschikbaarheid. U bent verantwoordelijk voor het configureren van hoge beschikbaarheid nadat u een replica hebt gepromoot.

Zie Overwegingen voor andere factoren over het promotieproces waarmee u rekening moet houden.

Cost

Voor leesreplica's worden reken- en opslagkosten in rekening gebracht, plus kosten voor gegevensoverdracht tussen regio's voor replicatie. Raadpleeg Azure Database for PostgreSQL prijzen en bandbreedteprijzen voor gedetailleerde prijsinformatie.

Ondersteuning voor meerdere regio's configureren

• Een leesreplica maken: Zie Een leesreplica maken voor meer informatie over het maken van een leesreplica. U kunt replica's configureren nadat u de primaire server hebt gemaakt, zolang de primaire server wordt uitgevoerd en toegankelijk is.

  Zie Virtuele eindpunten maken om een virtueel eindpunt te maken.

• Een leesreplica verwijderen: Zie Een leesreplica verwijderen voor meer informatie over hoe u een leesreplica kunt verwijderen.

Gedrag wanneer alle regio's in orde zijn

In deze sectie wordt beschreven wat u kunt verwachten wanneer uw server is geconfigureerd met een leesreplica in een andere regio en een virtueel eindpunt, en alle regio's zijn operationeel:

• Verkeersroutering tussen regio's: Bij normale bewerkingen leidt uw virtuele eindpunt verkeer voor het eindpunt voor lezen/schrijven naar de primaire server in de primaire regio. Als u ook het alleen-lezen eindpunt van het virtuele eindpunt gebruikt, wordt verkeer doorgestuurd naar de replica die u configureert.

• Gegevensreplicatie tussen regio's: Leesreplica's in meerdere regio's maken gebruik van asynchrone replicatie om de impact op de prestaties van de primaire server te minimaliseren. De hoeveelheid replicatievertraging is afhankelijk van veel factoren, waaronder de schrijfbelasting en de latentie tussen de primaire server en replica's. Replicatievertraging is doorgaans ten minste enkele minuten, maar kan langer zijn. Zie voor meer informatie Replicatie bewaken.

Gedrag tijdens een regiofout

In deze sectie wordt beschreven wat u kunt verwachten wanneer uw server is geconfigureerd met een leesreplica in een andere regio en een virtueel eindpunt, en er is een storing in de primaire regio:

• Detectie en reactie: U bent verantwoordelijk voor het detecteren van een uitval in de primaire regio en het handmatig promoveren van een read replica om de nieuwe primaire server te worden. Tijdens een regiostoring moet u een geforceerde promotie uitvoeren, wat resulteert in het verlies van niet-gerepliceerde gegevens.

  Belangrijk

  U bent verantwoordelijk voor het activeren van promotie. Azure promoveert leesreplica's niet automatisch, zelfs als er een regiofout opgetreden is.

  Zie Schakel de leesreplica over naar primair voor gedetailleerde stappen voor het initiëren van een promotie.

• Kennisgeving: Microsoft informeert u niet automatisch wanneer een regio niet beschikbaar is. U kunt Azure Service Health echter gebruiken om inzicht te hebben in de algehele status van de service, inclusief eventuele regiofouten, en u kunt Service Health-waarschuwingen instellen om u op de hoogte te stellen van problemen.

• Actieve aanvragen: Het promotieproces verwijdert alle actieve verbindingen met de primaire regio. Nadat het promotieproces is voltooid, moeten toepassingen opnieuw verbinding maken met de gepromoveerde replica.

• Verwachte gegevensverlies: Tijdens een regiostoring moet u een geforceerde promotie uitvoeren, wat resulteert in het permanente verlies van niet-gerepliceerde gegevens.

  De hoeveelheid gegevensverlies is afhankelijk van de replicatievertraging op het moment van de storing. Replicatievertraging is doorgaans ten minste enkele minuten, maar kan langer zijn. Zie voor meer informatie Replicatie bewaken.

• Verwachte downtime: Geforceerde promotie wordt doorgaans binnen 1-3 minuten na activering voltooid. Toepassingen moeten mogelijk ook opnieuw verbinding maken met het juiste eindpunt. Virtuele eindpunten worden bijgewerkt als onderdeel van het geforceerde promotieproces. Toepassingen moeten de time-to-live (TTL) van de DNS-records van het eindpunt respecteren om ervoor te zorgen dat ze snel opnieuw verbinding maken met de juiste replica nadat de promotie is voltooid.

• Verkeer omleiden: Het virtuele eindpunt voor de server leidt toepassingsverkeer automatisch om naar de nieuwe primaire replica.

  Opmerking

  Nadat een leesreplica is gepromoveerd tot primaire server, is de configuratie voor hoge beschikbaarheid niet ingeschakeld. U moet configuratie met hoge beschikbaarheid handmatig inschakelen of toevoegen aan uw eigen automatiseringsprocessen.

Herstel van de regio

Wanneer u virtuele eindpunten gebruikt nadat de primaire regio is hersteld, wordt de oude primaire server automatisch geconfigureerd als een leesreplica. U kunt een andere promotie uitvoeren om de primaire bewerkingen te retourneren naar de primaire regio van uw voorkeur.

Test voor regiofouten

Test regelmatig de procedures voor het promoveren van leesreplica's om ervoor te zorgen dat uw processen correct werken en dat de mogelijkheden voldoen aan uw vereisten voor hersteltijddoelstelling (RTO) en herstelpuntdoelstelling (RPO).

U kunt op elk gewenst moment een leesreplica promoveren tot de primaire server, zelfs wanneer alle regio's optimaal functioneren. Voor testen:

• U kunt geforceerde promotietests uitvoeren. U wordt aangeraden deze tests uit te voeren in een niet-productieomgeving, omdat dit kan leiden tot gegevensverlies. Geforceerde promotietests helpen bij het simuleren van het gedrag dat u tijdens een regiostoring ziet.
• Voor gepland onderhoud of testscenario's waarbij u gegevensverlies wilt voorkomen, gebruikt u in plaats daarvan een geplande promotie. Geplande promotie volgt echter een ander proces dan de promotie tijdens een regiostoring, zodat deze mogelijk niet overeenkomt met het gedrag tijdens een echte regio-storing.

Zie Switch over read replica to primary voor stapsgewijze instructies.

Voer regelmatig volledige herstelanalyses uit als onderdeel van uw strategie voor herstel na noodgevallen. Deze oefeningen moeten gegevensvalidatie, testen van toepassingsfunctionaliteit en gedocumenteerde terugdraaiprocedures omvatten.

Backups en herstel

Azure Database for PostgreSQL maakt automatisch een back-up van uw gegevens. Deze back-ups bieden herstelmogelijkheden voor een bepaald tijdstip en helpen u te beschermen tegen onbedoelde beschadiging en verwijdering van gegevens. Microsoft de back-ups volledig beheert. Ze onderbreken de beschikbaarheid van de server niet en bevatten zowel volledige back-ups als back-ups van transactielogboeken.

• Back-upopslag: Als u de server in een regio met beschikbaarheidszones implementeert, slaat de service back-ups op in zone-redundante opslag (ZRS), ongeacht de configuratie van de server met hoge beschikbaarheid. Voor servers die zijn geïmplementeerd in regio's zonder beschikbaarheidszones, slaat de service back-ups op in lokaal redundante opslag (LRS).

  In Azure-regio’s met regioparen kunt u geo-redundante back-upopslag configureren bij het maken van de server om back-ups te repliceren naar de gekoppelde Azure-regio voor extra bescherming tegen regionale storingen. De service repliceert back-ups asynchroon.

  De standaardretentieperiode voor back-ups is zeven dagen, maar u kunt de retentie uitbreiden tot 35 dagen. U kunt Azure Backup ook gebruiken voor langetermijnopslag van handmatige back-ups voor maximaal 10 jaar. Alle back-ups worden versleuteld.

• Herstellen: Met herstel naar een bepaald tijdstip kunt u uw database herstellen naar elk moment binnen de bewaarperiode voor back-ups. Het herstelproces maakt een nieuwe databaseserver met een nieuwe servernaam die door de gebruiker is verstrekt. U kunt de nieuwe server gebruiken as-is of gegevens kopiëren.

  Wanneer u een geografisch redundante back-up herstelt, maakt u een nieuwe server in de gekoppelde regio.

  Deze mogelijkheid is handig voor het herstellen van onbedoelde gegevenswijzigingen, toepassingsfouten of testscenario's.

Voor de meeste oplossingen hoeft u niet uitsluitend te vertrouwen op back-ups. Gebruik in plaats daarvan de andere mogelijkheden die in deze handleiding worden beschreven om uw tolerantievereisten te ondersteunen. Back-ups beschermen echter tegen enkele risico's die andere benaderingen niet opleveren. Zie Wat zijn redundantie, replicatie en back-up? voor meer informatie.

Zie Back-up en herstel in Azure Database for PostgreSQL voor meer informatie.

Tolerantie voor serviceonderhoud

Azure Database for PostgreSQL verwerkt automatisch kritieke onderhoudstaken, waaronder het patchen van de onderliggende hardware, het besturingssysteem en de database-engine. De service bevat beveiligingsupdates, software-updates en secundaire versie-upgrades als onderdeel van gepland onderhoud.

Volg deze aanbevelingen om ervoor te zorgen dat uw server beschikbaar blijft tijdens onderhoudsvensters:

• Hoge beschikbaarheid inschakelen: Tijdens het onderhoud moet de server mogelijk opnieuw worden opgestart als onderdeel van het updateproces. Als u hoge beschikbaarheid inschakelt, gebruiken onderhoudsbewerkingen doorgaans rolling updates om downtime te minimaliseren. Eerst vinden periodieke onderhoudsactiviteiten, zoals kleine versie-upgrades, plaats op de stand-byreplica. Om downtime te verminderen, wordt het standbyknooppunt tot primair knooppunt gepromoveerd, zodat workloads op het gepromoveerde knooppunt kunnen blijven draaien terwijl onderhoudstaken op het andere knooppunt worden uitgevoerd. Deze volgorde is van toepassing of uw server zone-redundante of zonegebonden hoge beschikbaarheid gebruikt.

  Voor servers zonder hoge beschikbaarheid, verwacht korte uitvaltijd tijdens onderhoudsbewerkingen. Wanneer hoge beschikbaarheid is ingeschakeld, worden onderhoudsbewerkingen doorgaans voltooid met minimale of geen downtime.

• Aangepaste onderhoudsvensters configureren: U kunt het onderhoudsschema zo configureren dat het systeem wordt beheerd of een aangepast onderhoudsvenster definieert om de impact op uw bedrijfsactiviteiten te minimaliseren. Plan onderhoud tijdens perioden met een lage activiteit om de impact van het bedrijf te minimaliseren. Zie Onderhoud plannen voor meer informatie.

• Logica voor opnieuw proberen implementeren: Zorg ervoor dat uw toepassingen korte connectiviteitsonderbrekingen kunnen verwerken die kunnen optreden tijdens het opnieuw opstarten van onderhoud. Als u uw toepassingen tolerant wilt maken voor dit soort problemen, raadpleegt u Richtlijnen voor tolerantie voor tijdelijke fouten .

Diensteniveau-overeenkomst

De SLA (Service Level Agreement) voor Azure-services beschrijft de verwachte beschikbaarheid van elke service en de voorwaarden waaraan uw oplossing moet voldoen om die beschikbaarheidsverwachting te bereiken. Zie SLA's voor onlineservices voor meer informatie.

Azure Database for PostgreSQL biedt verschillende beschikbaarheidS-SLA's, afhankelijk van de configuratie van de server:

• Servers die zijn geconfigureerd met zone-redundante hoge beschikbaarheid bieden een SLA voor uptime van 99,99%.
• Servers die zijn geconfigureerd met zonegebonden hoge beschikbaarheid bieden een SLA voor uptime van 99,95%.
• Servers die zonder hoge beschikbaarheid zijn geconfigureerd, bieden een SLA voor uptime van 99,9%.

Verwante inhoud

• Azure-betrouwbaarheid
• Architecturale best practice voor Azure Database voor PostgreSQL
• Overzicht van bedrijfscontinuïteit met Azure Database for PostgreSQL
• Herstel na noodgevallen in Azure Database for PostgreSQL
• Terraform-scripts voor het implementeren van principes voor tolerantie en herstelbaarheid