Notitie
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen u aan te melden of de directory te wijzigen.
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen de mappen te wijzigen.
Van toepassing op:
Azure Database for PostgreSQL - Flexible Server
In dit artikel wordt hoge beschikbaarheid in Azure Database for PostgreSQL - Flexible Server 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 - Flexible Server biedt ondersteuning voor hoge beschikbaarheid door fysiek gescheiden primaire en stand-byreplica's in te richten, 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 in het geval van 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 beschikbaarheidszone
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.
Zie Wat zijn beschikbaarheidszones? voor meer informatie.
Azure Database for PostgreSQL - Flexible Server 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 vereist dat u toepassingsredundantie tussen zones configureert. 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 erg 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, a.k.a WAL) 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 rekeneenheid-laag.
- 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. In het geval van een verstoring van de primaire server wordt er automatisch een failover uitgevoerd naar de stand-by-replica.
De zonegebonden implementatieoptie is beschikbaar in alle Azure-regio's waar u Flexibele server kunt implementeren.
Notitie
Zowel zonale als zone-redundante deployatiemodellen gedragen zich architecturaal hetzelfde. Verschillende discussies in de volgende secties zijn van toepassing op beide, tenzij anders wordt beschreven.
Functies voor hoge beschikbaarheid
Een stand-byreplica wordt geïmplementeerd in dezelfde VM-configuratie, waaronder vCores, opslag, 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 worden automatische back-ups periodiek uitgevoerd vanaf de primaire databaseserver. Tegelijkertijd worden de transactielogboeken continu gearchiveerd in de back-up opslag vanuit de stand-by replica. 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.
Mogelijkheid om de server opnieuw op te starten om eventuele wijzigingen in statische serverparameters te detecteren.
Periodieke onderhoudsactiviteiten zoals kleine versie-upgrades vinden eerst plaats op de stand-by en, om downtime te verminderen, wordt de stand-by gepromoveerd tot primair zodat workloads kunnen blijven draaien, terwijl de onderhoudstaken op het resterende knooppunt worden toegepast.
Notitie
Om ervoor te zorgen dat High-Availability (HA) correct functioneert, moet u de waarden voor de max_replication_slots serverparameter max_wal_senders configureren. High-Availability vereist 4 van elk om failovers en naadloze upgrades te verwerken. Voor een HA-installatie met 5 leesreplica's en 12 logische replicatieslots, moet u zowel de parameterwaarden max_replication_slots als max_wal_senders instellen op 21. Dit komt doordat voor elke leesreplica en logische replicatieslot één van elk is vereist, plus de 4 die nodig zijn om High-Availability goed te laten functioneren. Raadpleeg de max_replication_slots voor meer informatie over max_wal_senders en parameters.
Monitoren van de gezondheid van hoge beschikbaarheid
Statuscontrole met hoge beschikbaarheid (HA) in Azure Database for PostgreSQL - Flexible Server biedt een doorlopend overzicht van de status en gereedheid van instanties met hoge beschikbaarheid. Deze bewakingsfunctie maakt gebruik van het RHC-framework (Resource Health Check) van Azure om problemen te detecteren en te waarschuwen die van invloed kunnen zijn op de failovergereedheid of algemene beschikbaarheid van uw database. Door belangrijke metrische gegevens te beoordelen, zoals verbindingsstatus, failoverstatus en de gezondheid van gegevensreplicatie, maakt het bewaken van de HA-gezondheidsstatus proactieve probleemoplossing mogelijk en helpt het bij het behouden van de uptime en prestaties van uw database.
Klanten kunnen HA gezondheidsstatus monitoring gebruiken 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.
- Configureer waarschuwingen voor tijdige meldingen over eventuele wijzigingen in de hoge beschikbaarheidsstatus, zodat er onmiddellijk actie wordt ondernomen 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.
Voor een gedetailleerde handleiding over het configureren en interpreteren van statusstatussen voor hoge beschikbaarheid raadpleegt u het hoofdartikel over de statusbewaking van hoge beschikbaarheid (HA) voor Azure Database for PostgreSQL - Flexible Server.
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.
Standbyreplica kan niet worden gebruikt voor leesopdrachten.
Afhankelijk van de workload en activiteit op de primaire server kan het failoverproces langer dan 120 seconden duren doordat het herstel dat nodig is bij de stand-byreplica voordat promotie kan plaatsvinden.
De stand-byserver herstelt doorgaans WAL-bestanden op 40 MB/s. Voor grotere SKU's 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.
Het configureren van een extra stand-by wordt niet ondersteund.
Het configureren van door de klant geïnitieerde beheertaken kan niet worden gepland tijdens het beheerde onderhoudsvenster.
Geplande gebeurtenissen zoals schaalcomputing en schaalopslag vindt eerst plaats op de stand-by en vervolgens op de primaire server. De server voert momenteel geen failover uit voor deze geplande bewerkingen.
Als logische decodering of logische replicatie is geconfigureerd met een voor beschikbaarheid geconfigureerde flexibele server, worden in het geval van een failover naar de stand-byserver de logische replicatieslots niet gekopieerd naar de stand-byserver. Als u logische replicatieslots wilt onderhouden en ervoor wilt zorgen dat de gegevensconsistentie na een failover wordt behouden, wordt u aangeraden de PG Failover Slots-extensie te gebruiken. Raadpleeg de documentatie voor meer informatie over het inschakelen van deze extensie.
Het configureren van beschikbaarheidszones tussen privé (VNET) en openbare toegang met privé-eindpunten wordt niet ondersteund. U moet beschikbaarheidszones configureren binnen een VNET (verspreid over beschikbaarheidszones binnen een regio) of openbare toegang met privé-eindpunten.
Beschikbaarheidszones worden slechts binnen één regio geconfigureerd. Beschikbaarheidszones kunnen niet worden geconfigureerd in verschillende regio's.
Dienstenniveau-overeenkomst (SLA)
Zonegebonden model biedt een uptime SLA van 99,95%.
Zoneredundantiemodel biedt een SLA voor uptime van 99,99%.
Een Azure Database for PostgreSQL - Flexibele server maken waarvoor beschikbaarheidszone is ingeschakeld
Voor meer informatie over het maken van een Azure Database for PostgreSQL - Flexible Server voor hoge beschikbaarheid met beschikbaarheidszones, raadpleeg Quickstart: Een Azure Database voor PostgreSQL - Flexible Server maken in de 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 zone-redundante implementatiemodellen.
Onderdelen en werkstroom voor hoge beschikbaarheid
Transactievoltooiing
Schrijf- en doorvoerbewerkingen die door transacties worden geactiveerd, worden eerst geregistreerd bij de WAL op de primaire server. Deze worden vervolgens gestreamd naar de stand-byserver met behulp van het Postgres-streamingprotocol. Zodra de logbestanden zijn opgeslagen op de opslag van de standby-server, ontvangt de primaire server bevestiging van schrijfvoltooiing. Alleen dan wordt de toepassing bevestigd dat de transactie is doorgevoerd. Deze extra communicatiecyclus veroorzaakt meer latentie in uw toepassing. Het effectpercentage is afhankelijk van de toepassing. Dit bevestigingsproces wacht niet totdat de logbestanden zijn toegepast op de standby-server. De stand-byserver bevindt zich permanent in de herstelmodus totdat deze wordt gepromoveerd.
Gezondheidscontrole
Flexibele bewaking van serverstatus controleert periodiek zowel de status van de primaire server als de back-up server. Wanneer bij gezondheidsbewaking na meerdere pings wordt gedetecteerd dat een primaire server niet beschikbaar is, initieert de service automatisch een failover naar de standbyserver. Het algoritme voor statuscontrole is gebaseerd op meerdere gegevenspunten om fout-positieve situaties te voorkomen.
Failovermodussen
Flexibele server ondersteunt twee failovermodi, geplande failover en niet-geplande failover. Wanneer de replicatie in beide modi is verbroken, voert de stand-byserver het herstel uit voordat deze als primaire server wordt gepromoveerd en wordt geopend voor lezen/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
De status van primaire en stand-byservers wordt continu bewaakt en er worden passende acties ondernomen om problemen op te lossen, waaronder het activeren van een failover naar de stand-byserver. De onderstaande tabel bevat de mogelijke statussen voor hoge beschikbaarheid:
| Status | Beschrijving |
|---|---|
| Initialiseren | Tijdens het maken van een nieuwe stand-byserver. |
| Gegevens repliceren | Nadat de stand-by is gemaakt, haalt het de primaire in. |
| Gezond | Replicatie verkeert in een stabiele en gezonde toestand. |
| Overdragen bij Falen | De databaseserver is bezig met het uitvoeren van een failover naar de stand-by. |
| Stand-by verwijderen | Tijdens het verwijderen van de stand-byserver. |
| Niet ingeschakeld | Hoge beschikbaarheid is niet ingeschakeld. |
Notitie
U kunt hoge beschikbaarheid inschakelen tijdens het maken van de server of op een later tijdstip. Als u hoge beschikbaarheid inschakelt of uitschakelt tijdens de fase na het maken, wordt aanbevolen om te werken wanneer de primaire serveractiviteit laag is.
Onverander gebleven bewerkingen
PostgreSQL-clienttoepassingen zijn verbonden met de primaire server met behulp van de databaseservernaam. Leesbewerkingen van toepassingen worden rechtstreeks vanaf de primaire server geleverd. Tegelijkertijd worden doorvoeringen en schrijfbewerkingen alleen aan de toepassing bevestigd nadat de logboekgegevens zijn opgeslagen op zowel de primaire server als de stand-byreplica. 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.
- Clients maken verbinding met de flexibele server en voeren schrijfbewerkingen uit.
- Wijzigingen worden gerepliceerd naar de standbysite.
- Primair ontvangt een bevestiging.
- Schrijfbewerkingen/vastleggingen worden bevestigd.
Herstel van servers met hoge beschikbaarheid naar een specifiek tijdstip
Voor flexibele servers die zijn geconfigureerd met hoge beschikbaarheid, worden logboekgegevens in realtime gerepliceerd 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 dus geen stand-by gebruiken om dergelijke logische fouten te herstellen. Als u dergelijke fouten wilt herstellen, moet u een herstel naar een bepaald tijdstip uitvoeren vanuit de back-up. Met de functie voor herstel naar een bepaald tijdstip van een flexibele server kunt u herstellen naar de tijd 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 enkele gebruiksvoorbeelden:
U kunt de herstelde server gebruiken voor productie en kunt optioneel hoge beschikbaarheid inschakelen met een stand-by replica in dezelfde zone of een andere zone in 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.
Ondersteuning voor failover
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 deze bewerkingen zijn geconfigureerd in hoge beschikbaarheid, worden deze bewerkingen eerst toegepast op de stand-byreplica terwijl de toepassingen toegang blijven krijgen tot de primaire server. Zodra de stand-byreplica is bijgewerkt, worden primaire serververbindingen verwijderd en wordt een failover geactiveerd, waardoor de stand-byreplica wordt geactiveerd als de primaire replica met dezelfde databaseservernaam. Clienttoepassingen moeten opnieuw verbinding maken met dezelfde databaseservernaam op de nieuwe primaire server en kunnen hun bewerkingen hervatten. Er wordt een nieuwe stand-byserver gemaakt in dezelfde zone als de oude primaire server.
Voor andere door de gebruiker geïnitieerde bewerkingen, zoals scale-compute of scale-storage, worden de wijzigingen eerst toegepast op de stand-by, gevolgd door de primaire bewerking. Op dit moment wordt er voor de service geen failover-overschakeling uitgevoerd naar de stand-byserver. Daarom ondervinden apps tijdens het uitvoeren van de schaalbewerking op de primaire server een korte downtime.
U kunt deze functie ook gebruiken om een failover uit te voeren naar de stand-byserver met verminderde downtime. Uw primaire database 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, wordt de stand-byserver eerst voorbereid om ervoor te zorgen dat hij is bijgewerkt met recente transacties, zodat de toepassing lees- en schrijfoperaties kan blijven uitvoeren. De stand-by wordt vervolgens gepromoveerd en de verbindingen met het primaire systeem worden verbroken. Uw toepassing kan blijven schrijven naar de primaire server terwijl er op de achtergrond een nieuwe stand-byserver wordt ingesteld. Hier volgen de stappen voor geplande failover:
| Stap | Beschrijving | Verwachte downtime van de app? |
|---|---|---|
| 1 | Wacht totdat de standbyserver gelijk is geworden aan de primaire server. | Nee |
| 2 | Het interne bewakingssysteem initieert de failoverwerkstroom. | Nee |
| 3 | Schrijfbewerkingen van toepassingen worden geblokkeerd wanneer de stand-byserver zich dicht bij het primaire logboekreeksnummer (LSN) bevindt. | Ja |
| 4 | Stand-byserver wordt gepromoveerd tot een onafhankelijke server. | Ja |
| 5 | DNS-record wordt bijgewerkt met het IP-adres van de nieuwe stand-byserver. | Ja |
| 6 | Toepassing om opnieuw verbinding te maken en de lees-/schrijfbewerking te hervatten met een nieuwe primaire. | Nee |
| 7 | Er wordt een nieuwe stand-byserver in een andere zone tot stand gebracht. | Nee |
| 8 | De stand-byserver begint logboeken (van Azure Blob) te herstellen die tijdens de opzet zijn gemist. | Nee |
| 9 | Er wordt een stabiele toestand tussen de primaire en de standbyserver tot stand gebracht. | Nee |
| 10 | Het geplande failoverproces is voltooid. | Nee |
Downtime van toepassingen begint bij stap 3 en kan de bewerking na stap 5 hervatten. De rest van de stappen worden op de achtergrond uitgevoerd zonder dat dit van invloed is op schrijf- en doorvoerbewerkingen van toepassingen.
Aanbeveling
Met flexibele server kunt u optioneel door Azure geïnitieerde onderhoudsactiviteiten plannen door een venster van 60 minuten te kiezen op een dag van uw voorkeur waarin de activiteiten op de databases naar verwachting laag zijn. Azure-onderhoudstaken, zoals patchen of upgrades van secundaire versies, vinden plaats in dat venster. Als u geen aangepast venster kiest, wordt een door het systeem toegewezen venster van 1 uur tussen 11:00 - 7:00 uur lokale tijd geselecteerd voor uw server. Deze door Azure geïnitieerde onderhoudsactiviteiten worden ook uitgevoerd op de stand-byreplica voor flexibele servers die zijn geconfigureerd met beschikbaarheidszones.
Zie Geplande downtime-gebeurtenissen voor een lijst met mogelijke geplande downtime-gebeurtenissen.
Niet-geplande failover
Niet-geplande downtime kan optreden als gevolg van onvoorziene onderbrekingen, zoals onderliggende hardwarestoringen, netwerkproblemen en softwarefouten. Als de databaseserver die is geconfigureerd met hoge beschikbaarheid onverwacht uitvalt, wordt de stand-byreplica geactiveerd en kunnen de clients hun bewerkingen hervatten. Als deze niet is geconfigureerd met hoge beschikbaarheid (HA), wordt automatisch een nieuwe databaseserver ingericht als de poging tot opnieuw opstarten mislukt. 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.
Failovertests (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 standbyserver het herstelproces tot de laatste vastgelegde gegevens heeft voltooid, wordt deze uitgeroepen tot 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.
Hier volgen de stappen tijdens geforceerde failover:
| Stap | Beschrijving | Verwachte downtime van de app? |
|---|---|---|
| 1 | De primaire server wordt kort na ontvangst van de failoveraanvraag gestopt. | Ja |
| 2 | De toepassing ondervindt downtime omdat de primaire server niet beschikbaar is. | Ja |
| 3 | Intern bewakingssysteem detecteert de fout en initieert een failover naar de stand-byserver. | Ja |
| 4 | Stand-byserver gaat in de herstelmodus voordat deze volledig wordt gepromoveerd als een onafhankelijke server. | Ja |
| 5 | Het failoverproces wacht tot het standbyherstel voltooid is. | Ja |
| 6 | Zodra de server werkt, wordt het DNS-record bijgewerkt met dezelfde hostnaam, maar met het IP-adres van de standby. | Ja |
| 7 | De toepassing kan opnieuw verbinding maken met de nieuwe primaire server en de bewerking hervatten. | Nee |
| 8 | Er wordt een stand-byserver in de voorkeurszone tot stand gebracht. | Nee |
| 9 | De stand-byserver begint logboeken (van Azure Blob) te herstellen die tijdens de opzet zijn gemist. | Nee |
| 10 | Er wordt een stabiele toestand tussen de primaire en de standbyserver tot stand gebracht. | Nee |
| 11 | Het geforceerde failoverproces is voltooid. | Nee |
Uitvaltijd van toepassingen wordt verwacht na stap 1 en blijft behouden totdat stap 6 is voltooid. De rest van de stappen worden op de achtergrond uitgevoerd zonder dat dit van invloed is op de schrijf- en doorvoerbewerkingen van de toepassing.
Belangrijk
Het end-to-end-failoverproces omvat (a) een failover naar de stand-byserver na het uitvallen van de primaire server en (b) het tot stand brengen van een nieuwe stand-byserver in een stabiele toestand. Wanneer uw toepassing uitvaltijd in beslag neemt totdat de failover naar de stand-by is voltooid, meet u de downtime vanuit het perspectief van uw toepassing/client in plaats van het algehele end-to-end-failoverproces.
Overwegingen bij het uitvoeren van geforceerde failovers
De totale end-to-end-bewerkingstijd kan worden gezien als langer 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.
Het is raadzaam om een geforceerde failover uit te voeren tijdens een periode met weinig activiteit om de downtime te verminderen.
Best practices voor PostgreSQL-statistieken na een failover
Na een PostgreSQL-failover omvat het primaire mechanisme voor het onderhouden van optimale databaseprestaties inzicht in de verschillende rollen van pg_statistic en de pg_stat_* -tabellen. De pg_statistic tabel bevat optimalisatiestatistieken, 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.
Daarentegen worden de pg_stat_* tabellen, die activiteitsstatistieken vastleggen, zoals het aantal scans, tuples lezen en updates, 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 is ontworpen om de operationele status van de nieuwe primaire nauwkeurig weer te geven, maar betekent ook het verlies van historische activiteitsgegevens die het autovacuumproces en andere operationele efficiëntie kunnen informeren.
Gezien dit onderscheid is de beste praktijk na een PostgreSQL-failover om ANALYZE uit te voeren. 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
Zonal herstel: Als u wilt herstellen na een fout op zoneniveau, kunt u een herstel op een specifiek tijdstip uitvoeren met behulp van 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 wordt binnen 60-120 seconden automatisch overgeschakeld naar de stand-byserver, 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 lokale 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. Uptime SLA van 99,9% wordt in deze configuratie aangeboden. 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:
- Er wordt een nieuwe Linux reken-VM ingericht.
- De opslag met gegevensbestanden wordt toegewezen aan de nieuwe virtuele machine.
- PostgreSQL-database-engine wordt online gebracht op de nieuwe virtuele machine.
In de onderstaande afbeelding ziet u de overgang tussen VM en opslagfout.
Herstel na noodgevallen en bedrijfscontinuïteit tussen regio's
In het geval van een regiobrede ramp 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 voor uw bedrijfskritieke databases beperken 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. Wanneer u uw toepassingen ontwerpt, moet u rekening houden 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 de mogelijkheid om uw server in een andere regio te herstellen in het geval van een noodgeval. Het biedt ook ten minste 99,9999999999999999 procent (16 negens) duurzaamheid van back-upobjecten gedurende een jaar.
Geografisch redundante back-up kan alleen worden geconfigureerd op het moment dat de server wordt gemaakt. Wanneer de server is geconfigureerd 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
Leesreplica's voor meerdere regio's kunnen worden geïmplementeerd om uw databases te beschermen tegen storingen op regioniveau. Leesreplica's worden asynchroon bijgewerkt met behulp van PostgreSQL's fysieke replicatietechnologie en kunnen achterlopen op de primaire replica. Leesreplica's worden ondersteund in de algemene en geheugengeoptimaliseerde rekenlagen.
Voor meer informatie over leesreplicafuncties en overwegingen, zie Leesreplica's.
Detectie, melding en beheer van storingen
Als uw server is geconfigureerd 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. In het geval van een regiofout kunt u herstel na noodgevallen uitvoeren door uw leesreplica te promoveren tot een zelfstandige, lees- en schrijfbare server. RPO duurt naar verwachting maximaal 5 minuten (mogelijk gegevensverlies), behalve in het geval van ernstige regionale storingen 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.