Betrouwbaarheid in Azure Database for PostgreSQL

Azure Database for PostgreSQL is een volledig beheerde databaseservice die is ontworpen om u gedetailleerde controle en flexibiliteit te bieden over 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 tolerant maakt voor verschillende mogelijke storingen en problemen, waaronder tijdelijke fouten, storingen in de beschikbaarheidszone, regiostoringen en serviceonderhoud. Het beschrijft ook hoe u back-ups kunt gebruiken om te herstellen van andere soorten problemen en benadrukt belangrijke informatie over de Service Level Agreement (SLA) van Azure Database voor PostgreSQL.

Aanbevelingen voor productie-implementatie

Zie de aanbevolen richtlijnen voor de architectuur voor Azure Database for PostgreSQL in het Azure Well-Architected Framework om te voldoen aan de betrouwbaarheidsvereisten voor uw oplossing en hoe 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 om uw databaseserver te ondersteunen. U implementeert een of meer databases op de server.

Servers kunnen worden geïmplementeerd in meerdere rekenlagen: Burstable, General Purpose en Memory Optimized, die elk zijn geoptimaliseerd voor verschillende soorten workloads. In sommige Azure-regio's kunt u servers implementeren met Azure Confidential Computing.

Zie Wat is Azure Database for PostgreSQL?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, terwijl gegevensbestanden worden opgeslagen in Azure Storage, waarbij drie lokaal redundante synchrone kopieën van de databasebestanden worden onderhouden om de duurzaamheid van gegevens te garanderen.

• Hoge beschikbaarheid: U kunt eventueel een configuratie voor 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. Gegevenswijzigingen op de primaire server worden synchroon gerepliceerd 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 afhandelen. Voor een hogere tolerantie kunt u de servers over beschikbaarheidszones verdelen.

  

  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 zijn twee soorten 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.

  Bewerkingen zoals stoppen, starten en opnieuw opstarten worden tegelijkertijd uitgevoerd op zowel de primaire server als stand-bydatabaseservers. Geplande gebeurtenissen, zoals het schalen van computing en schaalopslag, 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.

U kunt uw type ondersteuning voor beschikbaarheidszones selecteren via de configuratie voor hoge beschikbaarheid . Als u hoge beschikbaarheid inschakelt, wordt naast uw primaire server een stand-byserver geïmplementeerd. 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.

