Läs repliker i Azure Database for PostgreSQL – flexibel server

Med funktionen skrivskyddad replik kan du replikera data från en Azure Database for PostgreSQL flexibel server till en skrivskyddad replik. Repliker uppdateras asynkront med postgreSQL-motorns interna fysiska replikeringsteknik. Dataströmsreplikering med replikeringsplatser är standardarbetsläget. Vid behov används filbaserad loggöverföring för att komma ikapp. Du kan replikera från den primära servern till upp till fem repliker.

Repliker är nya servrar som du hanterar på liknande sätt som vanliga Azure Database for PostgreSQL flexibel server. För varje läsreplik betalar du för de etablerade beräkningsresurserna i vCores och lagring i GB per månad.

Lär dig hur du skapar en läsreplik.

När du ska använda en läsreplika

Funktionen läsreplik hjälper till att förbättra prestanda och skala för läsintensiva arbetsbelastningar. Du kan förlägga läsarbetsbelastningar till replikerna och dirigera skrivarbetsbelastningar till primärnoden. Du kan också distribuera läsrepliker i en annan region och uppgradera dem till en läs- och skrivserver om katastrofåterställning behövs.

Ett typiskt scenario är att BI- och analytiska arbetsbelastningar använder läsrepliken som datakälla för rapportering.

Eftersom repliker är skrivskyddade minskar de inte direkt skrivkapacitetsbelastningen på den primära servern.

Överväganden

Läsrepliker är främst utformade för scenarier där avlastning av frågor är fördelaktigt och en liten fördröjning är hanterbar. De är optimerade för att ge uppdateringar i nära realtid från primärnoden för de flesta arbetsbelastningar, vilket gör dem till en utmärkt lösning för läsintensiva arbetsbelastningar. Det är dock viktigt att observera att de inte är avsedda för synkrona replikeringsscenarier som kräver datanoggrannhet upp till minuten. Även om data på repliken med tiden överensstämmer med den primära, kan det finnas en fördröjning som vanligtvis sträcker sig från några sekunder till några minuter, och i scenarier med hög belastning eller längre svarstider kan denna fördröjning sträcka sig till flera timmar. Normalt har läsrepliker i samma region som den primära mindre fördröjning än geo-repliker, eftersom de senare ofta hanterar geografisk avståndsinducerad svarstid. Mer information om prestandakonsekvenserna av geo-replikering finns i artikeln Geo-replikering . Data på repliken blir så småningom konsekvent med data på den primära servern. Använd den här funktionen för arbetsbelastningar som kan hantera den här fördröjningen.

Skapa en replik

Du kan distribuera en primär server för Azure Database for PostgreSQL flexibel server i alla regioner som stöder tjänsten. Du kan skapa repliker av den primära servern i samma region eller i olika globala Azure regioner där Azure Database for PostgreSQL är tillgängligt. Du kan också skapa repliker i vissa Azure-regioner i suveräna moln. En lista över nationella molnregioner där du kan skapa repliker finns i artikeln Geo-replikering .

När du startar arbetsflödet för att skapa repliker skapar processen en tom Azure Database for PostgreSQL flexibel server. Den nya servern fylls med data på den primära servern. För att skapa repliker i samma region använder processen en metod för ögonblicksbilder. Därför är tidpunkten för skapandet oberoende av datastorleken. Georepliker skapas utifrån grundsäkerhetskopian av den primära servern, som sedan överförs via nätverket. Skapandetiden kan därför variera från minuter till flera timmar, beroende på den primära storleken.

En replik anses endast ha skapats när två villkor uppfylls: hela säkerhetskopieringen av den primära kopieras till repliken och transaktionsloggarna synkroniseras med högst 1 GB fördröjning.

