Share via

Leesreplica's in Azure Database for PostgreSQL - flexibele server

  • Artikel

VAN TOEPASSING OP: Azure Database for PostgreSQL - Flexibele server

Met de functie leesreplica kunt u gegevens repliceren van een flexibele Server-instantie van Azure Database for PostgreSQL naar een alleen-lezen replica. Replica's worden asynchroon bijgewerkt met de systeemeigen fysieke replicatietechnologie van de PostgreSQL-engine. Het streamen van replicatie met behulp van replicatiesleuven is de standaardbewerkingsmodus. Indien nodig wordt het verzenden van logboeken op basis van bestanden gebruikt om in te halen. U kunt repliceren van de primaire server naar maximaal vijf replica's.

Replica's zijn nieuwe servers die u beheert op dezelfde manier als gewone exemplaren van flexibele Azure Database for PostgreSQL-servers. Voor elke leesreplica wordt u gefactureerd voor de ingerichte rekenkracht in vCores en opslag in GB/maand.

Meer informatie over het maken en beheren van replica's.

Wanneer u een leesreplica moet gebruiken

De leesreplicafunctie helpt de prestaties en schaal van leesintensieve werkbelastingen verbeteren. Leeswerkbelastingen kunnen worden geïsoleerd naar de replica's, terwijl schrijfwerkbelastingen naar de primaire server kunnen worden omgeleid. Leesreplica's kunnen ook worden geïmplementeerd in een andere regio en kunnen worden gepromoveerd naar een read-write-server als herstel na noodgevallen nodig is.

Een typisch scenario is dat BI- en analytische workloads de leesreplica gebruiken als gegevensbron voor rapportage.

Aangezien replica's alleen-lezen zijn, verminderen ze niet direct de belasting van de schrijfcapaciteit op de primaire server.

Overwegingen

Leesreplica's zijn voornamelijk ontworpen voor scenario's waarbij offloading van query's nuttig is en een lichte vertraging beheerbaar is. Ze zijn geoptimaliseerd voor bijna realtime updates van de primaire voor de meeste workloads, waardoor ze een uitstekende oplossing zijn voor scenario's met veel leesbewerkingen. Het is echter belangrijk om te weten dat ze niet zijn bedoeld voor synchrone replicatiescenario's waarvoor nauwkeurigheid van gegevens tot en met de minuut is vereist. Hoewel de gegevens op de replica uiteindelijk consistent worden met de primaire, kan er een vertraging optreden, die meestal een paar seconden tot minuten varieert en in sommige scenario's met een zware werkbelasting of hoge latentie, kan deze vertraging worden uitgebreid tot uren. Normaal gesproken hebben leesreplica's in dezelfde regio als de primaire replica minder vertraging dan geo-replica's, omdat de laatste vaak te maken heeft met een latentie op geografische afstand. Raadpleeg het artikel geo-replicatie voor meer inzicht in de gevolgen voor de prestaties van geo-replicatie . De gegevens op de replica worden uiteindelijk consistent met de gegevens op de primaire. Gebruik deze functie voor workloads die deze vertraging aan kunnen.

Notitie

Voor de meeste workloads bieden leesreplica's in nagenoeg realtime updates van de primaire server. Bij permanente zware primaire werkbelastingen met veel schrijfintensieve primaire werkbelastingen kan de replicatievertraging echter blijven groeien en kan deze mogelijk alleen worden ingehaald met de primaire werkbelasting. Dit kan ook het opslaggebruik bij de primaire opslag verhogen, omdat de WAL-bestanden slechts eenmaal worden verwijderd nadat ze zijn ontvangen op de replica. Als deze situatie zich blijft voordoen, kunt u de leesreplica verwijderen en opnieuw maken nadat de schrijfintensieve workloads zijn voltooid, de replica terugbrengen naar een goede status voor vertraging. Asynchrone leesreplica's zijn niet geschikt voor dergelijke zware schrijfworkloads. Bij het evalueren van leesreplica's voor uw toepassing, controleert u de vertraging op de replica voor een volledige app-workloadcyclus door de piek- en niet-piektijden om de mogelijke vertraging en de verwachte RTO/RPO op verschillende punten van de workloadcyclus te beoordelen.

