Leesreplica's in flexibele server voor Azure Database for PostgreSQL

Met de functie leesreplica kunt u gegevens van een Azure Database for PostgreSQL flexibele server repliceren naar een alleen-lezen replica. Replica's worden asynchroon bijgewerkt met behulp van de systeemeigen fysieke replicatietechnologie van de PostgreSQL-engine. Streamingreplicatie met behulp van replicatiesleuven is de standaard bewerkingsmodus. Indien nodig wordt bestandgebaseerde logbestandverzending gebruikt om bij te werken. U kunt repliceren van de primaire server naar maximaal vijf replica's.

Replica's zijn nieuwe servers die u beheert, vergelijkbaar met gewone Azure Database for PostgreSQL flexibele server. Voor elke leesreplica betaalt u voor de ingerichte rekenkracht in vCores en opslag in GB per maand.

Meer informatie over het maken van een leesreplica.

Wanneer u een leesreplica moet gebruiken

De functie leesreplica helpt de prestaties en schaal van leesintensieve workloads te verbeteren. U kunt leesworkloads isoleren naar de replica's, terwijl u schrijfworkloads naar de primaire stuurt. U kunt ook leesreplica's in een andere regio implementeren en deze promoveren tot een server voor lezen en schrijven als noodherstel nodig is.

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

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 de overdracht van query's nuttig is en lichte vertraging beheersbaar is. Ze zijn geoptimaliseerd om voor de meeste workloads updates vanaf de primaire server bijna in realtime te leveren, waardoor ze een uitstekende oplossing zijn voor leesintensieve scenario's. 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.

Een replica maken

U kunt een primaire server implementeren voor Azure Database for PostgreSQL flexibele server in elke regio die ondersteuning biedt voor de service. U kunt replica's van de primaire server binnen dezelfde regio of in verschillende globale Azure regio's maken waar Azure Database for PostgreSQL beschikbaar is. U kunt ook replica's maken in sommige Azure regio's in onafhankelijke clouds. Zie het artikel Geo-replicatie voor een lijst met onafhankelijke cloudregio's waar u replica's kunt maken.

Wanneer u de workflow voor het maken van een replica start, wordt er een lege Azure Database for PostgreSQL Flexible Server gemaakt. De nieuwe server wordt gevuld met de gegevens op de primaire server. Voor het maken van replica's in dezelfde regio gebruikt het proces een benadering voor momentopnamen. Daarom is de aanmaaktijd onafhankelijk van de grootte van de gegevens. Geo-replica's worden gemaakt met behulp van de basisback-up van de primaire replica, die vervolgens via het netwerk wordt verzonden. Daarom kan de aanmaaktijd variëren van minuten tot enkele uren, afhankelijk van de primaire grootte.

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

Om een succesvolle creatie te bereiken, vermijd het maken van replica's bij hoge transactionele belasting. Vermijd bijvoorbeeld het maken van replica's bij migraties vanuit andere bronnen naar een Azure Database for PostgreSQL-flexibele server of tijdens zware bulkbelasting. Als u gegevens migreert of grote hoeveelheden gegevens laadt, voltooit u deze taak eerst. Nadat u deze taak 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 parameter voor uw server. 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.

Meer informatie over het maken van een leesreplica.

Configuratiebeheer

Wanneer u leesreplica's instelt voor een Azure Database for PostgreSQL flexibele server, moet u weten welke serverconfiguraties u kunt aanpassen, welke configuraties de replica over neemt van de primaire server en eventuele gerelateerde beperkingen.

Overgenomen configuraties

Wanneer u een leesreplica maakt, neemt deze specifieke serverconfiguraties over van de primaire server. U kunt deze configuraties wijzigen tijdens het maken van de replica of nadat u de replica hebt ingesteld. De leesreplica neemt echter geen specifieke instellingen over, zoals geo-back-up, van de primaire server.

Configuraties tijdens het maken van replica's

