Delen via


Leesreplica's promoveren in Azure Database for PostgreSQL - Flexible Server

VAN TOEPASSING OP: Azure Database for PostgreSQL - Flexibele server

Niveau verhogen verwijst naar het proces waarbij een replica wordt opdracht gegeven om de replicamodus te beëindigen en over te stappen op volledige lees-/schrijfbewerkingen.

Belangrijk

Niveau verhogen is niet automatisch. In het geval van een storing in de primaire server schakelt het systeem niet onafhankelijk over naar de leesreplica. Een gebruikersactie is altijd vereist voor de promotiebewerking.

Promotie van replica's kan op twee verschillende manieren worden uitgevoerd:

Niveau verhogen naar primaire server

Met deze actie wordt een replica naar de rol van de primaire server verheven. In het proces wordt de huidige primaire server gedegradeerd naar een replicarol, waarbij de rollen worden gewisseld. Voor een geslaagde promotie moet een virtueel eindpunt zijn geconfigureerd voor zowel het huidige primaire eindpunt als het schrijfeindpunt en de replica die is bedoeld voor promotie als het eindpunt van de lezer. De promotie is alleen geslaagd als de doelreplica is opgenomen in de eindpuntconfiguratie van de lezer.

Het diagram illustreert de configuratie van de servers vóór de promotie en de resulterende status nadat de promotiebewerking is voltooid.

Diagram met promotie naar primaire serverbewerking.

Niveau verhogen naar onafhankelijke server en verwijderen uit replicatie

Wanneer u deze optie kiest, wordt de replica gepromoveerd tot een onafhankelijke server en wordt deze verwijderd uit het replicatieproces. Als gevolg hiervan werken zowel de primaire als de gepromoveerde server als twee onafhankelijke lees-/schrijfservers. Er moet worden opgemerkt dat virtuele eindpunten kunnen worden geconfigureerd, ze niet nodig zijn voor deze bewerking. De zojuist gepromoveerde server maakt geen deel meer uit van bestaande virtuele eindpunten, zelfs als het eindpunt van de lezer er eerder naar wijst. Het is dus essentieel om de verbindingsreeks van uw toepassing bij te werken om rechtstreeks naar de zojuist gepromoveerde replica te gaan als de toepassing er verbinding mee moet maken.

In het diagram ziet u hoe de servers worden ingesteld voordat ze worden gepromoveerd en hun configuratie nadat ze onafhankelijke servers zijn geworden.

Diagram met promotie naar onafhankelijke server en verwijderen uit replicatiebewerking.

Belangrijk

Het niveau verhogen naar een onafhankelijke server en verwijderen uit replicatieactie is achterwaarts compatibel met de vorige promotiefunctionaliteit.

Belangrijk

Serversymmetrie: Voor een succesvolle promotie met de promotie naar primaire serverbewerking moeten zowel de primaire als de replicaservers identieke lagen en opslaggrootten hebben. Als de primaire instantie bijvoorbeeld 2vCores heeft en de replica 4vCores heeft, is de enige haalbare optie om de actie 'niveau verhogen naar onafhankelijke server en verwijderen uit replicatie' te gebruiken. Daarnaast moeten ze dezelfde waarden delen voor serverparameters die gedeeld geheugen toewijzen.

Voor beide promotiemethoden zijn er meer opties om rekening mee te houden:

  • Gepland: Deze optie zorgt ervoor dat gegevens worden gesynchroniseerd voordat ze worden gepromoot. Alle logboeken die in behandeling zijn, worden toegepast om ervoor te zorgen dat gegevensconsistentie wordt gegarandeerd voordat clientverbindingen worden geaccepteerd.

  • Geforceerd: deze optie is ontworpen voor snel herstel in scenario's zoals regionale storingen. In plaats van te wachten om alle gegevens van de primaire server te synchroniseren, wordt de server operationeel zodra wal-bestanden worden verwerkt die nodig zijn om de dichtstbijzijnde consistente status te bereiken. Als u de replica promoveert met deze optie, geeft de vertraging op het moment dat u de replica loskoppelt van de primaire replica aan hoeveel gegevens verloren gaan.

Belangrijk

De optie Geforceerde promotie is speciaal ontworpen om regionale storingen aan te pakken. In dergelijke gevallen worden alle controles overgeslagen, inclusief de vereiste voor serversymmetrie, en wordt de promotie voortgezet. Dit komt doordat er prioriteit wordt gegeven aan de onmiddellijke beschikbaarheid van servers voor het afhandelen van noodscenario's. Het gebruik van de optie Geforceerd buiten regio-downscenario's is echter niet toegestaan als niet wordt voldaan aan de vereisten voor leesreplica's die zijn opgegeven in de documentatie, met name de symmetrievereiste van de server, omdat dit kan leiden tot problemen zoals verbroken replicatie.

Meer informatie over het promoveren van replica's naar primaire servers en het promoveren naar onafhankelijke servers en het verwijderen van replicatie.

