Geo-replicatie in Azure Database for PostgreSQL - Flexibele server
VAN TOEPASSING OP: 
Azure Database for PostgreSQL - Flexibele server
Een leesreplica kan worden gemaakt in dezelfde regio als de primaire server of in een andere geografische regio. Geo-replicatie kan nuttig zijn voor scenario's zoals noodherstelplanning of het dichter bij uw gebruikers brengen van gegevens.
U kunt een primaire server hebben in elke flexibele Azure Database for PostgreSQL-serverregio. Een primaire server kan ook replica's hebben in elke globale regio van Azure die ondersteuning biedt voor flexibele Azure Database for PostgreSQL-server. Daarnaast ondersteunen we speciale regio's Azure Government en Microsoft Azure beheerd door 21Vianet. De speciale regio's worden nu ondersteund:
Azure Government-regio's:
- US Gov - Arizona
- US Gov - Texas
- VS (overheid) - Virginia
Microsoft Azure beheerd door 21Vianet-regio's:
- China - noord 3
- China - oost 3
- China - noord 2
- China - oost 2
Gekoppelde regio's voor herstel na noodgevallen
Hoewel het maken van replica's in een ondersteunde regio mogelijk is, zijn er belangrijke voordelen voor het kiezen van replica's in gekoppelde regio's, met name bij het ontwerpen voor herstel na noodgevallen:
Regioherstelreeks: In een geografisch brede storing wordt het herstel van één regio uit elke gekoppelde set prioriteit gegeven, zodat toepassingen in gekoppelde regio's altijd een regio hebben die wordt versneld voor herstel.
Sequentiële updates: updates van gekoppelde regio's worden chronologisch gefaseerd, waardoor het risico op downtime van problemen met betrekking tot updates wordt geminimaliseerd.
Fysieke isolatie: er wordt een minimale afstand van 300 mijl tussen datacenters in gekoppelde regio's onderhouden, waardoor het risico op gelijktijdige storingen van belangrijke gebeurtenissen wordt verminderd.
Gegevenslocatie: Met een paar uitzonderingen bevinden regio's in een gekoppelde set zich binnen dezelfde geografie, die voldoen aan de vereisten voor gegevenslocatie.
Prestaties: hoewel gekoppelde regio's doorgaans lage netwerklatentie bieden, is het verbeteren van de toegankelijkheid en gebruikerservaring van gegevens mogelijk niet altijd de regio's met de absolute laagste latentie. Als het primaire doel is om gegevens dichter bij gebruikers te leveren in plaats van prioriteit te geven aan herstel na noodgevallen, is het essentieel om alle beschikbare regio's voor latentie te evalueren. In sommige gevallen kan een niet-gekoppelde regio de laagste latentie vertonen. Voor een uitgebreid begrip kunt u verwijzen naar de latentiecijfers van Azure om een weloverwogen keuze te maken.
Raadpleeg de documentatie van Azure over replicatie tussen regio's voor meer informatie over de voordelen van gekoppelde regio's.
Regionale fouten en herstel
Azure-faciliteiten in verschillende regio's zijn ontworpen om zeer betrouwbaar te zijn. In zeldzame gevallen kan een hele regio echter ontoegankelijk worden vanwege redenen die variëren van netwerkfouten tot ernstige scenario's zoals natuurrampen. Met de mogelijkheden van Azure kunt u toepassingen maken die zijn verdeeld over meerdere regio's, zodat een fout in de ene regio geen invloed heeft op andere regio's.
Voorbereiden op regionale rampen
Het voorbereiden op potentiële regionale rampen is van cruciaal belang voor een ononderbroken werking van uw toepassingen en services. Als u een robuust plan voor onvoorziene gebeurtenissen overweegt voor uw flexibele serverexemplaren van Azure Database for PostgreSQL, zijn dit de belangrijkste stappen en overwegingen:
- Stel een geo-gerepliceerde leesreplica in: het is essentieel dat u een leesreplica instelt in een afzonderlijke regio van uw primaire regio. Dit zorgt voor continuïteit als de primaire regio te maken heeft met een storing.
- Zorg voor serversymmetrie: de actie 'niveau verhogen naar primaire server' is het meest aanbevolen voor het afhandelen van regionale storingen, maar wordt geleverd met een serversymmetrievereiste . Dit betekent dat zowel de primaire als de replicaservers identieke configuraties van specifieke instellingen moeten hebben. De voordelen van het gebruik van deze actie zijn:
- U hoeft de toepassings-verbindingsreeks s niet te wijzigen als u virtuele eindpunten gebruikt.
- Het biedt een naadloos herstelproces waarbij, zodra de getroffen regio weer online is, de oorspronkelijke primaire server automatisch de functie hervat, maar in een nieuwe replicarol.
- Virtuele eindpunten instellen: virtuele eindpunten zorgen voor een soepele overgang van uw toepassing naar een andere regio als er een storing optreedt. Ze elimineren de noodzaak van wijzigingen in de verbindingsreeks s van uw toepassing.
- Configureer de leesreplica: niet alle instellingen van de primaire server worden gerepliceerd naar de leesreplica. Het is van cruciaal belang om ervoor te zorgen dat alle benodigde configuraties en functies (bijvoorbeeld PgBouncer) op de juiste wijze zijn ingesteld op uw leesreplica. Zie de sectie Configuratiebeheer voor meer informatie.
- Voorbereiden op hoge beschikbaarheid :als voor uw installatie hoge beschikbaarheid is vereist, wordt deze niet automatisch ingeschakeld op een gepromoveerde replica. Wees klaar om deze na promotie te activeren. Overweeg deze stap te automatiseren om downtime te minimaliseren.
- Regelmatig testen: simuleer regelmatig regionale noodscenario's om bestaande drempelwaarden, doelen en configuraties te valideren. Zorg ervoor dat uw toepassing reageert zoals verwacht tijdens deze testscenario's.
- Volg de algemene richtlijnen van Azure: Azure biedt uitgebreide richtlijnen voor betrouwbaarheid en voorbereiding op noodgevallen. Het is zeer nuttig om deze resources te raadplegen en best practices te integreren in uw voorbereidingsplan.
Proactief zijn en van tevoren voorbereiden op regionale rampen zorgen voor de tolerantie en betrouwbaarheid van uw toepassingen en gegevens.
Wanneer storingen van invloed zijn op uw SLA
In het geval van een langdurige storing met Azure Database for PostgreSQL Flexibele server in een specifieke regio die de SLA (Service Level Agreement) van uw toepassing bedreigt, moet u er rekening mee houden dat beide acties die hieronder worden besproken, niet servicegestuurd zijn. Tussenkomst van de gebruiker is vereist voor beide. Het is een best practice om het hele proces zoveel mogelijk te automatiseren en robuuste bewaking te hebben. Zie de pagina Servicestoring voor meer informatie over welke informatie wordt verstrekt tijdens een storing. Alleen een geforceerde promotie is mogelijk in een scenario waarin een regio uitvalt, wat betekent dat de hoeveelheid gegevensverlies ongeveer gelijk is aan de huidige vertraging tussen de replica en de primaire. Daarom is het van cruciaal belang om de vertraging te bewaken. Houd rekening met de volgende stappen:
Niveau verhogen naar primaire server
Deze optie vereist geen update van de verbindingsreeks s in uw toepassing, mits virtuele eindpunten zijn geconfigureerd. Zodra het eindpunt van de schrijver is geactiveerd, wordt het nieuwe primaire eindpunt in een andere regio opnieuw aangeduid en wordt in de kolom replicatiestatus in Azure Portal 'Opnieuw configureren' weergegeven. Zodra de betrokken regio is hersteld, wordt de voormalige primaire server automatisch hervat, maar nu in een replicarol.
Niveau verhogen naar onafhankelijke server en verwijderen uit replicatie
In dat geval is dit de enige haalbare optie. Nadat u de server hebt gepromoot, moet u de verbindingsreeks s van uw toepassing bijwerken. Zodra de oorspronkelijke regio is hersteld, kan de oude primaire machine weer actief worden. Zorg ervoor dat u deze verwijdert om onnodige kosten te voorkomen. Als u de vorige topologie wilt behouden, maakt u de leesreplica opnieuw.