• Laag, opslaggrootte: voor de bewerking promoveren naar primaire server moeten de laag en de opslaggrootte overeenkomen met die van de primaire server. Voor de bewerking promoveren tot zelfstandige server en uit replicatie verwijderen kunnen het servicelaagtype en de opslaggrootte gelijk zijn aan of groter zijn dan die van de primaire server.
• Prestatielaag (IOPS): aanpasbaar.
• Gegevensversleuteling: Aanpasbaar, inclusief het verplaatsen van door de service beheerde sleutels naar door de klant beheerde sleutels.

Configuraties na het maken

• Firewallregels: u kunt regels toevoegen, verwijderen of wijzigen.
• Serviceniveau, opslaggrootte: voor de bewerking promoveren naar primaire server moeten het serviceniveau en de opslaggrootte overeenkomen met die van de primaire server. Voor de bewerking promoveren naar onafhankelijke server en uit replicatie verwijderen kunnen het serviceniveau en de opslaggrootte gelijk zijn aan of groter zijn dan die van de primaire server.
• Prestatielaag (IOPS): aanpasbaar.
• Authentication method: Aanpasbare opties omvatten het overschakelen van PostgreSQL-verificatie naar Microsoft Entra.
• Parameters: de meeste parameters zijn aanpasbaar. Degenen die van invloed zijn op de grootte van het gedeelde geheugen , moeten echter worden afgestemd op de primaire server, met name voor mogelijke promotie naar primaire serverscenario's . Voor de bewerking promoveren tot zelfstandige server en verwijderen uit replicatie moeten deze parameters gelijk zijn aan of hoger zijn dan die op de primaire server.
• Onderhoudsschema: Aanpasbaar.

Functies die niet worden ondersteund op leesreplica's

Primaire servers ondersteunen bepaalde functies die u niet kunt instellen voor leesreplica's. Deze functies zijn onder andere:

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

Als uw bron-Azure Database for PostgreSQL flexibele server is versleuteld met door de klant beheerde sleutels, raadpleegt u de documentatie voor andere overwegingen.

Trapsgewijze leesreplica's maken

Trapsgewijze leesreplica's kunnen helpen bij het distribueren van leesworkloads, waardoor de belasting op de primaire server wordt verminderd. Het implementeren van leesreplica's in verschillende regio's (leesreplica's tussen regio's) kan helpen leesverkeer dichter bij gebruikers in verschillende geografische gebieden te verdelen. U kunt trapsgewijze leesreplica's aan de server Azure Database for PostgreSQL toevoegen. Met deze functie kunt u nieuwe leesreplica's maken boven op een bestaande leesreplica, waarbij de bestaande leesreplica fungeert als de bron voor het volgende niveau.

De leesreplica op het eerste niveau repliceert asynchroon gegevens van de primaire server. Vervolgens kunt u een leesreplica op het tweede niveau maken met behulp van de replica op het eerste niveau als bron, die een replicatiehiërarchie met twee lagen vormt. Deze architectuur vergroot de schaalbaarheid en ondersteunt maximaal 30 read-replicaservers, waarbij de primaire server maximaal vijf read-replica's ondersteunt en elk van die replica's vijf extra replica's ondersteunt. Als u een trapsgewijze leesreplica wilt toevoegen aan Azure Database for PostgreSQL flexibele server, selecteert u de bestaande leesreplica (gemaakt op basis van de primaire server), gaat u naar het tabblad Replicatie en selecteert u Replica maken.

Uw primaire server kan bijvoorbeeld maximaal vijf leesreplica's (niveau 1) hebben. Een van deze, bijvoorbeeld read-replica-1, fungeert als de bron voor een andere replica read-replica-2 die deel uitmaakt van (niveau 2).

Belangrijkste overwegingen

