Skrivskyddade repliker i Azure Database for PostgreSQL – enskild server

  • Artikel

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

Viktigt!

Azure Database for PostgreSQL – enskild server är på väg att dras tillbaka. Vi rekommenderar starkt att du uppgraderar till Azure Database for PostgreSQL – flexibel server. Mer information om hur du migrerar till Azure Database for PostgreSQL – flexibel server finns i Vad händer med Azure Database for PostgreSQL – enskild server?.

Med funktionen skrivskyddad replik kan du replikera data från en Azure Database for PostgreSQL-server till en skrivskyddad server. Repliker uppdateras asynkront med PostgreSQL-motorns interna fysiska replikeringsteknik. Du kan replikera från den primära servern till upp till fem repliker.

Repliker är nya servrar som du hanterar ungefär som vanliga Azure Database for PostgreSQL-servrar. 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 befordras till en läs-/skrivserver i händelse av en haveriberedskap.

Ett vanligt scenario är att låta BI och analytiska arbetsbelastningar använda de skrivskyddade replikerna som datakälla vid rapportering.

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

Att tänka på

Funktionen är avsedd för scenarier där fördröjningen är acceptabel och avsedd för avlastning av frågor. Det är inte avsett för synkrona replikeringsscenarier där replikdata förväntas vara uppdaterade. Det blir en mätbar fördröjning mellan den primära och repliken. Detta kan vara i minuter eller till och med timmar beroende på arbetsbelastningen och svarstiden mellan den primära och repliken. 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.

Kommentar

För de flesta arbetsbelastningar erbjuder skrivskyddade repliker uppdateringar nästan i realtid från den primära servern. Men med beständiga, tunga, skrivintensiva primära arbetsbelastningar kan replikeringsfördröjningen fortsätta att växa och kanske aldrig kommer ikapp den primära servern. Detta kan också öka lagringsanvändningen på den primära servern eftersom WAL-filerna inte tas bort förrän de har tagits emot på repliken. Om det här problemet kvarstår kan du återställa tillståndet för repliken och bli av med fördröjningen genom att ta bort och skapa den skrivskyddade repliken på nytt när de skrivintensiva arbetsbelastningarna är klara. Asynkrona skrivskyddade repliker lämpar sig inte för sådana tunga skrivarbetsbelastningar. När du utvärderar läsrepliker för ditt program övervakar du fördröjningen på repliken för en fullständig apparbetsbelastningscykel under de högsta och icke-högsta tiderna för att få åtkomst till den möjliga fördröjningen och det förväntade RTO/RPO vid olika tidpunkter i arbetsbelastningscykeln.

Kommentar

Automatiska säkerhetskopieringar utförs för replikservrar som har konfigurerats med upp till 4 TB lagringskonfiguration.

Replikering mellan regioner

Du kan skapa en skrivskyddad replik i en annan region än där den primära servern finns. Replikering mellan regioner kan vara användbart för scenarier som haveriberedskapsplanering eller om du vill att data ska vara närmare användarna.

Kommentar

Servrar på basic-nivå stöder endast replikering i samma region.

Du kan ha en primär server i valfri Azure Database for PostgreSQL-region. En primär server kan ha en replik i sin kopplade region eller de universella replikregionerna. Bilden nedan visar vilka replikregioner som är tillgängliga beroende på din primära region.

Läs replikregioner

Universella replikeringsregioner

Du kan alltid skapa en läsreplik i någon av följande regioner, oavsett var den primära servern finns. Det här är de universella replikregionerna:

Australien, östra, Australien, sydöstra, Brasilien, södra, Kanada, centrala, Kanada, östra, USA, centrala, Östra Asien, USA, östra, USA, östra 2, Japan, östra, Japan, västra, Korea, centrala, Sydkorea, södra, USA, norra centrala, Europa, norra centrala, USA, södra centrala, Sydostasien, Storbritannien, södra, Storbritannien, västra, Europa, västra, USA, västra, USA, västra 2, USA, västra centrala.