Replica's maken

Een primaire server voor Azure Database for PostgreSQL flexibele server kan worden geïmplementeerd in elke regio die ondersteuning biedt voor de service. U kunt replica's maken van de primaire server binnen dezelfde regio of in verschillende globale Azure-regio's waar flexibele Azure Database for PostgreSQL-server beschikbaar is. De mogelijkheid om replica's te maken, wordt nu uitgebreid naar enkele speciale Azure-regio's. Zie het artikel Geo-replicatie voor een lijst met speciale regio's waar u replica's kunt maken.

Wanneer u de werkstroom voor het maken van replica's start, wordt er een leeg exemplaar van azure Database for PostgreSQL flexibele server gemaakt. De nieuwe server wordt gevuld met de gegevens op de primaire server. Voor het maken van replica's in dezelfde regio wordt een momentopnamebenadering gebruikt. Daarom is de aanmaaktijd onafhankelijk van de grootte van de gegevens. Geo-replica's worden gemaakt met behulp van de basisback-up van het primaire exemplaar, dat vervolgens via het netwerk wordt verzonden; Daarom kan de aanmaaktijd variëren van minuten tot enkele uren, afhankelijk van de primaire grootte.

Replica wordt alleen als geslaagd beschouwd wanneer aan twee voorwaarden wordt voldaan: de volledige back-up van het primaire exemplaar moet worden gekopieerd naar de replica en de transactielogboeken moeten worden gesynchroniseerd met niet meer dan een vertraging van 1 GB.

Als u een geslaagde bewerking wilt maken, vermijdt u het maken van replica's tijdens hoge transactionele belasting. U moet bijvoorbeeld voorkomen dat u replica's maakt wanneer u migreert van andere bronnen naar een flexibele Azure Database for PostgreSQL-server of tijdens zware bulksgewijs laden. Als u gegevens migreert of grote hoeveelheden gegevens op dit moment laadt, kunt u deze taak het beste eerst voltooien. Nadat u deze hebt voltooid, kunt u de replica's instellen. Zodra de migratie- of bulksgewijs laden is voltooid, controleert u of de grootte van het transactielogboek is teruggezet naar de normale grootte. Normaal gesproken moet de grootte van het transactielogboek dicht bij de waarde liggen die is gedefinieerd in de max_wal_size serverparameter voor uw exemplaar. U kunt de opslagvoetafdruk voor transactielogboeken bijhouden met behulp van de metrische waarde voor opslag van transactielogboeken, die inzicht biedt in de hoeveelheid opslagruimte die door het transactielogboek wordt gebruikt. Door deze metrische gegevens te bewaken, kunt u ervoor zorgen dat de grootte van het transactielogboek binnen het verwachte bereik valt en dat het proces voor het maken van replica's kan worden gestart.

Belangrijk

Leesreplica's worden momenteel ondersteund voor de rekenlagen Algemeen gebruik en Geoptimaliseerd voor geheugen. De rekenlaag Burstable-server wordt niet ondersteund.

Belangrijk

Wanneer u bewerkingen voor het maken, verwijderen en promoveren van replica's uitvoert, krijgt de primaire server een updatestatus. Gedurende deze tijd zijn serverbeheerbewerkingen zoals het wijzigen van serverparameters, het wijzigen van opties voor hoge beschikbaarheid of het toevoegen of verwijderen van firewalls niet beschikbaar. Het is belangrijk te weten dat de updatestatus alleen invloed heeft op serverbeheerbewerkingen en geen invloed heeft op bewerkingen in het gegevensvlak . Dit betekent dat uw databaseserver volledig functioneel blijft en verbindingen kan accepteren, evenals lees- en schrijfverkeer.

Meer informatie over het maken van een leesreplica in Azure Portal.

Configuratiebeheer

Bij het instellen van leesreplica's voor flexibele Azure Database for PostgreSQL-server is het essentieel om inzicht te hebben in de serverconfiguraties die kunnen worden aangepast, de replica's die zijn overgenomen van de primaire server en eventuele gerelateerde beperkingen.

Overgenomen configuraties

