Skrivskyddade repliker i Azure Database for PostgreSQL – flexibel server

GÄLLER FÖR: Azure Database for PostgreSQL – flexibel server

Med funktionen skrivskyddad replik kan du replikera data från en flexibel Azure Database for PostgreSQL-serverinstans till en skrivskyddad replik. Repliker uppdateras asynkront med PostgreSQL-motorns inbyggda 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 flexibla Azure Database for PostgreSQL-serverinstanser. För varje läsreplik debiteras du för den etablerade beräkningen i virtuella kärnor och lagring i GB/månad.

Lär dig hur du skapar och hanterar repliker.

När du ska använda en skrivskyddad replik

Funktionen med skrivskyddade repliker bidrar till att förbättra prestanda och skalning för läsintensiva arbetsbelastningar. Läsarbetsbelastningar kan isoleras till replikerna, medan skrivarbetsbelastningar kan dirigeras till den primära servern. Läsrepliker kan också distribueras i en annan region och kan höjas upp till en skrivskyddad server om haveriberedskap krä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.

Att tänka på

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 tillhandahålla uppdateringar i nära realtid från den primära för de flesta arbetsbelastningar, vilket gör dem till en utmärkt lösning för läsintensiva scenarier. 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 så småningom blir konsekventa med den primära, kan det finnas en fördröjning, som vanligtvis sträcker sig från några sekunder till minuter, och i vissa scenarier med hög arbetsbelastning eller långa svarstider kan den här fördröjningen sträcka sig till 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 konsekventa med data på den primära. Använd den här funktionen för arbetsbelastningar som kan hantera den här fördröjningen.

Skapa en replik

En primär server för Azure Database for PostgreSQL – flexibel server kan distribueras i valfri region 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– flexibel server är tillgänglig. Möjligheten att skapa repliker utökas nu till vissa särskilda Azure-regioner. Se artikeln Geo-replikering för en lista över särskilda regioner där du kan skapa repliker.

När du startar arbetsflödet för att skapa replik skapas en tom flexibel Azure Database for PostgreSQL-serverinstans. Den nya servern fylls med data på den primära servern. För att skapa repliker i samma region används en metod för ögonblicksbilder. Därför är tidpunkten för skapandet oberoende av datastorleken. Geo-repliker skapas med bassäkerhetskopian av den primära instansen, som sedan överförs över nätverket. Därför kan skapandetiden variera från minuter till flera timmar, beroende på den primära storleken.

Repliken anses endast ha skapats när två villkor uppfylls: hela säkerhetskopieringen av den primära instansen måste kopieras till repliken och transaktionsloggarna får 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. Du bör till exempel undvika att skapa repliker när du migrerar från andra källor till en flexibel Azure Database for PostgreSQL-server eller vid hög massbelastning. Om du migrerar data eller läser in stora mängder data just nu är det bäst att slutföra 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 har slutförts kontrollerar du om transaktionsloggens storlek har återställts till sin normala storlek. Normalt bör transaktionsloggens storlek ligga nära det värde som definierats i max_wal_size-serverparametern för din instans. Du kan spåra transaktionsloggens lagringsfotavtryck med hjälp av måttet Transaktionslogglagring används , vilket ger insikter om mängden lagring 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 startas.

Lär dig hur du skapar en skrivskyddad replik i Azure-portalen.

Konfigurationshantering

När du konfigurerar läsrepliker för en flexibel Azure Database for PostgreSQL-server är det viktigt att du förstår de serverkonfigurationer som kan justeras, de som ärvs från den primära servern och eventuella relaterade begränsningar.

Ärvda konfigurationer

När en läsreplik skapas ärver den specifika serverkonfigurationer från den primära servern. Dessa konfigurationer kan ändras antingen när repliken skapas eller när den har konfigurerats. Specifika inställningar, till exempel geo-säkerhetskopiering, replikeras dock inte till läsrepliken.

Konfigurationer när replik skapas

• Nivå, lagringsstorlek: För åtgärden "befordra till primär server" måste den vara samma som den primära. För åtgärden "befordra till oberoende server och ta bort från replikering" kan den vara samma eller högre än den primära.
• Prestandanivå (IOPS): Justerbar.
• Datakryptering: Justerbar, inkludera flytt från tjänsthanterade nycklar till kundhanterade nycklar.

Konfigurationer efter skapandet

• Brandväggsregler: Kan läggas till, tas bort eller ändras.
• Nivå, lagringsstorlek: För åtgärden "befordra till primär server" måste den vara samma som den primära. För åtgärden "befordra till oberoende server och ta bort från replikering" kan den vara samma eller högre än den primära.
• Prestandanivå (IOPS): Justerbar.
• Autentiseringsmetod: Justerbara alternativ omfattar växling från PostgreSQL-autentisering till Microsoft Entra.
• Serverparametrar: De flesta är justerbara. De som påverkar den delade minnesstorleken bör dock överensstämma med den primära, särskilt för potentiella scenarier med "flytta upp till primär server". För åtgärden "befordra till oberoende server och ta bort från replikering" bör dessa parametrar vara desamma eller överskrida dem i den primära.
• Underhållsschema: Justerbart.