Configuratiebeheer

Leesreplica's worden behandeld als afzonderlijke servers in termen van configuraties van besturingsvlakken. Deze benadering biedt flexibiliteit voor scenario's met leesschaal. Wanneer u echter replica's gebruikt voor herstel na noodgevallen, moeten gebruikers ervoor zorgen dat de configuratie naar wens is.

De promotiebewerking draagt geen specifieke configuraties en parameters over. Hier volgen enkele van de belangrijke:

  • PgBouncer: de instellingen en status van de ingebouwde PgBouncer-verbindingspooler worden niet gerepliceerd tijdens het promotieproces. Als PgBouncer is ingeschakeld op de primaire maar niet op de replica, blijft deze uitgeschakeld op de replica na promotie. Als u PgBouncer op de zojuist gepromoveerde server wilt, moet u deze inschakelen vóór of na de promotieactie.
  • Geografisch redundante back-upopslag: geo-back-upinstellingen worden niet overgedragen. Omdat replica's geen geo-back-up kunnen hebben ingeschakeld, heeft de gepromoveerde primaire replica (voorheen de replica) deze niet na promotie. De functie kan alleen worden geactiveerd tijdens de aanmaaktijd van de standaardserver (geen replica).
  • Serverparameters: als hun waarden verschillen op de primaire en leesreplica, worden ze niet gewijzigd tijdens de promotie. Het is essentieel om te weten dat parameters die van invloed zijn op de grootte van het gedeelde geheugen dezelfde waarden moeten hebben op zowel de primaire als de replica. Deze vereiste wordt beschreven in de sectie Serverparameters .
  • Microsoft Entra-verificatie: Als de primaire microsoft Entra-verificatie is geconfigureerd, maar de replica is ingesteld met PostgreSQL-verificatie, schakelt de replica na promotie niet automatisch over naar Microsoft Entra-verificatie. De PostgreSQL-verificatie blijft behouden. Gebruikers moeten Microsoft Entra-verificatie handmatig configureren op de gepromoveerde replica vóór of na het promotieproces.
  • Hoge beschikbaarheid (HA): Als u hoge beschikbaarheid na de promotie nodig hebt, moet deze worden geconfigureerd op de nieuw gepromoveerde primaire server, na het omkeren van de functie.

Overwegingen

Serverstatussen tijdens promotie

In zowel de scenario's geplande als geforceerde promotie is het vereist dat servers (zowel primaire als replica) de status Beschikbaar hebben. Als de status van een server iets anders is dan 'Beschikbaar' (zoals 'Bijwerken' of 'Opnieuw opstarten'), kan de promotie doorgaans niet doorgaan zonder problemen. Er wordt echter een uitzondering gemaakt in het geval van regionale storingen.

Tijdens dergelijke regionale storingen kan de methode geforceerde promotie worden geïmplementeerd, ongeacht de huidige status van de primaire server. Met deze aanpak kunt u snel actie ondernemen als reactie op mogelijke regionale rampen, waardoor normale controles op serverbeschikbaarheid worden overgeslagen.

Houd er rekening mee dat als de voormalige primaire server niet kan worden hersteld tijdens de promotie van de replica, de enige optie is om de voormalige primaire server te verwijderen en de replicaserver opnieuw te maken.

Zichtbaarheid van meerdere replica's tijdens promotie in niet-geairede regio's

Bij het omgaan met meerdere replica's en als de primaire regio geen gekoppelde regio heeft, moet er een speciale overweging worden overwogen. In het geval van een regionale storing die van invloed is op de primaire replica, worden andere replica's niet automatisch herkend door de zojuist gepromoveerde replica. Hoewel toepassingen nog steeds kunnen worden omgeleid naar de gepromoveerde replica voor continue werking, blijven de niet-herkende replica's verbroken tijdens de storing. Deze extra replica's worden alleen opnieuw gekoppeld en hervat hun rollen zodra de oorspronkelijke primaire regio is hersteld.

Veelgestelde vragen

  • Kan ik een replica promoveren als voor mijn primaire server hoge beschikbaarheid (HA) is ingeschakeld?

    Ja, of uw primaire server nu ha-enabled is of niet, u kunt de leesreplica promoveren. De mogelijkheid om een leesreplica naar een primaire server te promoveren, is onafhankelijk van de ha-configuratie van de primaire server.

  • Als ik een primaire replica met hoge beschikbaarheid en een leesreplica heb en ik de replica promoveert, gaat u terug naar de oorspronkelijke primaire replica, dan bevindt de server zich nog steeds in hoge beschikbaarheid?

    Nee, we schakelen hoge beschikbaarheid uit tijdens de eerste promotie omdat we geen leesreplica's met hoge beschikbaarheid ondersteunen. Het promoveren van een leesreplica naar een primaire replica betekent dat de oorspronkelijke primaire replica de rol wijzigt in een replica. Als u terugschakelt, moet u hoge beschikbaarheid inschakelen op de oorspronkelijke primaire server.