Wanneer een leesreplica wordt gemaakt, neemt deze specifieke serverconfiguraties over van de primaire server. Deze configuraties kunnen worden gewijzigd tijdens het maken van de replica of nadat deze is ingesteld. Specifieke instellingen, zoals geo-back-up, worden echter niet gerepliceerd naar de leesreplica.

Configuraties tijdens het maken van replica's

  • Laag, opslaggrootte: Voor de bewerking 'niveau verhogen naar primaire server' moet deze hetzelfde zijn als de primaire. Voor de bewerking 'niveau verhogen naar onafhankelijke server en verwijderen uit replicatie' kan dit hetzelfde of hoger zijn dan de primaire server.
  • Prestatielaag (IOPS): aanpasbaar.
  • Gegevensversleuteling: Aanpasbare, omvat het verplaatsen van door de service beheerde sleutels naar door de klant beheerde sleutels.

Configuraties na het maken

  • Firewallregels: kan worden toegevoegd, verwijderd of gewijzigd.
  • Laag, opslaggrootte: Voor de bewerking 'niveau verhogen naar primaire server' moet deze hetzelfde zijn als de primaire. Voor de bewerking 'niveau verhogen naar onafhankelijke server en verwijderen uit replicatie' kan dit hetzelfde of hoger zijn dan de primaire server.
  • Prestatielaag (IOPS): aanpasbaar.
  • Verificatiemethode: Aanpasbare opties omvatten het overschakelen van PostgreSQL-verificatie naar Microsoft Entra.
  • Serverparameters: de meeste zijn aanpasbaar. Degenen die van invloed zijn op de grootte van het gedeelde geheugen , moeten echter worden afgestemd op de primaire scenario's, met name voor mogelijke scenario's met het niveau 'niveau verhogen naar primaire server'. Voor de bewerking 'niveau verhogen naar onafhankelijke server en verwijderen uit replicatie' moeten deze parameters hetzelfde zijn of de parameters op de primaire server overschrijden.
  • Onderhoudsschema: Aanpasbaar.

Niet-ondersteunde functies op leesreplica's

Bepaalde functies zijn beperkt tot primaire servers en kunnen niet worden ingesteld op leesreplica's. Deze omvatten:

  • Back-ups, inclusief geo-back-ups.
  • Hoge beschikbaarheid (HA)

Als uw bronexemplaren van Azure Database for PostgreSQL flexibele servers zijn versleuteld met door de klant beheerde sleutels, raadpleegt u de documentatie voor andere overwegingen.

Verbinding maken met een replica

Wanneer u een replica maakt, neemt deze de firewallregels of het service-eindpunt van het virtuele netwerk van de primaire server over. Deze regels kunnen worden gewijzigd tijdens het maken van replica's en op een later tijdstip.

De replica neemt het beheerdersaccount over van de primaire server. Alle gebruikersaccounts op de primaire server worden gerepliceerd naar de leesreplica's. U kunt alleen verbinding maken met een leesreplica met behulp van de gebruikersaccounts die beschikbaar zijn op de primaire server.

Er zijn twee methoden om verbinding te maken met de replica:

  • Rechtstreeks naar het replica-exemplaar: u kunt verbinding maken met de replica met behulp van de hostnaam en een geldig gebruikersaccount, net zoals u dat zou doen op een gewone flexibele Azure Database for PostgreSQL-serverinstantie. Voor een server met de naam myreplica met de gebruikersnaam myadmin van de beheerder kunt u verbinding maken met de replica met behulp van psql:
psql -h myreplica.postgres.database.azure.com -U myadmin postgres

Voer bij de prompt het wachtwoord voor het gebruikersaccount in.

Bovendien biedt Azure Portal kant-en-klare verbindingsreeks s om het verbindingsproces te vereenvoudigen. Deze vindt u op de pagina Verbinding maken . Ze omvatten zowel libpq variabelen als verbindingsreeks s die zijn afgestemd op bash-consoles.

  • Via virtuele eindpunten: er is een alternatieve verbindingsmethode met behulp van virtuele eindpunten, zoals beschreven in het artikel Over virtuele eindpunten . Met behulp van virtuele eindpunten kunt u het alleen-lezeneindpunt zo configureren dat het consistent verwijst naar de replica, ongeacht welke server momenteel de replicarol heeft.