Funktioner som inte stöds på läsrepliker

Vissa funktioner är begränsade till primära servrar och kan inte konfigureras på läsrepliker. Dessa kan vara:

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

Om din azure database for PostgreSQL-källinstans för flexibel server krypteras med kundhanterade nycklar kan du läsa dokumentationen för andra överväganden.

Ansluta till en replik

När du skapar en replik ärver den brandväggsreglerna eller tjänstslutpunkten för det virtuella nätverket på den primära servern. Dessa regler kan ändras när repliken skapas och vid en senare tidpunkt.

Repliken ärver administratörskontot från den primära servern. Alla användarkonton på den primära servern replikeras till skrivskyddade repliker. Du kan bara ansluta till en skrivskyddad replik med hjälp av de användarkonton som är tillgängliga på den primära servern.

Det finns två metoder för att ansluta till repliken:

• Direkt till replikinstansen: Du kan ansluta till repliken med dess värdnamn och ett giltigt användarkonto, precis som på en vanlig flexibel Azure Database for PostgreSQL-serverinstans. 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 underlätta anslutningsprocessen tillhandahåller Azure-portalen dessutom färdiga niska veze. Dessa finns på sidan Anslut . De omfattar både libpq variabler och niska veze som är skräddarsydda för bash-konsoler.

• Via virtuella slutpunkter: Det finns en alternativ anslutningsmetod med hjälp av virtuella slutpunkter, som beskrivs i artikeln Virtuella slutpunkter . Genom att använda virtuella slutpunkter kan du konfigurera den skrivskyddade slutpunkten så att den konsekvent pekar på repliken, oavsett vilken server som för närvarande har replikrollen.

Övervaka replikering

Läsreplikfunktionen i Azure Database for PostgreSQL – flexibel server förlitar sig på mekanismen för replikeringsfack. Den största fördelen med replikeringsplatser är att de automatiskt justerar antalet transaktionsloggar (WAL-segment) som krävs av alla replikservrar. Detta förhindrar att repliker blir osynkroniserade eftersom de undviker att ta bort WAL-segment på den primära innan de skickas till replikerna. Nackdelen med metoden är risken att gå ut ur utrymme på den primära om replikeringsplatsen förblir inaktiv under en längre tid. I sådana situationer ackumulerar primärt WAL-filer som 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äxlas 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 replikeringsfackstatusen för läsrepliker.

Vi rekommenderar att du anger 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.

Azure Database for PostgreSQL – flexibel server innehåller två mått för övervakning av replikering. De två måtten är Maximal fysisk replikeringsfördröjning och Läsreplikfördröjning. Information om hur du visar dessa mått finns i avsnittet Övervaka en replik i artikeln läsreplik.

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åttet är endast tillämpligt och tillgängligt på den primära servern och är endast tillgängligt om minst en av skrivskyddade repliker ä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 spelades upp för 5 sekunder sedan, visar fördröjningen för Skrivskyddad replik 5 sekunder. Det här måttet är endast tillämpligt och tillgängligt på 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 uppflyttingsåtgärden läser du kolumnen Replikeringstillstånd 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 GetReplica visas tillståndet som ReplicationState i egenskapspåsen när du anropar API:et replica .

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

Lär dig hur du övervakar replikering.

Att tänka på

I det här avsnittet sammanfattas överväganden om funktionen för läsreplik. Följande överväganden gäller.

• Energiåtgärder: Energiåtgärder, inklusive start- och stoppåtgärder, kan tillämpas på både primära servrar och replikservrar. Men för att bevara systemintegriteten bör en specifik sekvens följas. Innan du stoppar skrivskyddade repliker kontrollerar du att den primära servern stoppas först. När åtgärder påbörjas startar du startåtgärden på replikservrarna innan du startar den primära servern.
• Om servern har läsrepliker bör skrivskyddade repliker tas bort först innan den primära servern tas bort.
• På plats högre version uppgradering i Azure Database for PostgreSQL flexibel server kräver att ta bort alla skrivskyddade repliker som för närvarande är aktiverade på servern. När replikerna har tagits bort kan den primära servern uppgraderas till önskad huvudversion. När uppgraderingen är klar kan du återskapa replikerna för att återuppta replikeringen.
• Premium SSD v2: Från och med den aktuella versionen stöds inte skapandet av läsrepliker om den primära servern använder Premium SSD v2 för lagring.
• Återställa administratörslösenord: Återställning av administratörslösenordet på replikservern stöds för närvarande inte. Dessutom stöds inte heller uppdatering av administratörslösenordet tillsammans med att främja replikåtgärden i samma begäran. Om du vill göra detta måste du först höja upp replikservern och sedan uppdatera lösenordet på den nyligen upphöjda servern separat.