• U kunt maximaal vijf leesreplica's per bronleesreplica maken, met ondersteuning voor twee replicatieniveaus.
• De switchoverbewerking ondersteunt een intermediaire leesreplica (bron) en een cascaderende leesreplica.
• Het niveau verhogen naar primaire bewerking biedt geen ondersteuning voor tussenliggende leesreplica's met trapsgewijze leesreplica's.
• Virtuele eindpunten worden niet ondersteund voor trapsgewijze replica's.
• Trapsgewijze leesreplica's worden ondersteund op tussenliggende replica's met PostgreSQL versie 14 en hoger.

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 niet over. U kunt deze regels instellen tijdens het maken van de replica en deze later wijzigen.

De replica neemt het beheerdersaccount over van de primaire server. Alle gebruikersaccounts op de primaire server worden gerepliceerd naar de leeskopieën. U kunt alleen verbinding maken met een leesreplica door gebruik te maken van de gebruikersaccounts die beschikbaar zijn op de primaire server.

U kunt twee methoden gebruiken om verbinding te maken met de replica:

• Rechtstreeks naar de replica: U kunt verbinding maken met de replica met behulp van de hostnaam en een geldig gebruikersaccount, net zoals op een gewone Azure Database for PostgreSQL flexibele server. 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.

Om het verbindingsproces eenvoudiger te maken, biedt de Azure-portal kant-en-klare verbindingsreeksen. U vindt deze verbindingsreeksen op de pagina Verbinding maken . Ze bevatten zowel libpq variabelen als verbindingsreeksen die zijn afgestemd op bash-consoles.

• Via virtuele eindpunten: een alternatieve verbindingsmethode maakt gebruik van virtuele eindpunten. Zie Virtuele eindpunten voor meer informatie. Met behulp van virtuele eindpunten kunt u het alleen-lezeneindpunt configureren om altijd naar de replica te verwijzen, ongeacht welke server momenteel de replicarol heeft.

Replicatie bewaken

De leesreplicafunctie in Azure Database for PostgreSQL maakt gebruik van het mechanisme van replicatieslots. Het belangrijkste voordeel van replicatiesites is dat ze automatisch het aantal transactielogboeken (WAL-segmenten) aanpassen dat vereist is voor alle replicaservers. Deze aanpassing helpt voorkomen dat replica's uit synchronisatie raken, doordat wordt voorkomen dat WAL-segmenten op de primaire server worden verwijderd voordat de replica's deze hebben ontvangen. Het nadeel van deze aanpak is het risico dat er onvoldoende ruimte beschikbaar is op de primaire methode als de replicatiesite gedurende langere tijd inactief blijft. In dergelijke situaties verzamelt de primaire WAL-bestanden, wat incrementele groei van het opslaggebruik veroorzaakt. Wanneer het opslaggebruik 95% bereikt of als de beschikbare capaciteit kleiner is dan 5 GiB, schakelt de server automatisch over naar de modus Alleen-lezen om fouten met betrekking tot schijfvullende situaties te voorkomen.
Daarom is het controleren van de replicatievertraging en de status van replicatieslots cruciaal voor leesreplica's.

Stel waarschuwingsregels in voor opslag die wordt gebruikt of opslagpercentage, en voor replicatievertragingen, wanneer deze 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 transactielogboekopslag gebruikt geeft aan of de accumulatie van WAL-bestanden de belangrijkste reden is voor het overmatige opslaggebruik.

Metrische gegevens bewaken

Azure Database for PostgreSQL service biedt de volgende metrische gegevens voor het bewaken van replicatie.

U kunt verbeterde metrische gegevens gebruiken voor bewaking en waarschuwingen bij leesreplicatie.

Verbeterde metrische gegevens inschakelen

• De meeste van deze nieuwe metrische gegevens zijn standaard uitgeschakeld . Er zijn echter enkele uitzonderingen, die standaard zijn ingeschakeld. De meest rechtse kolom in de volgende tabellen geeft aan of elke metriek standaard is ingeschakeld.
• Om de meetwaarden in te schakelen die niet standaard zijn ingeschakeld, stelt u de parameter metrics.collector_database_activity in op ON. Deze parameter is dynamisch en vereist geen opnieuw opstarten van het exemplaar.

Logische replicatie

Replication