Replicatie bewaken

De functie Leesreplica in flexibele Azure Database for PostgreSQL-server is afhankelijk van het mechanisme voor replicatiesites. Het belangrijkste voordeel van replicatiesites is dat ze automatisch het aantal transactielogboeken (WAL-segmenten) aanpassen dat vereist is voor alle replicaservers. Hiermee voorkomt u dat replica's worden gesynchroniseerd omdat hiermee WAL-segmenten op de primaire server worden verwijderd voordat ze naar de replica's worden verzonden. Het nadeel van de aanpak is het risico dat er geen ruimte meer beschikbaar is op de primaire methode als de replicatiesite gedurende langere tijd inactief blijft. In dergelijke situaties verzamelt primaire WAL-bestanden die incrementele groei van het opslaggebruik veroorzaken. Wanneer het opslaggebruik 95% bereikt of als de beschikbare capaciteit kleiner is dan 5 GiB, wordt de server automatisch overgeschakeld naar de modus Alleen-lezen om fouten te voorkomen die zijn gekoppeld aan volledige schijfsituaties.
Daarom is het controleren van de replicatievertraging en de status van replicatiesites cruciaal voor leesreplica's.

We raden u aan waarschuwingsregels in te stellen voor de gebruikte opslag of het opslagpercentage, en voor replicatievertragingen, wanneer ze bepaalde drempelwaarden overschrijden, zodat u proactief kunt handelen, de opslaggrootte kunt vergroten en leesreplica's kunt verwijderen. U kunt bijvoorbeeld een waarschuwing instellen als het opslagpercentage hoger is dan 80% gebruik en als de replicavertraging hoger is dan 5 minuten. De metrische gegevens voor opslag van transactielogboeken die worden gebruikt , laten zien of de accumulatie van WAL-bestanden de belangrijkste reden is van het overmatige opslaggebruik.

Flexibele Azure Database for PostgreSQL-server biedt twee metrische gegevens voor het bewaken van replicatie. De twee metrische gegevens zijn Max Physical Replication Lag en Read Replica Lag. Als u wilt weten hoe u deze metrische gegevens bekijkt, raadpleegt u de sectie Een replica bewaken van het artikel met instructies voor leesreplica's.

De metrische waarde voor maximale fysieke replicatievertraging toont de vertraging in bytes tussen de primaire en de meest achterblijvende replica. Deze metrische waarde is alleen van toepassing en alleen beschikbaar op de primaire server en is alleen beschikbaar als ten minste één van de leesreplica's is verbonden met de primaire server. De vertragingsinformatie is ook aanwezig wanneer de replica bezig is met het inhaalproces van de primaire replica, tijdens het maken van replica's of wanneer replicatie inactief wordt.

De metrische waarde leesreplicavertraging toont de tijd sinds de laatste opnieuw afgespeelde transactie. Als er bijvoorbeeld geen transacties plaatsvinden op uw primaire server en de laatste transactie vijf seconden geleden opnieuw is afgespeeld, toont de vertraging van leesreplica 5 seconden. Deze metrische waarde is alleen van toepassing en alleen beschikbaar op replica's.

Stel een waarschuwing in om u te informeren wanneer de replicavertraging een waarde bereikt die niet acceptabel is voor uw workload.

Voor meer inzicht voert u rechtstreeks een query uit op de primaire server om de replicatievertraging op alle replica's op te halen.

Notitie

Als een primaire server of leesreplica opnieuw wordt opgestart, wordt de tijd die nodig is om de replicavertraging opnieuw op te starten en in te halen weergegeven in de metrische waarde replicavertraging.

Replicatiestatus

Als u de voortgang en status van de replicatie wilt controleren en de bewerking wilt verhogen, raadpleegt u de kolom Replicatiestatus in Azure Portal. Deze kolom bevindt zich op de replicatiepagina en geeft verschillende statussen weer die inzicht geven in de huidige toestand van de leesreplica's en hun koppeling naar de primaire replica. Voor gebruikers die afhankelijk zijn van de Azure Resource Manager-API, wordt de status weergegeven als ReplicationState in de eigenschapstas bij het aanroepen van de GetReplica replica API.