Länkade regioner

Förutom de universella replikregionerna kan du skapa en skrivskyddad replik i den Azure-kopplade regionen på den primära servern. Om du inte känner till regionens par kan du lära dig mer i artikeln Azure Paired Regions (Länkade regioner i Azure).

Om du använder repliker mellan regioner för planering av haveriberedskap rekommenderar vi att du skapar repliken i den kopplade regionen i stället för någon av de andra regionerna. Parkopplade regioner undviker samtidiga uppdateringar och prioriterar fysisk isolering och datahemvist.

Det finns begränsningar att tänka på:

  • Enkelriktade par: Vissa Azure-regioner är endast kopplade i en riktning. Dessa regioner omfattar Indien, västra, Brasilien, södra. Det innebär att en primär server i Indien, västra, kan skapa en replik i södra Indien. En primär server i södra Indien kan dock inte skapa en replik i Indien, västra. Detta beror på att Västra Indiens sekundära region är Södra Indien, men Södra Indiens sekundära region är inte Västra Indien.

Skapa en replik

När du startar arbetsflödet för att skapa en replik skapas en tom Azure Database for PostgreSQL-server. Den nya servern fylls med data som fanns på den primära servern. Skapandetiden beror på hur mycket data som finns på det primära klustret och hur lång tid som har gått sedan den senaste veckovisa fullständiga säkerhetskopieringen. Tiden kan variera från några minuter till flera timmar.

Varje replik är aktiverad för automatisk ökning av lagring. Funktionen för automatisk utökning gör att repliken kan hålla jämna steg med de data som replikeras till den och förhindra en avbrott i replikeringen som orsakas av fel som inte finns i lagringen.

Funktionen för skrivskyddade repliker använder fysisk replikering i PostgreSQL, inte logisk replikering. Dataströmsreplikering med replikeringsplatser är standardarbetsläget. Vid behov används loggöverföring för att komma ikapp.

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

Om din PostgreSQL-källserver är krypterad med kundhanterade nycklar finns mer information i dokumentationen.

Ansluta till en replik

När du skapar en replik ärver den inte brandväggsreglerna eller VNet-tjänstslutpunkten för den primära servern. Dessa regler måste konfigureras separat för repliken.

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.

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

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

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

Övervaka replikering

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

Måttet Max Lag Across Replicas visar fördröjningen i byte mellan den primära och den replik som släpar mest efter. 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 läsreplikerna är ansluten till den primära och den primära är i direktuppspelningsreplikeringsläge. Fördröjningsinformationen visar inte information när repliken håller på att komma ikapp den primära med hjälp av de arkiverade loggarna för den primära i ett replikeringsläge för filöverföring.

Måttet Replikfördröjning visar tiden sedan den senaste omspelade transaktionen. Om det inte sker några transaktioner på den primära servern återspeglar måttet den här tidsfördröjningen. Det här måttet är endast tillämpligt och tillgängligt för replikservrar. Replikfördröjning beräknas från pg_stat_wal_receiver vyn:

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

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 ytterligare information frågar du den primära servern direkt för att hämta replikeringsfördröjningen i byte på alla repliker.

Kommentar

Om en primär server eller en läsreplik startas om återspeglas den tid det tar att starta om och komma ikapp i måttet Replikfördröjning.

Stoppa replikering/Flytta upp replik

Du kan när som helst stoppa replikeringen mellan en primär och en replik. Stoppåtgärden gör att repliken startas om och befordrar repliken till en oberoende, fristående skrivbar server. Data på den fristående servern är de data som var tillgängliga på replikservern när replikeringen stoppades. Efterföljande uppdateringar i primärt sprids inte till repliken. Replikservern kan dock ha ackumulerade loggar som inte har tillämpats ännu. Som en del av omstartsprocessen tillämpar repliken alla väntande loggar innan klientanslutningar godkänns.