Zie het artikel met instructies voor replica's voor meer informatie.

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 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 Read Replica-vertraging metriek toont de tijd sinds de laatste herhaalde transactie. Als er bijvoorbeeld geen transacties plaatsvinden op uw primaire server en de laatste transactie vijf seconden geleden opnieuw is verwerkt, wordt de vertraging van de leesreplica weergegeven als 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.

Replicatiestatus

Raadpleeg de kolom Replication in de Azure-portal om de voortgang en status van de replicatie te controleren en de bewerking te promoten. 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. Bij het aanroepen van de GetReplica-API wordt de status weergegeven als ReplicationState in de eigenschapstas replica voor gebruikers die afhankelijk zijn van de Azure Resource Manager-API.

Dit zijn de mogelijke waarden:

Meer informatie over het bewaken van replicatie.

Overwegingen

In deze sectie vindt u een samenvatting van overwegingen over de leesreplicafunctie. De volgende overwegingen zijn van toepassing.

• Energiebewerkingen: u kunt energiebewerkingen, inclusief start - en stopacties , toepassen op zowel de primaire als de replicaservers. Als u echter de systeemintegriteit wilt behouden, volgt u een specifieke volgorde. Voordat u de leesreplica's stopt, moet u ervoor zorgen dat eerst de primaire server wordt gestopt. Wanneer bewerkingen worden gestart, start u de startactie op de replicaservers voordat u de primaire server start.
• Als een server leesreplica's heeft, verwijdert u eerst de leesreplica's voordat u de primaire server verwijdert.
• In-place-upgrade naar een nieuwe hoofdversie voor een Azure Database for PostgreSQL Flexible Server vereist dat alle leesreplica's en cascaderende leesreplica's die op de server zijn ingeschakeld, worden verwijderd. Zodra de replica's zijn verwijderd, kunt u de primaire server upgraden naar de gewenste primaire versie. Nadat de upgrade is voltooid, kunt u de replica's opnieuw maken om het replicatieproces te hervatten.
  • 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, niet ondersteund. Als u deze acties wilt uitvoeren, moet u eerst de replicaserver promoveren en vervolgens het wachtwoord op de zojuist gepromoveerde server afzonderlijk bijwerken.

Nieuwe reproducties

U maakt een leesreplica als een nieuwe Azure Database for PostgreSQL Flexible Server. U kunt geen bestaande server in een replica maken.

Resource verplaatsen

U kunt leesreplica's maken in een andere resourcegroep dan de primaire. Het verplaatsen van leesreplica's naar een andere resourcegroep nadat deze zijn gemaakt, wordt echter niet ondersteund. Bovendien wordt het verplaatsen van replica's naar een ander abonnement niet ondersteund. Het verplaatsen van het primaire exemplaar met leesreplica's naar een andere resourcegroep of een ander abonnement wordt niet ondersteund.

Opslag automatisch uitbreiden

Wanneer u leesreplica's configureert voor een Azure Database for PostgreSQL flexibele server, moet u ervoor zorgen dat de instelling voor automatische groei van de 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 autogroei van opslag is ingeschakeld op de primaire server, moet het ook ingeschakeld zijn op de replica's om consistentie in het gedrag van opslagschalen te waarborgen.
• 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 de automatische groei van opslag wilt uitschakelen, moet u dit eerst uitschakelen op de primaire server voordat u dit op de replica's doet om replicatiecomplicaties te vermijden.

Backup maken en terugzetten

Wanneer u back-ups en herstelbewerkingen voor uw Azure Database for PostgreSQL flexibele server beheert, moet u rekening houden met de huidige en vorige rol van de server in verschillende promotiescenario's. Onthoud deze belangrijke punten:

Promoveer naar primaire server