Dit zijn de mogelijke waarden:

Replicatiestatus Beschrijving Volgorde verhogen Volgorde voor het maken van replica's lezen
Opnieuw configureren Wacht op het begin van de replica-primaire koppeling. Het kan langer blijven als de replica of de regio niet beschikbaar is, bijvoorbeeld vanwege een noodgeval. 1 N.v.t.
Bevoorrading De leesreplica wordt ingericht en de replicatie tussen de twee servers moet nog worden gestart. Totdat het inrichten is voltooid, kunt u geen verbinding maken met de leesreplica. N.v.t. 1
Bijwerken De serverconfiguratie wordt voorbereid na een geactiveerde actie, zoals promotie of het maken van leesreplica's. 2 2
Catchup WAL-bestanden worden toegepast op de replica. De duur van deze fase tijdens de promotie is afhankelijk van de gekozen optie voor gegevenssynchronisatie: gepland of geforceerd. 3 3
Actief De status In orde, waarmee wordt aangegeven dat de leesreplica is verbonden met de primaire replica. Als de servers zijn gestopt maar eerder zijn verbonden, blijft de status actief. 4 4
Kapot De status Beschadigd, wat aangeeft dat de promotiebewerking is mislukt of dat de replica om een of andere reden geen verbinding kan maken met de primaire replica. Verwijder de replica en maak de replica opnieuw om dit op te lossen. N.v.t. N.v.t.

Meer informatie over het bewaken van replicatie.

Overwegingen

In deze sectie vindt u een overzicht van overwegingen over de functie leesreplica. De volgende overwegingen zijn van toepassing.

  • Energiebewerkingen: Energiebewerkingen, inclusief start- en stopacties, kunnen worden toegepast op zowel de primaire als de replicaservers. Om de systeemintegriteit te behouden, moet er echter een specifieke volgorde worden gevolgd. Voordat u de leesreplica's stopt, moet u ervoor zorgen dat de primaire server eerst wordt gestopt. Wanneer bewerkingen worden gestart, start u de startactie op de replicaservers voordat u de primaire server start.
  • Als de server leesreplica's heeft, moeten leesreplica's eerst worden verwijderd voordat u de primaire server verwijdert.
  • Voor een in-place primaire versie-upgrade in de flexibele server van Azure Database for PostgreSQL moet u alle leesreplica's verwijderen die momenteel op de server zijn ingeschakeld. Zodra de replica's zijn verwijderd, kan de primaire server worden bijgewerkt naar de gewenste primaire versie. Nadat de upgrade is voltooid, kunt u de replica's opnieuw maken om het replicatieproces te hervatten.
  • Premium SSD v2: Als de primaire server Premium SSD v2 gebruikt voor opslag, wordt het maken van leesreplica's niet ondersteund vanaf de huidige release.
  • Beheerderswachtwoord opnieuw instellen: het beheerderswachtwoord opnieuw instellen op de replicaserver wordt momenteel niet ondersteund. Daarnaast wordt het bijwerken van het beheerderswachtwoord, samen met het promoten van replicabewerkingen in dezelfde aanvraag, ook niet ondersteund. Als u dit wilt doen, moet u eerst de replicaserver promoveren en vervolgens het wachtwoord op de zojuist gepromoveerde server afzonderlijk bijwerken.

Nieuwe replica's

Er wordt een leesreplica gemaakt als een nieuw exemplaar van een flexibele Azure Database for PostgreSQL-server. Een bestaande server kan niet worden gemaakt in een replica. U kunt geen replica van een andere leesreplica maken. Trapsgewijze replicatie wordt dus niet ondersteund.

Resources verplaatsen

Gebruikers kunnen leesreplica's maken in een andere resourcegroep dan de primaire. Het verplaatsen van leesreplica's naar een andere resourcegroep nadat het maken ervan niet wordt ondersteund. Daarnaast wordt het verplaatsen van replica's naar een ander abonnement en het verplaatsen van de primaire replica met leesreplica's naar een andere resourcegroep of een ander abonnement niet ondersteund.