Kommentar

Det går för närvarande inte att återställa administratörslösenordet på replikservern. Dessutom stöds inte heller uppdatering av administratörslösenord tillsammans med åtgärden för att höja upp repliken 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.

Att tänka på

  • Innan du stoppar replikeringen på en läsreplik kontrollerar du replikeringsfördröjningen för att säkerställa att repliken har alla data som du behöver.
  • Eftersom läsrepliken måste tillämpa alla väntande loggar innan den kan göras till en fristående server kan RTO vara högre för skrivintensiva arbetsbelastningar när stoppreplikeringen sker eftersom det kan uppstå en betydande fördröjning på repliken. Var uppmärksam på detta när du planerar att höja upp en replik.
  • Den upphöjda replikservern kan inte göras till en replik igen.
  • Om du befordrar en replik till den primära servern kan du inte upprätta replikering tillbaka till den gamla primära servern. Om du vill gå tillbaka till den tidigare primära regionen kan du antingen skapa en ny replikserver med ett nytt namn eller ta bort den gamla primära servern och skapa en replik med samma namn som den tidigare primära servern.
  • Om du har flera skrivskyddade repliker och höjer upp en av dem till din primära server, är de andra replikservrarna fortfarande anslutna till den tidigare primära servern. Du kanske måste skapa replikerna på nytt från den nya upphöjda servern.

När du stoppar replikeringen förlorar repliken alla länkar till dess tidigare primära och andra repliker.

Lär dig hur du stoppar replikeringen till en replik.

Redundansväxling till replik

I händelse av ett primärt serverfel redigeras den inte automatiskt över till läsrepliken.

Eftersom replikeringen är asynkron kan det uppstå en betydande fördröjning mellan den primära repliken och repliken. Fördröjningen påverkas av ett antal faktorer, till exempel vilken typ av arbetsbelastning som körs på den primära servern och svarstiden mellan den primära servern och replikservern. I vanliga fall med nominell skrivarbetsbelastning förväntas replikfördröjningen mellan några sekunder och några minuter. Men i fall där den primära kör mycket tung skrivintensiv arbetsbelastning och repliken inte kommer ikapp tillräckligt snabbt kan fördröjningen vara mycket högre. Du kan spåra replikeringsfördröjningen för varje replik med måttet Replikfördröjning. Det här måttet visar tiden sedan den senaste omspelade transaktionen på repliken. Vi rekommenderar att du identifierar den genomsnittliga fördröjningen genom att observera replikfördröjningen under en tidsperiod. Du kan ange en avisering om replikfördröjning, så att om den hamnar utanför det förväntade intervallet får du ett meddelande om att vidta åtgärder.

Dricks

Om du redundansväxlar till repliken visar fördröjningen vid den tidpunkt då du avlänkar repliken från den primära datamängden hur mycket data som går förlorade.

När du har bestämt dig för att redundansväxlar till en replik

  1. Stoppa replikeringen till repliken
    Det här steget är nödvändigt för att replikservern ska bli en fristående server och kunna acceptera skrivningar. Som en del av den här processen startas replikservern om och kopplas från den primära servern. När du har initierat stoppreplikeringen tar det vanligtvis några minuter för serverdelen att tillämpa eventuella kvarvarande loggar som ännu inte har tillämpats och öppna databasen som en skrivbar server. Se avsnittet stoppa replikering i den här artikeln för att förstå konsekvenserna av den här åtgärden.

  2. Peka ditt program till (tidigare) repliken
    Varje server har en unik anslutningssträng. Uppdatera ditt program anslutningssträng så att det pekar på (tidigare) repliken i stället för den primära.

När programmet har bearbetat läsningar och skrivningar har du slutfört redundansväxlingen. Hur lång stilleståndstid dina programupplevelser beror på när du identifierar ett problem och slutför steg 1 och 2 ovan.