• Geen back-ups van leesreplica's: het systeem maakt nooit back-ups van servers met leesreplica's, ongeacht hun rol in het verleden.
• Behoud van eerdere back-ups: Als een server ooit een primaire server was en het systeem back-ups maakte gedurende die periode, blijven deze back-ups behouden tot de door de gebruiker gedefinieerde bewaarperiode.
• Beperkingen voor herstelbewerkingen: zelfs als er eerdere back-ups bestaan voor een server die overgaat naar een leesreplica, worden herstelbewerkingen beperkt. U kunt alleen een herstelbewerking starten wanneer de server wordt gepromoveerd naar de primaire rol.

Ter duidelijkheid illustreert de volgende tabel de volgende punten:

Promoveer naar onafhankelijke server en verwijderen uit replicatie

Hoewel de server een leesreplica is, maakt het systeem geen back-ups. Zodra u het niveau echter naar een onafhankelijke server promoveert, maakt het systeem back-ups voor zowel de gepromoveerde server als de primaire server. U kunt back-ups op beide servers herstellen.

Networking

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

Deze vereiste vergemakkelijkt niet alleen het synchronisatieproces, maar zorgt ook voor een goede werking van het promotiemechanisme. Replica’s moeten mogelijk in omgekeerde richting communiceren — van replica naar primaire — vooral tijdens bewerkingen waarbij een replica tot primaire wordt gepromoveerd. Bovendien moet u verbindingen met het Azure opslagaccount toestaan waarin Write-Ahead Logboekregistratiearchieven (WAL) worden opgeslagen om de duurzaamheid van gegevens te handhaven en efficiënte herstelprocessen mogelijk te maken.

Zie het artikel 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 in Azure regio's en virtuele netwerken binnen een privénetwerkcontext.

Beperking van problemen met replicatieslot

In zeldzame gevallen kan een hoge vertraging veroorzaakt door replicatieslots leiden tot een verhoogd gebruik van opslagruimte 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.

Het onderhouden van de status en functionaliteit van de primaire server is een prioriteit. In dergelijke uitzonderlijke gevallen kan de server het replicatieslot verwijderen om ervoor te zorgen dat de primaire server operationeel blijft voor lees- en schrijfbewerkingen. Replicatie schakelt dus over naar de verzendmodus voor logboeken op basis van bestanden, wat kan leiden tot een hogere replicatievertraging.

Bewaak het opslaggebruik en de replicatievertraging nauwkeurig en neem de nodige acties om potentiële problemen te beperken voordat ze escaleren.

Parameters

Wanneer u een leesreplica maakt, worden de parameters overgenomen van de primaire server. Deze overname zorgt voor een consistent en betrouwbaar uitgangspunt. Wijzigingen in de parameters op de primaire server die u aanbrengt nadat u de leesreplica hebt gemaakt, 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 gedrag flexibiliteit en aanpassingsopties biedt, vereist het ook zorgvuldig en handmatig beheer om consistentie tussen de primaire en de replica te behouden wanneer uniformiteit van parameters is vereist.

Beheerders kunnen parameters 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, stelt u deze specifieke parameters altijd in op waarden die gelijk zijn aan of groter zijn dan de parameters die zijn geconfigureerd op de primaire server. Voordat u parameterwaarden op een leesreplicaserver verlaagt, moet u ervoor zorgen dat de replicatievertraging minimaal is of dat de replica volledig wordt opgevangen met de primaire server om potentiële replicatie- of herstelproblemen te voorkomen.

Scale

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

Voor het schalen van rekenprocessen:

• Azure Database for PostgreSQL service vereist dat verschillende parameters voor replica's worden greater dan of gelijk aan de instelling op de primaire replica 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 op en schaal vervolgens de primaire op.

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

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

Voor het schalen van opslag:

• Omhoog schalen: schaal eerst de opslagcapaciteit van een replica omhoog en daarna de primaire kopie.

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

Verwante inhoud

• Geo-replicatie in Azure Database for PostgreSQL.
• Promoot leeskopieën in Azure Database voor PostgreSQL.
• Virtualeindpunten voor leesreplica's in Azure Database for PostgreSQL.
• Maak een leesreplica.
• Replicatie over Azure-regio's en virtuele netwerken met privé-netwerken.