Nya repliker

En läsreplik skapas som en ny flexibel Azure Database for PostgreSQL-serverinstans. Det går inte att göra en befintlig server till en replik. Du kan inte skapa en replik av en annan skrivskyddad replik, dvs. sammanhängande replikering stöds inte.

Resursflytt

Användare 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 att flytta repliker till en annan prenumeration och flytta den primära som har läsrepliker till en annan resursgrupp eller prenumeration.

Automatisk lagringsbrytning

När du konfigurerar läsrepliker för en flexibel Azure Database for PostgreSQL-serverinstans är det viktigt att se till att inställningen för automatisk lagringsväxning på replikerna matchar den primära serverns. 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ällningar för automatisk lagring automatiskt:

• Du kan aktivera automatisk lagringsväxning på valfri replik oavsett den primära serverns inställning.
• Om automatisk lagringsbrytning är aktiverat på den primära servern måste det också vara aktiverat på replikerna för att säkerställa konsekvens i lagringsskalningsbeteenden.
• 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älla

När du hanterar säkerhetskopior och återställningar för din flexibla Serverinstans i Azure Database for PostgreSQL är det viktigt att komma ihåg serverns aktuella och tidigare roll i olika marknadsföringsscenarier. Här är de viktigaste punkterna att komma ihåg:

Flytta upp till primär server

1. Inga säkerhetskopior hämtas från läsrepliker: Säkerhetskopior tas aldrig från skrivskyddade replikservrar, oavsett deras tidigare roll.

2. Bevarande av tidigare säkerhetskopior: Om en server en gång var en primär och har säkerhetskopior som gjorts under den perioden bevaras dessa säkerhetskopior. De behålls upp till den användardefinierade kvarhållningsperioden.

3. Begränsningar för återställningsåtgärd: Även om det finns tidigare säkerhetskopior för en server som har övergått till en läsreplik begränsas återställningsåtgärderna. Du kan bara initiera en återställningsåtgärd när servern har befordrats tillbaka till den primära rollen.

För tydlighetens skull, här är en tabell som illustrerar dessa punkter:

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

Servern är en läsreplik, men inga säkerhetskopior görs. Men när den har befordrats till en oberoende server har både den upphöjda servern och den primära servern säkerhetskopieringar och återställningar tillåts på båda.

Nätverk

Läsrepliker stöder alla nätverksalternativ som stöds av Azure Database for PostgreSQL – flexibel server.

Ovanstående krav underlättar inte bara synkroniseringsprocessen utan säkerställer också att uppflyttningsmekanismen fungerar korrekt där repliker kan behöva kommunicera i omvänd ordning – från replik till primär – särskilt under uppflyttning till primära åtgärder. Dessutom måste anslutningar till Azure Storage-kontot som lagrar WAL-arkiv (Write-Ahead Logging) tillåtas 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 på sidan Replikering mellan Azure-regioner och virtuella nätverk med privata nätverk .

Problem med replikeringsfack

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.

Eftersom det är en prioritet att underhålla den primära serverns hälsa och funktioner, kan replikeringsplatsen i sådana fall tas bort 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.

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

Serverparametrar

När en läsreplik skapas ärver den serverparametrarna från den primära servern. Detta för att säkerställa en konsekvent och tillförlitlig startpunkt. Ändringar av serverparametrarna på den primära servern som görs 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. Detta ger flexibilitet och anpassningsalternativ, men kräver också noggrann och manuell hantering för att upprätthålla konsekvens mellan den primära och dess replik när enhetlighet för serverparametrar krävs.

Administratörer kan ändra serverparametrar på läsreplikservern 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 bör dessa specifika parametrar alltid anges till värden som antingen motsvarar eller är större än de som konfigurerats på den primära servern.

Skala

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, men följande varningar gäller.

För beräkningsskalning:

• Azure Database for PostgreSQL – flexibel server kräver att flera parametrar på repliker är större än eller lika med inställningen på den primära servern för att säkerställa att repliken inte får slut på delat minne under återställningen. De parametrar som påverkas är: max_connections, max_prepared_transactions, max_locks_per_transaction, max_wal_senders, max_worker_processes.

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

• Skala ned: Skala först ned den primära beräkningen och skala sedan ned repliken.

• Beräkning på den primära måste alltid vara lika med eller mindre än beräkningen på den minsta repliken.

För lagringsskalning:

• Skala upp: Skala först upp en repliks lagring och skala sedan upp 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
• Höja upp läsrepliker
• Virtuella slutpunkter
• Skapa och hantera skrivskyddade repliker i Azure-portalen
• Replikering mellan regioner med virtuellt nätverk