Gegevensbestanden en logboeken voor write-ahead (WAL's) worden opgeslagen op premium beheerde schijven binnen elke beschikbaarheidszone, met lokaal redundante opslag (LRS) waarmee 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 vergelijkbare reken-, opslag- en netwerkconfiguratie als 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.

  

  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 u ook bij het verminderen van de downtime van toepassingen tijdens geplande en ongeplande downtimegebeurtenissen. Het beschermt echter niet tegen een storing in die zone.

  

  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 en dus is de enige configuratie voor hoge beschikbaarheid die u kunt selecteren 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 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.

  Omdat de servers zich in dezelfde zone bevinden, kan dit de schrijflatentie verminderen voor toepassingen die u in dezelfde zone implementeert.

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: De ondersteuning van Azure Database for PostgreSQL voor configuraties van beschikbaarheidszones verschilt tussen 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 die regio.

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

  Prijscategorie	Zone-redundant	Zonegebonden (dezelfde zone)
  Burstbaar	Niet ondersteund	Ondersteund
  Algemeen gebruik	Ondersteund	Ondersteund
  Geoptimaliseerd geheugen	Ondersteund	Ondersteund

• Servicelaag: Zoneredundantie vereist de lagen Algemeen gebruik of Geoptimaliseerd voor geheugen.

  Zonegebonden implementaties (dezelfde zone) worden ondersteund voor alle prijscategorieën.

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 de stand-byserver gemaakt en 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 de beschikbaarheidszone voor een server wilt configureren, configureert u de instellingen voor hoge beschikbaarheid.

• Een zoneredundante server maken: Voor meer informatie over het maken van een server met hoge beschikbaarheid en zoneredundantie, zie Quickstart: Een Azure Database voor PostgreSQL maken in de Azure Portal.

• Wijzig de configuratie van de beschikbaarheidszone voor bestaande servers: U kunt de configuratie van de beschikbaarheidszone voor bestaande servers wijzigen 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 nadat deze zijn gemaakt. U moet de server opnieuw maken.

  Aanbeveling

  Het is een goed idee om 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 servers zijn geconfigureerd 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 actieve/passieve configuratie waarbij alle databaseverbindingen en query's worden verwerkt door de primaire server in de primaire beschikbaarheidszone. De stand-by-server verwerkt geen clientverkeer tijdens normale operaties.

• Replicatie van gegevens in meerdere zones: Wijzigingen in gegevens worden synchroon tussen de primaire en stand-byservers gerepliceerd. Transacties worden pas als voltooid beschouwd als de primaire en stand-byservers de schrijfbewerking bevestigen.

  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. 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 en voor de meeste toepassingen is dit te verwaarlozen.

  • 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 standby dus 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 servers zijn geconfigureerd met ondersteuning voor hoge beschikbaarheid en beschikbaarheidszones en er een storing in de beschikbaarheidszone is.

• 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.

  In het geval van een zonefout is 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 Statustypen met hoge beschikbaarheid. 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 (HA) 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 helpt de uptime en prestaties van uw database te behouden.

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

• 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. De dienst verplaatst de primaire rol niet automatisch terug naar de oorspronkelijke zone om onnodige verstoringen te voorkomen. 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. We raden u aan simulaties uit te voeren in een niet-productieomgeving of op een rustige tijd. Zie Een geforceerde failover initiëren voor meer informatie.

• Zonal: Hoewel u geen volledige zonestoring kunt simuleren, kunt u simuleren dat uw server niet beschikbaar is op een vergelijkbare manier als wat er gebeurt tijdens een zonestoring. 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.

Als uw primaire regio mislukt, kunt u een promotie activeren zodat uw secundaire replica de primaire replica wordt. Er zijn verschillende typen failovers die u kunt activeren, afhankelijk van hoe u leesreplica’s gebruikt. 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.

Opmerking

In deze sectie vindt u een overzicht van enkele belangrijke informatie over hoe leesreplica's tolerantie kunnen ondersteunen bij storingen in de hele regio. 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 gekoppelde Azure-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 na de failover te configureren. 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 een aantal factoren. Wanneer de replicatievertraging erg 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 Leesreplica's promoveren in Azure Database for PostgreSQL - Overwegingen voor aanvullende factoren die van toepassing zijn op het promotieproces.

Cost

Read-replica's brengen reken- en opslagkosten in rekening, evenals kosten tussen regio's voor gegevensoverdracht 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. Replica's kunnen worden geconfigureerd nadat de primaire server is 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 omgeleid 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 een aantal factoren, waaronder de schrijfbelasting en de latentie tussen de primaire server en replica's. Replicatievertraging duurt doorgaans minstens enkele minuten, maar kan veel langer zijn. Zie Replicatie bewaken voor meer informatie.

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: Alle actieve verbindingen met de primaire regio worden verwijderd. Toepassingen moeten opnieuw verbinding maken met de gepromoveerde replica nadat het promotieproces is voltooid.

• 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 duurt doorgaans minstens enkele minuten, maar kan veel langer zijn. Zie Replicatie bewaken voor meer informatie.

• 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 de 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 promotieprocedures voor leesreplica's om ervoor te zorgen dat uw processen geldig zijn en of de mogelijkheden voldoen aan uw RTO- en RPO-vereisten.

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. We raden u aan 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. Houd er rekening mee dat geplande promotie een ander proces volgt dan promotie tijdens een storing in de regio.

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 voert automatisch back-ups uit die herstelmogelijkheden voor een bepaald tijdstip bieden en helpen u te beschermen tegen onbedoelde beschadiging en verwijdering van gegevens. Back-ups worden volledig beheerd door Microsoft, onderbreken de beschikbaarheid van de server niet en bevatten zowel volledige back-ups als back-ups van transactielogboeken.

• Back-upopslag: Als de server is geconfigureerd met zone-redundante hoge beschikbaarheid, worden back-ups opgeslagen in zone-redundante opslag (ZRS). Voor servers die zijn geconfigureerd zonder hoge beschikbaarheid of met zonegebonden hoge beschikbaarheid (één zone), worden back-ups opgeslagen in lokaal redundante opslag (LRS).

  In gepaarde Azure-regio's kunt u geo-redundante (GRS) back-upopslag configureren tijdens het maken van de server om back-ups naar de gekoppelde Azure-regio te repliceren voor extra beveiliging tegen regiofouten. Back-ups worden asynchroon gerepliceerd.

  De standaardretentieperiode voor back-ups is 7 dagen, met de optie voor het verlengen van de retentie 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. Tijdens het herstelproces wordt een nieuwe databaseserver gemaakt met een nieuwe servernaam die door de gebruiker is verstrekt. Vervolgens kunt u as-is gebruiken 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 hebt ingeschakeld, gebruiken onderhoudsbewerkingen doorgaans rolling updates om downtime te minimaliseren. Eerst vinden periodieke onderhoudsactiviteiten, zoals kleine versie-upgrades, plaats op de stand-byreplica. 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. 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 door 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 op basis van de configuratie van de server:

• Servers die zijn geconfigureerd met zone-redundante hoge beschikbaarheid.
• Servers die zijn geconfigureerd met zonegebonden hoge beschikbaarheid (één zone).
• Servers die zijn geconfigureerd zonder hoge beschikbaarheid.

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
• Azure Database for PostgreSQL Resiliency Solution Accelerator : Terraform-scripts voor het implementeren van veel van de principes voor tolerantie en herstelbaarheid die in dit artikel worden beschreven.