Automatische groei van opslag

Wanneer u leesreplica's configureert voor een exemplaar van een flexibele Azure Database for PostgreSQL-server, is het essentieel om ervoor te zorgen dat de instelling voor automatisch vergroten van opslag op de replica's overeenkomt met die van de primaire server. Met de functie voor automatische groei van opslag kan de databaseopslag automatisch toenemen om te voorkomen dat er onvoldoende ruimte beschikbaar is, wat kan leiden tot storingen in de database. U kunt als volgt instellingen voor automatische groei van opslag effectief beheren:

  • U kunt automatische groei van opslag hebben ingeschakeld op elke replica, ongeacht de instelling van de primaire server.
  • Als automatisch groeien van opslag is ingeschakeld op de primaire server, moet deze ook worden ingeschakeld op de replica's om consistentie in het gedrag van opslagschalen te garanderen.
  • Als u automatische groei van opslag wilt inschakelen op de primaire opslag, moet u deze eerst inschakelen op de replica's. Deze volgorde van bewerkingen is van cruciaal belang voor het behouden van replicatie-integriteit.
  • Als u daarentegen automatische groei van opslag wilt uitschakelen, moet u deze eerst uitschakelen op de primaire server voordat de replica's replicatiecomplicaties voorkomen.

Back-up maken en herstellen

Bij het beheren van back-ups en herstelbewerkingen voor uw flexibele Server-exemplaar van Azure Database for PostgreSQL is het essentieel om rekening te houden met de huidige en vorige rol van de server in verschillende promotiescenario's. Dit zijn de belangrijkste punten die u moet onthouden:

Niveau verhogen naar primaire server

  1. Er worden geen back-ups gemaakt van leesreplica's: back-ups worden nooit gemaakt van leesreplicaservers, ongeacht hun eerdere rol.

  2. Behoud van eerdere back-ups: als een server ooit een primaire server was en back-ups heeft gemaakt gedurende die periode, blijven deze back-ups behouden. Ze worden bewaard tot de door de gebruiker gedefinieerde bewaarperiode.

  3. Beperkingen voor herstelbewerkingen: zelfs als er eerdere back-ups bestaan voor een server die is overgezet naar een leesreplica, worden herstelbewerkingen beperkt. U kunt alleen een herstelbewerking starten wanneer de server is gepromoveerd naar de primaire rol.

Voor de duidelijkheid ziet u hier een tabel met de volgende punten:

Serverfunctie Back-up gemaakt Herstellen toegestaan
Primair Ja Ja
Leesreplica Nee Nr.
Leesreplica gepromoveerd naar primair Ja Ja

Niveau verhogen naar onafhankelijke server en verwijderen uit replicatie

Hoewel de server een leesreplica is, worden er geen back-ups gemaakt. Zodra deze is gepromoveerd naar een onafhankelijke server, hebben zowel de gepromoveerde server als de primaire server back-ups gemaakt en zijn herstelbewerkingen toegestaan op beide.

Netwerken

Leesreplica's ondersteunen alle netwerkopties die worden ondersteund door Azure Database for PostgreSQL Flexible Server.

Belangrijk

Bidirectionele communicatie tussen de primaire server en leesreplica's is van cruciaal belang voor de flexibele serverinstallatie van Azure Database for PostgreSQL. Er moet een inrichting zijn voor het verzenden en ontvangen van verkeer op doelpoort 5432 binnen het subnet van het virtuele Azure-netwerk.

De bovenstaande vereiste faciliteert niet alleen het synchronisatieproces, maar zorgt er ook voor dat het niveau van het promotiemechanisme goed functioneert, waarbij replica's mogelijk in omgekeerde volgorde moeten communiceren , met name tijdens het promoveren tot primaire bewerkingen. Bovendien moeten verbindingen met het Azure-opslagaccount waarin WAL-archieven (Write-Ahead Logging) worden opgeslagen, worden toegestaan om de duurzaamheid van gegevens te handhaven en efficiënte herstelprocessen mogelijk te maken.

