Leesreplica's in Azure Database for PostgreSQL - één server

  • Artikel

VAN TOEPASSING OP: Azure Database for PostgreSQL - enkele server

Belangrijk

Azure Database for PostgreSQL - Enkele server bevindt zich op het buitengebruikstellingspad. We raden u ten zeerste aan om een upgrade uit te voeren naar Azure Database for PostgreSQL - Flexible Server. Zie Wat gebeurt er met Azure Database for PostgreSQL Enkele server voor meer informatie over migreren naar Azure Database for PostgreSQL - Flexible Server.

Met de functie leesreplica kunt u gegevens van een Azure Database for PostgreSQL-server repliceren naar een alleen-lezenserver. Replica's worden asynchroon bijgewerkt met de systeemeigen fysieke replicatietechnologie van de PostgreSQL-engine. U kunt repliceren van de primaire server naar maximaal vijf replica's.

Replica's zijn nieuwe servers die u op een soortgelijke manier beheert als gewone 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 tot een lees-/schrijfserver in het geval van herstel na noodgevallen.

Een veelvoorkomend scenario is om BI en analytische werkbelastingen de leesreplica's te laten gebruiken als de gegevensbron voor rapportage.

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

Overwegingen

De functie is bedoeld voor scenario's waarin de vertraging acceptabel is en bedoeld is voor het offloaden van query's. Het is niet bedoeld voor synchrone replicatiescenario's waarbij de replicagegevens naar verwachting up-to-date zijn. Er is een meetbare vertraging tussen de primaire en de replica. Dit kan in minuten of zelfs uren zijn, afhankelijk van de werkbelasting en de latentie tussen de primaire en de replica. 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 vrijwel realtime updates op basis van de primaire server. Persistente, zware en schrijfintensieve primaire workloads kunnen echter zorgen voor langere replicavertraging, waardoor de primaire workload mogelijk nooit meer wordt bijgehaald. Hierdoor kan het opslaggebruik op de primaire server ook toenemen, omdat de WAL-bestanden niet worden verwijderd totdat ze op de replica zijn ontvangen. Als deze situatie voortduurt, kunt u de leesreplica verwijderen en opnieuw maken nadat de schrijfintensieve workloads zijn voltooid, om wat betreft de vertraging de status van de replica weer goed te krijgen. Asynchrone leesreplica's zijn niet geschikt voor dergelijke zware schrijfworkloads. Wanneer u leesreplica's voor uw toepassing evalueert, controleert u de vertraging op de replica voor een volledige werkbelastingscyclus van de app via de piek- en niet-piektijden om toegang te krijgen tot de mogelijke vertraging en de verwachte RTO/RPO op verschillende momenten van de workloadcyclus.

Notitie

Automatische back-ups worden uitgevoerd voor replicaservers die zijn geconfigureerd met een opslagconfiguratie van maximaal 4 TB.

Replicatie in meerdere regio's

U kunt een leesreplica maken in een andere regio dan die van uw primaire server. Replicatie tussen regio's kan handig zijn voor scenario's als het plannen van herstel na noodgeval of het dichter bij uw gebruikers brengen van gegevens.

Notitie

Servers in de Basic-laag ondersteunen alleen replicatie van dezelfde regio.

U kunt een primaire server gebruiken in elke regio met Azure Database for PostgreSQL . Een primaire server kan een replica in de gekoppelde regio of de universele replicaregio's hebben. In de onderstaande afbeelding ziet u welke replicaregio's beschikbaar zijn, afhankelijk van uw primaire regio.

Replicaregio's lezen

Universele replicaregio's

U kunt altijd een leesreplica maken in een van de volgende regio's, ongeacht waar uw primaire server zich bevindt. Dit zijn de universele replicaregio's:

Australië - oost, Australië - zuidoost, Brazilië - zuid, Canada - centraal, Canada - oost, VS - centraal, Azië - oost, VS - oost 2, Japan - oost, Japan - west, Korea - centraal, Korea - zuid, VS - noord-centraal, Europa - noord, VS - zuid- centraal, AZIË - zuidoost, VK - zuid, VK - west, EUROPA - west, VS - west, VS - west 2, VS - west- centraal.

Gekoppelde regio's

Naast de universele replicaregio's kunt u een leesreplica maken in de gekoppelde Azure-regio van uw primaire server. Als u het paar van uw regio niet weet, vindt u meer informatie in het artikel gekoppelde Azure-regio's.