Undvik att skapa repliker under tider med hög transaktionsbelastning för att uppnå en lyckad skapandeåtgärd. Undvik till exempel att skapa repliker när du migrerar från andra källor till en Azure Database for PostgreSQL flexibel server eller under stora massbelastningsåtgärder. Om du migrerar data eller läser in stora mängder data slutför du den här uppgiften först. När du har slutfört det kan du sedan börja konfigurera replikerna. När migreringen eller massinläsningen är klar kontrollerar du om transaktionsloggens storlek har återgåt till sin normala storlek. Transaktionsloggens storlek bör vanligtvis ligga nära det värde som definierats i parametern max_wal_size för servern. Du kan spåra transaktionsloggens lagringsfotavtryck med hjälp av måttet Transaktionslogglagring som används , vilket ger insikter om hur mycket lagringsutrymme som används av transaktionsloggen. Genom att övervaka det här måttet kan du se till att transaktionsloggens storlek ligger inom det förväntade intervallet och att processen för att skapa repliken kan starta.

Lär dig hur du skapar en läsreplik.

Konfigurationshantering

När du konfigurerar skrivskyddade repliker för en Azure Database for PostgreSQL flexibel server måste du förstå vilka serverkonfigurationer du kan justera, vilka konfigurationer repliken ärver från den primära servern och eventuella relaterade begränsningar.

Ärvda konfigurationer

När du skapar en läsreplik ärver den specifika serverkonfigurationer från den primära servern. Du kan ändra dessa konfigurationer när repliken skapas eller när du har konfigurerat repliken. Läsrepliken ärver dock inte specifika inställningar, till exempel geo-säkerhetskopiering, från den primära servern.

Konfigurationer när replik skapas

• Nivå, lagringsstorlek: För åtgärden flytta upp till primär server måste nivån och lagringsstorleken matcha den primära servern. Om du vill flytta upp till en oberoende server och ta bort från replikeringsåtgärden kan nivån och lagringsstorleken matcha eller överskrida den primära servern.
• Prestandanivå (IOPS): Justerbar.
• Datakryptering: Justerbar, inklusive flytt från tjänsthanterade nycklar till kundhanterade nycklar.

Konfigurationer efter skapandet

• Brandväggsregler: Du kan lägga till, ta bort eller ändra regler.
• Nivå, lagringsstorlek: För åtgärden flytta upp till primär server måste nivån och lagringsstorleken matcha den primära servern. Om du vill flytta upp till en oberoende server och ta bort från replikeringsåtgärden kan nivån och lagringsstorleken matcha eller överskrida den primära servern.
• Prestandanivå (IOPS): Justerbar.
• Authentication-metoden: Justerbara alternativ är att växla från PostgreSQL-autentisering till Microsoft Entra.
• Parametrar: De flesta parametrar är justerbara. De som påverkar storleken på det delade minnet bör dock vara i linje med primärservern, särskilt vid potentiell befordran till primärserver. För att höja upp till oberoende server och ta bort från replikeringsåtgärden bör dessa parametrar matcha eller överskrida dem på den primära servern.
• Underhållsschema: Justerbart.

Funktioner som inte stöds för läsrepliker

Primära servrar stöder vissa funktioner som du inte kan konfigurera på läsrepliker. Dessa funktioner omfattar:

• Säkerhetskopior, inklusive geo-säkerhetskopior.
• Hög tillgänglighet (HA).

Om källan Azure Database for PostgreSQL flexibel server krypteras med kundhanterade nycklar kan du läsa dokumentationen för andra överväganden.

Skapa sammanhängande läsrepliker

Sammanhängande läsrepliker kan hjälpa till att distribuera läsarbetsbelastningar, vilket minskar belastningen på den primära servern. Om du distribuerar läsrepliker i olika regioner (läsrepliker mellan regioner) kan du distribuera lästrafik närmare användare i olika geografiska områden. Du kan lägga till sammanhängande läsrepliker till Azure Database for PostgreSQL server. Med den här funktionen kan du skapa nya läsrepliker med utgångspunkt i en befintlig läsreplik, där den befintliga läsrepliken fungerar som källa för nästa nivå.