Zie de pagina Replicatie tussen Azure-regio's en virtuele netwerken met privénetwerken voor meer informatie over het configureren van privétoegang (integratie van virtuele netwerken) voor uw leesreplica's en inzicht in de gevolgen voor replicatie tussen Azure-regio's en virtuele netwerken binnen een privénetwerkcontext .

Beperking van problemen met replicatiesite

In zeldzame gevallen kan een hoge vertraging veroorzaakt door replicatiesites leiden tot een verhoogd opslaggebruik op de primaire server vanwege geaccumuleerde WAL-bestanden. Als het opslaggebruik 95% bereikt of de beschikbare capaciteit lager is dan 5 GiB, schakelt de server automatisch over naar de modus Alleen-lezen om schijfvullende fouten te voorkomen.

Omdat het onderhouden van de status en functionaliteit van de primaire server een prioriteit is, kan de replicatiesite in dergelijke gevallen worden verwijderd om ervoor te zorgen dat de primaire server operationeel blijft voor lees- en schrijfverkeer. Replicatie schakelt dus over naar de verzendmodus voor logboeken op basis van bestanden, wat kan leiden tot een hogere replicatievertraging.

Het is essentieel om het opslaggebruik en de replicatievertraging nauwkeurig te controleren en de benodigde acties uit te voeren om potentiële problemen te beperken voordat ze escaleren.

Serverparameters

Wanneer een leesreplica wordt gemaakt, neemt deze de serverparameters over van de primaire server. Dit is om een consistent en betrouwbaar uitgangspunt te garanderen. Wijzigingen in de serverparameters op de primaire server na het maken van de leesreplica worden echter niet automatisch gerepliceerd. Dit gedrag biedt het voordeel van afzonderlijke afstemming van de leesreplica, zoals het verbeteren van de prestaties voor leesintensieve bewerkingen zonder de parameters van de primaire server te wijzigen. Hoewel dit flexibiliteit en aanpassingsopties biedt, vereist het ook zorgvuldig en handmatig beheer om consistentie tussen de primaire en de replica te behouden wanneer uniformiteit van serverparameters is vereist.

Beheerders kunnen serverparameters op de leesreplicaserver wijzigen en andere waarden instellen dan op de primaire server. De enige uitzondering hierop zijn parameters die van invloed kunnen zijn op het herstel van de replica, ook vermeld in de sectie 'Schalen' hieronder: max_connections, max_prepared_transactions, max_locks_per_transaction, max_wal_senders. max_worker_processes Om ervoor te zorgen dat het herstel van de leesreplica naadloos verloopt en er geen beperkingen voor gedeeld geheugen optreden, moeten deze specifieke parameters altijd worden ingesteld op waarden die gelijk zijn aan of groter zijn dan de parameters die zijn geconfigureerd op de primaire server.

Schaal wijzigen

U kunt berekeningen (vCores) omhoog of omlaag schalen, de servicelaag wijzigen van Algemeen gebruik in Geoptimaliseerd voor geheugen (of omgekeerd) en de opslag omhoog schalen, maar de volgende opmerkingen zijn van toepassing.

Voor het schalen van rekenprocessen:

  • Voor een flexibele Azure Database for PostgreSQL-server zijn verschillende parameters vereist voor replica's die groter zijn dan of gelijk zijn aan de instelling op de primaire server om ervoor te zorgen dat de replica tijdens het herstel niet onvoldoende gedeeld geheugen heeft. De betrokken parameters zijn: max_connections, max_prepared_transactions, max_locks_per_transaction, max_wal_senders, . max_worker_processes

  • Omhoog schalen: schaal eerst de rekenkracht van een replica omhoog en schaal vervolgens de primaire schaal omhoog.

  • Omlaag schalen: schaal eerst de rekenkracht van de primaire machine omlaag en schaal vervolgens de replica omlaag.

  • Rekenkracht op de primaire moet altijd gelijk of kleiner zijn dan de berekening op de kleinste replica.

Voor het schalen van opslag:

  • Omhoog schalen: schaal eerst de opslag van een replica omhoog en schaal vervolgens de primaire waarde omhoog.

  • Opslaggrootte op de primaire moet altijd gelijk of kleiner zijn dan de opslaggrootte op de kleinste replica.

Gerelateerde inhoud