Als u replica's voor meerdere regio's gebruikt voor het plannen van herstel na noodgevallen, raden we u aan om de replica te maken in de gekoppelde regio in plaats van een van de andere regio's. Gekoppelde regio's voorkomen gelijktijdige updates en prioriteren fysieke isolatie en gegevenslocatie.

Er zijn beperkingen om rekening mee te houden:

  • Unidirectionele paren: sommige Azure-regio's worden slechts in één richting gekoppeld. Deze regio's omvatten India - west, Brazilië - zuid. Dit betekent dat een primaire server in India - west een replica kan maken in India - zuid. Een primaire server in India - zuid kan echter geen replica maken in India - west. Dit komt doordat de secundaire regio van India - west India is, maar de secundaire regio van Zuid-India is niet India - west.

Replica's maken

Wanneer u de werkstroom voor het maken van replica's start, wordt er een lege Azure Database for PostgreSQL-server gemaakt. De nieuwe server wordt gevuld met de gegevens die zich op de primaire server bevinden. De aanmaaktijd is afhankelijk van de hoeveelheid gegevens op de primaire server en de tijd sinds de laatste wekelijkse volledige back-up. De tijd kan variëren van enkele minuten tot enkele uren.

Elke replica is ingeschakeld voor automatisch vergroten van opslag. Met de functie voor automatisch vergroten kan de replica de gerepliceerde gegevens bijhouden en voorkomen dat replicatie wordt onderbroken die wordt veroorzaakt door fouten in de opslag.

De functie leesreplica maakt gebruik van fysieke PostgreSQL-replicatie, niet van logische replicatie. Het streamen van replicatie met behulp van replicatiesleuven is de standaardbewerkingsmodus. Indien nodig wordt de back-upfunctie voor logboekbestanden gebruikt om de achterstand in te halen.

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

Als uw PostgreSQL-bronserver is versleuteld met door de klant beheerde sleutels, raadpleegt u de documentatie voor aanvullende overwegingen.

Verbinding maken met een replica

Wanneer u een replica maakt, neemt deze de firewallregels of het VNet-service-eindpunt van de primaire server niet over. De regels moeten onafhankelijk van het replica worden ingesteld.

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.

U kunt verbinding maken met de replica met behulp van de hostnaam en een geldig gebruikersaccount, net als op een gewone Azure Database for PostgreSQL-server. Voor een server met de naam mijn replica 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@myreplica -d postgres

Voer bij de prompt het wachtwoord voor het gebruikersaccount in.

Replicatie bewaken

Azure Database for PostgreSQL biedt twee metrische gegevens voor het bewaken van replicatie. De twee metrische gegevens zijn Max Lag Across Replicas en 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 meetwaarde Max Lag Across Replicas toont de vertraging in bytes tussen de primaire en de meest vertraagde 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 is verbonden met de primaire replica en de primaire zich in de streamingreplicatiemodus bevindt. De vertragingsinformatie geeft geen details weer wanneer de replica bezig is met het inhaalproces van de primaire met behulp van de gearchiveerde logboeken van de primaire in een replicatiemodus voor bestandsverzending.

De metrische waarde replicavertraging toont de tijd sinds de laatste opnieuw afgespeelde transactie. Als er geen transacties plaatsvinden op uw primaire server, weerspiegelt de metrische waarde deze tijdsvertraging. Deze metrische waarde is alleen van toepassing en alleen beschikbaar voor replicaservers. Replicavertraging wordt berekend vanuit de pg_stat_wal_receiver weergave:

SELECT EXTRACT (EPOCH FROM now() - pg_last_xact_replay_timestamp());

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 in bytes 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.

Replicatie stoppen/replica promoveren

U kunt de replicatie tussen een primaire server en een replica op elk moment stoppen. De stopactie zorgt ervoor dat de replica opnieuw wordt opgestart en bevordert dat de replica een onafhankelijke, zelfstandige leesbare server is. De gegevens op de zelfstandige server zijn de gegevens die beschikbaar waren op de replicaserver op het moment dat de replicatie is gestopt. Eventuele volgende updates op de primaire server worden niet doorgegeven aan de replica. De replicaserver kan echter logboeken hebben verzameld die nog niet zijn toegepast. Als onderdeel van het herstartproces past de replica alle in behandeling zijnde logboeken toe voordat clientverbindingen worden geaccepteerd.

Notitie