Den första läsrepliken replikerar asynkront data från den primära servern. Du kan sedan skapa en läsreplik på den andra nivån med hjälp av repliken på den första nivån som källa, vilket skapar en replikeringshierarki på två nivåer. Den här arkitekturen ökar skalbarheten och stöder upp till 30 läsrepliker, där den primära servern stöder upp till fem läsrepliker och var och en av dessa repliker stöder ytterligare fem läsrepliker. Om du vill lägga till en sammanhängande skrivskyddad replik till Azure Database for PostgreSQL flexibel server väljer du den befintliga skrivskyddade repliken (skapad från den primära servern), går till fliken Replikering och väljer Skapa replik.

Din primära server kan till exempel ha upp till fem läsrepliker (nivå 1). En av dessa, till exempel read-replica-1, fungerar som källa för en annan replik read-replica-2 som blir en del av (nivå 2).

Viktiga överväganden

• Du kan skapa upp till fem läsrepliker per källläsningsreplik, med stöd för två replikeringsnivåer.
• Växlingsåtgärden stöder mellanliggande läsreplik (källa) och sammanhängande läsreplik.
• Uppflyttad till primär åtgärd stöder inte mellanliggande läsrepliker med sammanhängande läsrepliker.
• Virtuella slutpunkter stöds inte för sammanhängande repliker.
• Sammanhängande läsrepliker stöds på mellanliggande repliker med PostgreSQL version 14 och senare.

Ansluta till en replik

När du skapar en replik ärver den inte brandväggsreglerna eller tjänstslutpunkten för det virtuella nätverket på den primära servern. Du kan ange dessa regler när repliken skapas och ändra dem senare.

Repliken ärver administratörskontot från den primära servern. Alla användarkonton på den primära servern replikeras till läsrepliker. Du kan endast ansluta till en läsreplik genom att använda de användarkonton som är tillgängliga på den primära servern.

Du kan använda två metoder för att ansluta till repliken:

• Direkt till repliken: Du kan ansluta till repliken med dess värdnamn och ett giltigt användarkonto, precis som på en vanlig Azure Database for PostgreSQL flexibel server. För en server med namnet myreplica med administratörsanvändarnamnet myadmin kan du ansluta till repliken med hjälp psqlav :

psql -h myreplica.postgres.database.azure.com -U myadmin postgres

Ange lösenordet för användarkontot när du uppmanas att göra det.

För att göra anslutningsprocessen enklare tillhandahåller Azure portalen anslutningssträngar som är redo att användas. Du hittar dessa anslutningssträngar på sidan Anslut . De omfattar både libpq variabler och anslutningssträngar som är skräddarsydda för bash-konsoler.

• Via virtuella slutpunkter: En alternativ anslutningsmetod använder virtuella slutpunkter. Mer information finns i Virtuella slutpunkter. Genom att använda virtuella slutpunkter kan du konfigurera den skrivskyddade slutpunkten så att den alltid pekar på repliken, oavsett vilken server som för närvarande innehar replikrollen.

Övervaka replikering

Funktionen för läsreplik i Azure Database for PostgreSQL bygger på mekanismen med replikeringsplatser. Den största fördelen med replikeringsplatser är att de automatiskt justerar antalet transaktionsloggar (WAL-segment) som krävs av alla replikservrar. Den här justeringen hjälper till att förhindra att repliker blir osynkroniserade eftersom de undviker att ta bort WAL-segment på den primära innan replikerna tar emot dem. Nackdelen med den här metoden är risken att det tar slut på utrymme på den primära platsen om replikeringsplatsen förblir inaktiv under en längre tid. I sådana situationer ackumulerar den primära WAL-filer, vilket orsakar inkrementell ökning av lagringsanvändningen. När lagringsanvändningen når 95% eller om den tillgängliga kapaciteten är mindre än 5 GiB växlar servern automatiskt till skrivskyddat läge för att undvika fel som är associerade med diskfyllda situationer.
Därför är det viktigt att övervaka replikeringsfördröjningen och replikeringsslotsstatusen för läsreplikor.

