Dela via

Höja upp läsrepliker i Azure Database for PostgreSQL – flexibel server

  • Artikel

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

Flytta upp refererar till processen där en replik befalls för att avsluta replikläget och övergå till fullständiga skrivåtgärder.

Viktigt!

Uppflyttingsåtgärden är inte automatisk. I händelse av ett primärt serverfel växlar systemet inte till skrivskyddade repliker oberoende av varandra. En användaråtgärd krävs alltid för upphöjningsåtgärden.

Befordran av repliker kan göras på två olika sätt:

Flytta upp till primär server

Den här åtgärden höjer en replik till den primära serverns roll. I processen nedgraderas den aktuella primära servern till en replikroll och byter roller. För en lyckad befordran är det nödvändigt att ha en virtuell slutpunkt konfigurerad för både den aktuella primära som skrivarslutpunkten och repliken som är avsedd för befordran som läsarens slutpunkt. Befordran lyckas endast om målrepliken ingår i läsarens slutpunktskonfiguration.

Diagrammet visar konfigurationen av servrarna före befordran och det resulterande tillståndet efter att befordran har slutförts.

Diagram som visar upphöj till primär serveråtgärd.

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

När du väljer det här alternativet befordras repliken till en oberoende server och tas bort från replikeringsprocessen. Det innebär att både den primära och den upphöjda serverfunktionen fungerar som två oberoende skrivskyddade servrar. Det bör noteras att även om virtuella slutpunkter kan konfigureras är de inte nödvändiga för den här åtgärden. Den nyligen upphöjda servern är inte längre en del av några befintliga virtuella slutpunkter, även om läsarslutpunkten tidigare pekade på den. Därför är det viktigt att uppdatera programmets niska veze för att dirigera till den nyligen upphöjda repliken om programmet ska ansluta till den.

Diagrammet visar hur servrarna konfigureras innan de höjs upp och deras konfiguration efter att de har blivit oberoende servrar.

Diagram som visar upphöjer till oberoende server och tar bort från replikeringsåtgärden.

Viktigt!

Åtgärden Flytta upp till oberoende server och ta bort från replikering är bakåtkompatibel med den tidigare uppflyttade funktionen.

Viktigt!

Serversymmetri: För en lyckad befordran med hjälp av upphöjningen till den primära serveråtgärden måste både de primära servrarna och replikservrarna ha identiska nivåer och lagringsstorlekar. Om den primära har 2vCores och repliken har 4vCores är det enda genomförbara alternativet att använda åtgärden "befordra till oberoende server och ta bort från replikering". Dessutom måste de dela samma värden för serverparametrar som allokerar delat minne.

För båda kampanjmetoderna finns det fler alternativ att tänka på:

  • Planerat: Det här alternativet säkerställer att data synkroniseras innan de befordras. Den tillämpar alla väntande loggar för att säkerställa datakonsekvens innan klientanslutningar accepteras.

  • Tvingad: Det här alternativet är utformat för snabb återställning i scenarier som regionala avbrott. I stället för att vänta på att synkronisera alla data från den primära servern, blir servern i drift när den bearbetar WAL-filer som behövs för att uppnå närmaste konsekventa tillstånd. Om du höjer upp repliken med det här alternativet anger fördröjningen vid den tidpunkt då du avlänkar repliken från den primära repliken hur mycket data som går förlorade.

Viktigt!

Alternativet Tvingad befordran är särskilt utformat för att hantera regionala avbrott och i sådana fall hoppar det över alla kontroller – inklusive kravet på serversymmetri – och fortsätter med befordran. Detta beror på att den prioriterar omedelbar servertillgänglighet för att hantera katastrofscenarier. Att använda alternativet Tvingad utanför scenarier med region ned tillåts dock inte om kraven för läsrepliker som anges i dokumentationen, särskilt krav på serversymmetri, inte uppfylls, eftersom det kan leda till problem som bruten replikering.

Lär dig hur du höjer upp repliken till primär och befordrar till oberoende server och tar bort från replikeringen.

Konfigurationshantering