Het opnieuw instellen van het beheerderswachtwoord op de replicaserver wordt momenteel niet ondersteund. Daarnaast wordt het bijwerken van het beheerderswachtwoord, samen met het verhogen van de replicabewerking 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.

Overwegingen

  • Voordat u de replicatie op een leesreplica stopt, controleert u of de replicatievertraging alle gegevens bevat die u nodig hebt.
  • Omdat de leesreplica alle logboeken in behandeling moet toepassen voordat deze een zelfstandige server kan worden gemaakt, kan RTO hoger zijn voor het schrijven van zware werkbelastingen wanneer de replicatie stopt omdat er een aanzienlijke vertraging op de replica kan optreden. Let op dit wanneer u van plan bent om een replica te promoten.
  • De gepromoveerde replicaserver kan niet opnieuw worden gemaakt in een replica.
  • Als u een replica promoveren naar de primaire server, kunt u geen replicatie naar de oude primaire server tot stand brengen. Als u terug wilt gaan naar de regio van de oude primaire server, kunt u een nieuwe replicaserver met een nieuwe naam maken of de oude primaire server verwijderen en een replica maken met de oude primaire naam.
  • Als u meerdere leesreplica's hebt en een van deze replica's promoveert tot uw primaire server, zijn andere replicaservers nog steeds verbonden met de oude primaire server. Mogelijk moet u replica's opnieuw maken op basis van de nieuwe, gepromoveerde server.

Wanneer u de replicatie stopt, verliest de replica alle koppelingen naar de vorige primaire en andere replica's.

Meer informatie over het stoppen van replicatie naar een replica.

Failover naar replica

In het geval van een fout in de primaire server wordt er niet automatisch een failover uitgevoerd naar de leesreplica.

Omdat replicatie asynchroon is, kan er een aanzienlijke vertraging optreden tussen de primaire en de replica. De hoeveelheid vertraging wordt beïnvloed door een aantal factoren, zoals het type workload dat wordt uitgevoerd op de primaire server en de latentie tussen de primaire en de replicaserver. In typische gevallen met een nominale schrijfworkload wordt een replicavertraging tussen enkele seconden en enkele minuten verwacht. In gevallen waarin de primaire werkbelasting echter zeer zware schrijfintensieve werkbelasting uitvoert en de replica niet snel genoeg inhaalt, kan de vertraging veel hoger zijn. U kunt de replicatievertraging voor elke replica bijhouden met behulp van de metrische replicavertraging. Deze metrische waarde toont de tijd sinds de laatste opnieuw afgespeelde transactie op de replica. U wordt aangeraden de gemiddelde vertraging te identificeren door de replicavertraging gedurende een bepaalde periode te observeren. U kunt een waarschuwing instellen voor replicavertraging, zodat als deze buiten het verwachte bereik valt, u een melding ontvangt om actie te ondernemen.

Tip

Als u een failover naar de replica uitvoert, geeft de vertraging op het moment dat u de replica loskoppelt van de primaire replica aan hoeveel gegevens verloren gaan.

Nadat u hebt besloten dat u een failover naar een replica wilt uitvoeren,

  1. Replicatie naar de replica stoppen
    Deze stap is nodig om ervoor te zorgen dat de replicaserver een zelfstandige server wordt en schrijfbewerkingen kan accepteren. Als onderdeel van dit proces wordt de replicaserver opnieuw opgestart en wordt deze ontkoppeld van de primaire server. Zodra u de replicatie stopt, duurt het back-endproces doorgaans enkele minuten om eventuele restlogboeken toe te passen die nog niet zijn toegepast en om de database te openen als een leesbare server. Zie de sectie stopreplicatie van dit artikel om inzicht te krijgen in de gevolgen van deze actie.

  2. Uw toepassing naar de (voormalige) replica laten wijzen
    Elke server heeft een unieke verbindingsreeks. Werk uw toepassing verbindingsreeks bij zodat deze verwijst naar de (voormalige) replica in plaats van de primaire replica.

Zodra uw toepassing lees- en schrijfbewerkingen heeft verwerkt, hebt u de failover voltooid. De hoeveelheid downtime van uw toepassingservaring is afhankelijk van wanneer u een probleem detecteert en stap 1 en 2 hierboven uitvoert.

Herstel na noodgeval