Ange aviseringsregler för lagring som används eller lagringsprocent, och för replikeringsfördröjningar, när de överskrider vissa tröskelvärden så att du proaktivt kan agera, öka lagringsstorleken och ta bort eftersläpande läsrepliker. Du kan till exempel ange en avisering om lagringsprocenten överskrider 80 % användning och om replikfördröjningen är högre än 5 minuter. Måttet Transaction Log Storage Used visar dig om ackumuleringen av WAL-filer är den främsta orsaken till den överdrivna lagringsanvändningen.

Övervaka metrik

Azure Database for PostgreSQL-tjänsten innehåller följande mått för övervakning av replikering.

Du kan använda förbättrade mått för övervakning och avisering vid läsreplikering.

Aktivera förbättrade mätvärden

• De flesta av dessa nya mått är inaktiverade som standard. Det finns dock några undantag som är aktiverade som standard. Kolumnen längst till höger i följande tabeller anger om varje mått är aktiverat som standard eller inte.
• Om du vill aktivera de mått som inte är aktiverade som standard anger du parametern metrics.collector_database_activity till ON. Den här parametern är dynamisk och kräver ingen omstart av instansen.

Logisk replikering

Replication

För att lära dig mer, se artikeln om hur man använder läs repliker.

Måttet Maximal fysisk replikeringsfördröjning visar fördröjningen i byte mellan den primära och den replik som släpar efter mest. Det här mätvärdet är endast tillämpligt och tillgängligt på den primära servern och är endast tillgängligt om minst en av läsreplikerna är ansluten till den primära servern. Fördröjningsinformationen finns också när repliken håller på att komma ikapp den primära, när repliken skapas eller när replikeringen blir inaktiv.

Måttet Read Replica Lag visar tiden sedan den senaste omspelade transaktionen. Om det till exempel inte sker några transaktioner på den primära servern och den senaste transaktionen återspelades för 5 sekunder sedan, visar fördröjning för läsreplik en fördröjning på 5 sekunder. Detta mått är endast tillämpligt och tillgängligt för repliker.

Ange en avisering som informerar dig när replikfördröjningen når ett värde som inte är acceptabelt för din arbetsbelastning.

Om du vill ha mer information kan du fråga den primära servern direkt för att få replikeringsfördröjningen på alla repliker.

Replikeringstillstånd

Om du vill övervaka förloppet och statusen för replikerings- och upphöjningsåtgärden läser du kolumnen Replication i Azure-portalen. Den här kolumnen finns på replikeringssidan och visar olika tillstånd som ger insikter om det aktuella villkoret för de lästa replikerna och deras länk till den primära. För användare som förlitar sig på Azure Resource Manager-API:et visas tillståndet som ReplicationState i egenskapsuppsättningen GetReplica när du anropar replica API.

Här är de möjliga värdena:

Lär dig hur du övervakar replikering.

Överväganden

I det här avsnittet sammanfattas överväganden kring läsreplikfunktionen. Följande överväganden gäller.

• Energiåtgärder: Du kan använda energiåtgärder, inklusive start - och stoppåtgärder , på både de primära servrarna och replikservrarna. Följ dock en specifik sekvens för att bevara systemintegriteten. Innan du stoppar läsrepliker kontrollerar du att den primära servern är stoppad först. När åtgärder påbörjas startar du startåtgärden på replikservrarna innan du startar den primära servern.
• Om en server har läsrepliker tar du först bort de lästa replikerna innan du tar bort den primära servern.
• Uppgradering på plats av huvudversion för en flexibel Azure Database for PostgreSQL-server kräver att alla läsrepliker och kaskadkopplade läsrepliker som är aktiverade på servern tas bort. När replikerna har tagits bort kan du uppgradera den primära servern till önskad huvudversion. När uppgraderingen är klar kan du återskapa replikerna för att återuppta replikeringen.
  • Återställa administratörslösenord: Återställning av administratörslösenordet på replikservern stöds inte för närvarande. Dessutom stöds inte uppdatering av administratörslösenordet tillsammans med att främja replikåtgärden i samma begäran. Om du vill utföra dessa åtgärder ska du först höja upp replikservern och sedan uppdatera lösenordet på den nyligen upphöjda servern separat.