Haveriberedskap

När det finns en större katastrofhändelse, till exempel tillgänglighet på zonnivå eller regionala fel, kan du utföra en haveriberedskapsåtgärd genom att främja din läsreplik. Från användargränssnittsportalen kan du navigera till läsreplikservern. Välj sedan replikeringsfliken så kan du stoppa repliken för att höja upp den till en oberoende server. Du kan också använda Azure CLI för att stoppa och höja upp replikservern.

Att tänka på

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

Förutsättningar

Både läsrepliker och logisk avkodning är beroende av postgres-loggen (WAL) för information. Dessa två funktioner behöver olika nivåer av loggning från Postgres. Logisk avkodning behöver en högre loggningsnivå än läsrepliker.

Om du vill konfigurera rätt loggningsnivå använder du azure-replikeringssupportparametern. Stöd för Azure-replikering har tre inställningsalternativ:

  • Av – Placerar minst information i WAL. Den här inställningen är inte tillgänglig på de flesta Azure Database for PostgreSQL-servrar.
  • Replik – mer utförlig än Av. Det här är den lägsta loggningsnivån som krävs för att läsrepliker ska fungera. Den här inställningen är standard på de flesta servrar.
  • Logiskt – mer utförligt än replik. Det här är den lägsta loggningsnivån för att logisk avkodning ska fungera. Läsrepliker fungerar också med den här inställningen.

Nya repliker

En läsreplik skapas som en ny Azure Database for PostgreSQL-server. Det går inte att göra en befintlig server till en replik. Du kan inte skapa en replik av en annan läsreplik.

Replikkonfiguration

En replik skapas med samma beräknings- och lagringsinställningar som den primära. När en replik har skapats kan flera inställningar ändras, inklusive kvarhållningsperiod för lagring och säkerhetskopiering.

Brandväggsregler, regler för virtuella nätverk och parameterinställningar ärvs inte från den primära servern till repliken när repliken skapas eller efteråt.

Skalning

Skala virtuella kärnor eller mellan Generell användning och Minnesoptimerad:

  • PostgreSQL kräver max_connections att inställningen på en sekundär server är större än eller lika med inställningen på den primära, annars startar inte den sekundära.
  • I Azure Database for PostgreSQL är de högsta tillåtna anslutningarna för varje server fasta i beräknings-SKU:n eftersom anslutningarna upptar minne. Du kan lära dig mer om mappningen mellan max_connections och beräkningsskuus.
  • Skala upp: Skala först upp en repliks beräkning och skala sedan upp den primära. Den här ordningen förhindrar att fel bryter mot max_connections kravet.
  • Skala ned: Skala först ned den primära beräkningen och skala sedan ned repliken. Om du försöker skala repliken lägre än den primära kommer det att uppstå ett fel eftersom detta strider mot max_connections kravet.

Skalningslagring:

  • Alla repliker har automatiskt utökat lagringsutrymme för att förhindra replikeringsproblem från en lagringsfull replik. Det går inte att inaktivera den här inställningen.
  • Du kan också skala upp lagringen manuellt, precis som på andra servrar

Basic-nivå

Servrar på basic-nivå stöder endast replikering i samma region.

max_prepared_transactions

PostgreSQL kräver att värdet för parametern max_prepared_transactions på läsrepliken är större än eller lika med det primära värdet. Annars startar inte repliken. Om du vill ändra max_prepared_transactions på den primära ska du först ändra den på replikerna.

Stoppade repliker

Om du stoppar replikeringen mellan en primär server och en läsreplik startar repliken om för att tillämpa ändringen. Den stoppade repliken blir en fristående server som accepterar både läsningar och skrivningar. Den fristående servern kan inte göras till en replik igen.

Borttagna primära och fristående servrar

När en primär server tas bort blir alla dess läsrepliker fristående servrar. Replikerna startas om för att återspegla den här ändringen.

Nästa steg