Wanneer er sprake is van een grote noodgeval, zoals beschikbaarheidszone- of regionale storingen, kunt u herstel na noodgevallen uitvoeren door uw leesreplica te promoten. Vanuit de gebruikersinterfaceportal kunt u naar de leesreplicaserver navigeren. Selecteer vervolgens het replicatietabblad en u kunt de replica stoppen om deze te promoveren tot een onafhankelijke server. U kunt ook de Azure CLI gebruiken om de replicaserver te stoppen en te promoveren.

Overwegingen

In deze sectie vindt u een overzicht van overwegingen over de functie leesreplica.

Vereisten

Leesreplica's en logische decodering zijn beide afhankelijk van het Postgres Write Ahead-logboek (WAL) voor informatie. Deze twee functies hebben verschillende niveaus van logboekregistratie van Postgres nodig. Logische decodering vereist een hoger niveau van logboekregistratie dan leesreplica's.

Als u het juiste niveau van logboekregistratie wilt configureren, gebruikt u de ondersteuningsparameter voor Azure-replicatie. Ondersteuning voor Azure-replicatie heeft drie instellingsopties:

  • Uit - Plaatst de minste informatie in de WAL. Deze instelling is niet beschikbaar op de meeste Azure Database for PostgreSQL-servers.
  • Replica : uitgebreider dan Uit. Dit is het minimale niveau van logboekregistratie dat nodig is om leesreplica's te laten werken. Deze instelling is de standaardinstelling op de meeste servers.
  • Logisch : uitgebreider dan Replica. Dit is het minimale niveau van logboekregistratie voor logische decodering. Leesreplica's werken ook bij deze instelling.

Nieuwe replica's

Er wordt een leesreplica gemaakt als een nieuwe Azure Database for PostgreSQL-server. Een bestaande server kan niet worden gemaakt in een replica. U kunt geen replica van een andere leesreplica maken.

Replicaconfiguratie

Er wordt een replica gemaakt met dezelfde reken- en opslaginstellingen als de primaire. Nadat een replica is gemaakt, kunnen verschillende instellingen worden gewijzigd, waaronder opslag- en back-upretentieperiode.

Firewallregels, regels voor virtuele netwerken en parameterinstellingen worden niet overgenomen van de primaire server naar de replica wanneer de replica wordt gemaakt of later.

Schalen

VCores schalen of tussen Algemeen gebruik en Geoptimaliseerd voor geheugen:

  • PostgreSQL vereist dat de max_connections instelling op een secundaire server groter is dan of gelijk is aan de instelling op de primaire server, anders wordt de secundaire server niet gestart.
  • In Azure Database for PostgreSQL worden de maximaal toegestane verbindingen voor elke server vastgezet aan de reken-sKU omdat verbindingen geheugen in beslag nemen. Meer informatie over de toewijzing tussen max_connections en reken-SKU's.
  • Omhoog schalen: schaal eerst de rekenkracht van een replica omhoog en schaal vervolgens de primaire schaal omhoog. Deze bestelling voorkomt dat fouten de max_connections vereiste schenden.
  • Omlaag schalen: schaal eerst de rekenkracht van de primaire machine omlaag en schaal vervolgens de replica omlaag. Als u de replica lager probeert te schalen dan de primaire replica, treedt er een fout op omdat dit in strijd is met de max_connections vereiste.

Opslag schalen:

  • Voor alle replica's is automatisch vergroten van opslag ingeschakeld om replicatieproblemen van een volledige replica met opslag te voorkomen. Deze instelling kan niet worden uitgeschakeld.
  • U kunt de opslag ook handmatig omhoog schalen, net zoals op elke andere server

De servicelaag Basic

Servers in de Basic-laag ondersteunen alleen replicatie van dezelfde regio.

max_prepared_transactions

PostgreSQL vereist dat de waarde van de max_prepared_transactions parameter op de leesreplica groter is dan of gelijk is aan de primaire waarde. Anders wordt de replica niet gestart. Als u op de primaire server wilt wijzigen max_prepared_transactions , wijzigt u deze eerst op de replica's.

Gestopte replica's

Als u de replicatie tussen een primaire server en een leesreplica stopt, wordt de replica opnieuw opgestart om de wijziging toe te passen. De gestopte replica wordt een zelfstandige server die zowel lees- als schrijfbewerkingen accepteert. De zelfstandige server kan niet opnieuw in een replica worden gemaakt.

Primaire en zelfstandige servers verwijderd

Wanneer een primaire server wordt verwijderd, worden alle leesreplica's zelfstandige servers. De replica's worden opnieuw opgestart om deze wijziging weer te geven.

Volgende stappen