Nya repliker

Du skapar en läsreplik som en ny Azure Database for PostgreSQL – Flexibel server. Du kan inte göra en befintlig server till en replik.

Resursflytt

Du kan skapa skrivskyddade repliker i en annan resursgrupp än den primära. Det går dock inte att flytta läsrepliker till en annan resursgrupp när de har skapats. Dessutom stöds inte flytt av repliker till en annan prenumeration. Det stöds inte att flytta den primära med läsrepliker till en annan resursgrupp eller prenumeration.

Automatisk lagringstillväxt

När du konfigurerar läsrepliker för Azure Database for PostgreSQL – Flexibel server ser du till att inställningen för automatisk lagringsökning på replikerna motsvarar inställningen på den primära servern. Funktionen för automatisk lagringsåterväxt gör att databaslagringen kan öka automatiskt för att förhindra slut på utrymme, vilket kan leda till databasfel. Så här hanterar du inställningarna för automatisk tillväxt av lagring effektivt:

• Du kan aktivera automatisk lagringsväxning på valfri replik oavsett den primära serverns inställning.
• Om automatisk tillväxt av lagringsutrymme är aktiverat på den primära servern måste det också vara aktiverat på replikerna för att säkerställa konsekvent lagringsskalning.
• Om du vill aktivera automatisk lagringsväxning på den primära filen måste du först aktivera den på replikerna. Den här ordningen på åtgärder är avgörande för att upprätthålla replikeringsintegriteten.
• Om du däremot vill inaktivera automatisk lagringsåterväxt börjar du med att inaktivera den på den primära servern före replikerna för att undvika replikeringskomplikationer.

Säkerhetskopiera och återställ

När du hanterar säkerhetskopior och återställningar för din Azure Database for PostgreSQL flexibla servern bör du tänka på serverns aktuella och tidigare roll i olika uppflyttningsscenarier. Kom ihåg följande viktiga punkter:

Flytta upp till primär server

• Inga säkerhetskopior från läsrepliker: Systemet tar aldrig säkerhetskopior från läsreplikservrar, oavsett deras tidigare roll.
• Bevarande av tidigare säkerhetskopior: Om en server en gång var primär och systemet tog säkerhetskopior under den perioden bevaras dessa säkerhetskopior upp till den användardefinierade kvarhållningsperioden.
• Begränsningar för återställningsåtgärd: Även om det finns tidigare säkerhetskopior för en server som övergår till en läsreplik begränsas återställningsåtgärderna. Du kan bara initiera en återställningsåtgärd när servern befordras tillbaka till den primära rollen.

För tydlighetens skull illustrerar följande tabell dessa punkter:

Flytta upp till oberoende server och ta bort från replikering

Även om servern är en läsreplik tar systemet inte säkerhetskopior. Men när du befordrar den till en oberoende server, tar systemet säkerhetskopior för både den upphöjda servern och den primära servern. Du kan återställa säkerhetskopior på båda servrarna.

Nätverkande

Läsrepliker har stöd för alla nätverksalternativ som Azure Database for PostgreSQL – Flexibel server har stöd för.

Det här kravet underlättar inte bara synkroniseringsprocessen utan säkerställer också att upphöjningsmekanismen fungerar korrekt. Repliker kan behöva kommunicera i omvänd ordning – från repliken till primären – särskilt vid åtgärder för att uppgradera till primär. Dessutom måste du tillåta anslutningar till det Azure lagringskonto som lagrar wal-arkiv (Write-Ahead Loggning) för att upprätthålla datahållbarhet och möjliggöra effektiva återställningsprocesser.

Mer information om hur du konfigurerar privat åtkomst (integrering av virtuellt nätverk) för dina läsrepliker och förstå konsekvenserna för replikering i Azure regioner och virtuella nätverk i en privat nätverkskontext finns i artikeln Replikering över Azure regioner och virtuella nätverk med privata nätverk.

