Dela via

Geo-replikering i Azure Database for PostgreSQL – flexibel server

  • Artikel

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

En läsreplik kan skapas i samma region som den primära servern eller i en annan geografisk region. Geo-replikering kan vara till hjälp för scenarier som planering av haveriberedskap eller för data närmare dina användare.

Du kan ha en primär server i valfri flexibel Azure Database for PostgreSQL-serverregion. En primär server kan också ha repliker i valfri global region i Azure som stöder flexibel Azure Database for PostgreSQL-server. Dessutom stöder vi särskilda regioner som Azure Government och Microsoft Azure drivs av 21Vianet. De särskilda regioner som nu stöds är:

  • Azure Government-regioner:

    • US Gov, Arizona
    • US Gov, Texas
    • US Gov, Virginia

  • Microsoft Azure drivs av 21Vianet-regioner:

    • Norra Kina 3
    • Östra Kina 3
    • Norra Kina 2
    • Östra Kina 2

Parkopplade regioner i haveriberedskapssyfte

Det är möjligt att skapa repliker i alla regioner som stöds, men det finns betydande fördelar med att välja repliker i parkopplade regioner, särskilt när du skapar för haveriberedskap:

  • Regionåterställningssekvens: I ett geografiskt avbrott prioriteras återställning av en region från varje parkopplad uppsättning, vilket säkerställer att program i parkopplade regioner alltid har en region som påskyndas för återställning.

  • Sekventiell uppdatering: De kopplade regionernas uppdateringar fördelas kronologiskt, vilket minimerar risken för stilleståndstid från uppdateringsrelaterade problem.

  • Fysisk isolering: Ett minsta avstånd på 300 miles upprätthålls mellan datacenter i parkopplade regioner, vilket minskar risken för samtidiga avbrott från betydande händelser.

  • Datahemvist: Med några få undantag finns regioner i en parkopplad uppsättning inom samma geografiska område och uppfyller kraven på datahemvist.

  • Prestanda: Även om parkopplade regioner vanligtvis erbjuder låg nätverksfördröjning, vilket förbättrar datatillgängligheten och användarupplevelsen, kanske de inte alltid är de regioner som har den absolut lägsta svarstiden. Om det primära målet är att hantera data närmare användarna i stället för att prioritera haveriberedskap är det viktigt att utvärdera alla tillgängliga regioner för svarstid. I vissa fall kan en region som inte är länkad uppvisa den lägsta svarstiden. Om du vill ha en omfattande förståelse kan du referera till svarstidssiffrorna för Azures svarstider för tur och retur för att göra ett välgrundat val.

En djupare förståelse av fördelarna med kopplade regioner finns i Azures dokumentation om replikering mellan regioner.

Regionala fel och återställning

Azure-anläggningar i olika regioner är utformade för att vara mycket tillförlitliga. I sällsynta fall kan dock en hel region bli otillgänglig på grund av orsaker som sträcker sig från nätverksfel till allvarliga scenarier som naturkatastrofer. Med Azures funktioner kan du skapa program som är distribuerade i flera regioner, vilket säkerställer att ett fel i en region inte påverkar andra.

Förbereda för regionala katastrofer

Det är viktigt att du förbereder dig för potentiella regionala katastrofer för att säkerställa att dina program och tjänster fungerar oavbrutet. Om du överväger en robust beredskapsplan för din flexibla Azure Database for PostgreSQL-serverinstans är följande viktiga steg och överväganden:

  1. Upprätta en geo-replikerad läsreplik: Det är viktigt att en läsreplik konfigureras i en separat region från din primära. Detta säkerställer kontinuitet om den primära regionen drabbas av ett avbrott.
  2. Se till att servern är symmetrisk: Åtgärden "befordra till primär server" rekommenderas mest för att hantera regionala avbrott, men den levereras med ett krav på serversymmetri . Det innebär att både de primära servrarna och replikservrarna måste ha identiska konfigurationer av specifika inställningar. Fördelarna med att använda den här åtgärden är:
    • Du behöver inte ändra program niska veze om du använder virtuella slutpunkter.
    • Det ger en sömlös återställningsprocess där den ursprungliga primära servern automatiskt återupptar sin funktion när den berörda regionen är online igen, men i en ny replikroll.
  3. Konfigurera virtuella slutpunkter: Virtuella slutpunkter möjliggör en smidig övergång av ditt program till en annan region om det uppstår ett avbrott. De eliminerar behovet av ändringar i programmets niska veze.
  4. Konfigurera skrivskyddad replik: Alla inställningar från den primära servern replikeras inte till läsrepliken. Det är viktigt att se till att alla nödvändiga konfigurationer och funktioner (till exempel PgBouncer) är korrekt konfigurerade på din läsreplik. Mer information finns i avsnittet Konfigurationshantering .
  5. Förbered för hög tillgänglighet (HA): Om installationen kräver hög tillgänglighet aktiveras den inte automatiskt på en upphöjd replik. Var redo att aktivera den efter befordran. Överväg att automatisera det här steget för att minimera stilleståndstiden.
  6. Regelbunden testning: Simulera regelbundet regionala katastrofscenarier för att verifiera befintliga tröskelvärden, mål och konfigurationer. Se till att ditt program svarar som förväntat under dessa testscenarier.
  7. Följ Azures allmänna vägledning: Azure ger omfattande vägledning om tillförlitlighet och katastrofberedskap. Det är mycket fördelaktigt att konsultera dessa resurser och integrera bästa praxis i din beredskapsplan.

Att vara proaktiv och förbereda sig i förväg för regionala katastrofer säkerställer motståndskraften och tillförlitligheten hos dina program och data.

När avbrott påverkar ditt serviceavtal

I händelse av ett långvarigt avbrott med flexibel Azure Database for PostgreSQL-server i en specifik region som hotar programmets serviceavtal (SLA) bör du vara medveten om att båda åtgärderna som beskrivs nedan inte är tjänstdrivna. Användarintervention krävs för båda. Vi rekommenderar att du automatiserar hela processen så mycket som möjligt och har robust övervakning på plats. Mer information om vilken information som tillhandahålls under ett avbrott finns på sidan Tjänststopp . Endast en framtvingad uppflytt är möjlig i ett scenario med en region nedåt, vilket innebär att mängden dataförlust är ungefär lika med den aktuella fördröjningen mellan repliken och den primära. Därför är det viktigt att övervaka fördröjningen. Överväg följande steg:

Flytta upp till primär server

Det här alternativet kräver inte uppdatering av niska veze i ditt program, förutsatt att virtuella slutpunkter har konfigurerats. När den har aktiverats pekar skrivarslutpunkten på nytt till den nya primära i en annan region och replikeringstillståndskolumnen i Azure-portalen visar "Konfigurera om". När den berörda regionen har återställts återupptas den tidigare primära servern automatiskt, men nu i en replikroll.

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

I så fall är detta det enda genomförbara alternativet. När du har marknadsfört servern måste du uppdatera programmets niska veze. När den ursprungliga regionen har återställts kan den gamla primära platsen bli aktiv igen. Se till att ta bort den för att undvika onödiga kostnader. Om du vill behålla den tidigare topologin återskapar du den lästa repliken.

Relaterat innehåll