Läsrepliker behandlas som separata servrar när det gäller kontrollplanskonfigurationer. Den här metoden ger flexibilitet för lässkalningsscenarier. Men när du använder repliker för haveriberedskap måste användarna se till att konfigurationen är som den ska.

Uppflyttingsåtgärden överför inte specifika konfigurationer och parametrar. Här är några av de anmärkningsvärda:

  • PgBouncer: Den inbyggda PgBouncer-anslutningspoolens inställningar och status replikeras inte under befordran. Om PgBouncer har aktiverats på den primära men inte på repliken förblir den inaktiverad på repliken efter befordran. Om du vill ha PgBouncer på den nyligen upphöjda servern måste du aktivera den antingen före eller efter befordran.
  • Geo-redundant lagring av säkerhetskopiering: Inställningar för geo-säkerhetskopiering överförs inte. Eftersom repliker inte kan ha geo-säkerhetskopiering aktiverat, har den upphöjda primära (tidigare repliken) inte den efter befordran. Funktionen kan bara aktiveras när standardservern skapas (inte en replik).
  • Serverparametrar: Om deras värden skiljer sig åt på den primära repliken och läsrepliken ändras de inte under befordran. Observera att parametrar som påverkar den delade minnesstorleken måste ha samma värden på både de primära och replikerna. Det här kravet beskrivs i avsnittet Serverparametrar .
  • Microsoft Entra-autentisering: Om den primära hade Konfigurerat Microsoft Entra-autentisering , men repliken konfigurerades med PostgreSQL-autentisering, kommer repliken inte automatiskt att växla till Microsoft Entra-autentisering efter befordran. Den behåller PostgreSQL-autentiseringen. Användare måste manuellt konfigurera Microsoft Entra-autentisering på den upphöjda repliken antingen före eller efter befordransprocessen.
  • Hög tillgänglighet (HA): Om du behöver ha efter befordran måste den konfigureras på den nyligen upphöjda primära servern efter rollåtervändningen.

Att tänka på

Servertillstånd under befordran

I både scenarier för planerad och tvingad befordran krävs det att servrarna (både primära och replik) är i tillståndet "Tillgänglig". Om en servers status är något annat än "Tillgänglig" (till exempel "Uppdatera" eller "Starta om" kan befordran vanligtvis inte fortsätta utan problem. Ett undantag görs dock vid regionala avbrott.

Under sådana regionala avbrott kan metoden Tvingad befordran implementeras oavsett den primära serverns aktuella status. Den här metoden möjliggör snabba åtgärder som svar på potentiella regionala katastrofer och kringgår normala kontroller av servertillgänglighet.

Observera att om den tidigare primära servern misslyckas utöver återställningen under befordran av repliken är det enda alternativet att ta bort den tidigare primära servern och återskapa replikservern.

Flera replikers synlighet under befordran i icke-trappade regioner

När du hanterar flera repliker och om den primära regionen saknar en länkad region måste du överväga ett särskilt övervägande. Om ett regionalt avbrott påverkar den primära repliken identifieras inga andra repliker automatiskt av den nyligen upphöjda repliken. Program kan fortfarande dirigeras till den upphöjda repliken för fortsatt drift, men de okända replikerna förblir frånkopplade under driftstoppet. Dessa extra repliker kopplar bara om och återupptar sina roller när den ursprungliga primära regionen har återställts.

Vanliga frågor och svar

  • Kan jag höja upp en replik om min primära server har hög tillgänglighet (HA) aktiverat?

    Ja, oavsett om den primära servern är HA-aktiverad eller inte kan du höja upp dess läsreplik. Möjligheten att höja upp en läsreplik till en primär server är oberoende av ha-konfigurationen för den primära.

  • Om jag har en HA-aktiverad primär och en skrivskyddad replik, och jag höjer upp repliken och sedan växlar tillbaka till den ursprungliga primära, kommer servern fortfarande att vara i HA?

    Nej, vi inaktiverar HA under den första befordran eftersom vi inte stöder HA-aktiverade läsrepliker. Om du befordrar en läsreplik till en primär innebär det att den ursprungliga primära filen ändrar sin roll till en replik. Om du växlar tillbaka måste du aktivera HA på den ursprungliga primära servern.

Relaterat innehåll