Åtgärder för replikationsplatsproblem

I sällsynta fall kan hög fördröjning som orsakas av replikeringsfack leda till ökad lagringsanvändning på den primära servern på grund av ackumulerade WAL-filer. Om lagringsanvändningen når 95 % eller om den tillgängliga kapaciteten understiger 5 GiB växlar servern automatiskt till skrivskyddat läge för att förhindra disk full-fel.

Att underhålla den primära serverns hälsa och funktioner är en prioritet. I sådana gränsfall kan servern släppa replikeringsplatsen för att säkerställa att den primära servern förblir i drift för läs- och skrivtrafik. Replikeringen växlar därför till filbaserat loggleveransläge, vilket kan leda till en högre replikeringsfördröjning.

Övervaka lagringsanvändningen och replikeringsfördröjningen noggrant och vidta nödvändiga åtgärder för att minimera potentiella problem innan de eskaleras.

Parameters

När du skapar en läsreplik ärver den parametrarna från den primära servern. Det här arvet garanterar en konsekvent och tillförlitlig startpunkt. Ändringar av parametrarna på den primära servern som du gör när du har skapat läsrepliken replikeras dock inte automatiskt. Det här beteendet ger fördelen med individuell justering av läsrepliken, till exempel att förbättra dess prestanda för läsintensiva åtgärder utan att ändra den primära serverns parametrar. Även om det här beteendet ger flexibilitets- och anpassningsalternativ, krävs även noggrann och manuell hantering för att upprätthålla konsekvens mellan den primära och dess replik när parametrarnas enhetlighet krävs.

Administratörer kan ändra parametrar på den skrivskyddade replikservern och ange andra värden än på den primära servern. Det enda undantaget är parametrar som kan påverka återställningen av repliken, som även nämns i avsnittet "Skalning" nedan: max_connections, max_prepared_transactions, max_locks_per_transaction, max_wal_senders, max_worker_processes. För att säkerställa att återställningen av läsrepliken är sömlös och inte stöter på begränsningar för delat minne anger du alltid dessa specifika parametrar till värden som antingen motsvarar eller är större än de som konfigurerats på den primära servern. Innan du sänker parametervärdena på en skrivskyddad replikserver kontrollerar du att replikeringsfördröjningen är minimal eller att repliken är helt ikapp den primära servern för att undvika potentiella replikerings- eller återställningsproblem.

Scale

Du kan skala upp och ned beräkning (virtuella kärnor), ändra tjänstnivån från Generell användning till Minnesoptimerad (eller vice versa) och skala upp lagringen. Följande varningar gäller dock.

För skalning av beräkningskapacitet:

• Azure Database for PostgreSQL-tjänsten kräver att flera parametrar på repliker är greater än eller lika med inställningen för den primära för att säkerställa att repliken inte får slut på delat minne under återställningen. De berörda parametrarna är: max_connections, max_prepared_transactions, max_locks_per_transaction, max_wal_senders, max_worker_processes.

• Skala upp: Skala först upp en replikas beräkningskapacitet och sedan skala upp den primära.

• Skala ned: Skala först ned den primära datorresursen och skala sedan ned kopian.

• Beräkningskapaciteten på primärnoden måste alltid vara mindre än eller lika med beräkningskapaciteten på den minsta replikan.

För att skala lagring

• Skala upp: Skala först upp lagringen på en replika och därefter den primära.

• Lagringsstorleken på den primära måste alltid vara lika med eller mindre än lagringsstorleken på den minsta repliken.

Relaterat innehåll

• Geo-replikering i Azure Database for PostgreSQL.
• Promote läsrepliker i Azure Database for PostgreSQL.
• Virtuella slutpunkter för läsrepliker i Azure Database for PostgreSQL.
• Skapa en läsreplik.
• Replikering i Azure regioner och virtuella nätverk med privata nätverk.