Skalning av resurser i Azure Database for PostgreSQL – flexibel server

En Azure Database for PostgreSQL flexibel server stöder både vertikala och vågräta skalningsalternativ.

Vertikal skalning

Skala servern lodrätt genom att lägga till fler resurser i Azure Database for PostgreSQL flexibel server. Du kan öka eller minska antalet processorer och det tilldelade minnet.

Serverns nätverksdataflöde beror på vilka värden du väljer för CPU och minne.

När du har skapat en flexibel server för Azure Database for PostgreSQL kan du skala följande oberoende av varandra:

• Beräkningsnivå och SKU.
• Lagringsnivå och storlek.
• Kvarhållningsperiod för säkerhetskopior.

Skala upp eller ned beräkningsnivån mellan Burstable, General Purpose och Memory Optimized för att justera efter arbetsbelastningens behov. På var och en av dessa nivåer väljer du bland ett brett urval av förkonfigurerad maskinvara för olika generationer med varierande antal processorer och mängder installerat minne. Välj det alternativ som stöder dina resurskrav samtidigt som driftskostnaderna minskas och justeras efter dina behov.

Skala upp eller ned antalet virtuella kärnor och installerat minne. Du kan också konfigurera lagringsnivån upp eller ned för att hantera de dataflödes- och IOPS-krav som din arbetsbelastning kräver. Du kan bara öka lagringsstorleken. Beroende på dina krav kan du öka eller minska kvarhållningsperioden för säkerhetskopior mellan 7 och 35 dagar.

Skala dessa resurser med hjälp av flera gränssnitt. Du kan till exempel använda Azure-portalen eller Azure CLI.

Horisontell skalning

Med elastiska kluster i Azure Database for PostgreSQL kan du skala ut databasen horisontellt för att stödja dataarbetslaster som går utöver kapaciteten hos en enskild databasserver. Elastiska kluster ger också möjlighet att köra parallella åtgärder samtidigt över alla noder i ett kluster, vilket avsevärt ökar dataflödet och låser upp ultralåg svarstid. Elastiska kluster erbjuder två modeller för horisontell partitionering av tabeller: radbaserad horisontell partitionering och schemabaserad horisontell partitionering.

Skalning av läsreplikor

Du kan skala upp servern horisontellt genom att skapa läsrepliker. Med läsrepliker kan du skala dina läsarbetslaster över flera separata Azure Database for PostgreSQL Flexible Server-servrar. De påverkar inte den primära serverns prestanda och tillgänglighet.

I en vågrätt skalad konfiguration kan du även skala den primära servern och läsreplikerna lodrätt.

När du ändrar antalet virtuella kärnor eller beräkningsnivån startar servern om så att den nya tilldelade maskinvaran börjar köra serverarbetsbelastningen. Under den här tiden växlar systemet över till den nya servertypen. Du kan inte upprätta nya anslutningar, och alla ogenomförda transaktioner återställs.

Den totala tiden det tar att starta om servern beror på kraschåterställningsprocessen och databasaktiviteten vid tidpunkten för omstarten. Omstarten tar vanligtvis en minut eller mindre, men det kan ta flera minuter. Tidsinställningen beror på transaktionsaktiviteten när omstarten initierades.

Om ditt program är känsligt för förlust av pågående transaktioner som kan inträffa under utökning av datorkapacitet, bör du implementera ett försöksmönster för transaktioner.

Skalning av lagringen kräver i de flesta fall ingen omstart av servern. Mer information finns i lagringsalternativ i Azure Database for PostgreSQL.

Ändringar i kvarhållningsperioden för säkerhetskopior är en onlineåtgärd.

För att förbättra omstartstiden utför du skalningsåtgärder under låg belastning. Den här metoden minskar den tid som krävs för att starta om databasservern.

Skalning med nära noll stilleståndstid

Skalning med nästan inget driftstopp är en funktion som är utformad för att minimera driftstopp när du ändrar lagrings- och beräkningsnivåer. Om du ändrar antalet virtuella kärnor eller ändrar beräkningsnivån startar servern om för att tillämpa den nya konfigurationen. Under den här övergången till den nya servern kan du inte upprätta nya anslutningar.

Normalt tar den här processen allt från 2 till 10 minuter med regelbunden skalning. Genom att använda skalningsfunktionen för nästan noll driftstopp kan du minska den här varaktigheten till mindre än 30 sekunder. Den här minskningen av stilleståndstiden under skalning av resurser förbättrar den totala tillgängligheten för din databasinstans.

Så här fungerar det

När du uppdaterar din Azure Database for PostgreSQL flexibla servern i skalningsscenarier skapar tjänsten en ny virtuell dator för servern med den uppdaterade konfigurationen. Sedan synkroniseras den med den virtuella datorn som för närvarande kör servern och växlar sedan till den nya virtuella datorn med ett kort avbrott. En bakgrundsprocess eliminerar den gamla virtuella datorn.

Den här processen möjliggör sömlösa uppdateringar med minimal stilleståndstid och utlöses automatiskt när du ändrar lagrings- eller beräkningsnivåer. Du behöver inte vidta några åtgärder för att använda den här funktionen. Den här funktionen stöds för både Azure Database for PostgreSQL – flexibel server med HA och utan HA.

För horisontellt skalbara konfigurationer, som består av en primär server och en eller flera läsrepliker, måste skalningsåtgärder följa en specifik sekvens för att säkerställa datakonsekvens och minimera driftstopp. Mer information om sekvensen finns i skala med läsrepliker.

Exakta förväntningar på stilleståndstid

• Stilleståndstid: I de flesta fall varierar stilleståndstiden från 10 till 30 sekunder.
• Andra överväganden: Efter en skalningshändelse finns det en inbyggd DNS-period Time-To-Live (TTL) på cirka 30 sekunder. Skalningsprocessen styr inte direkt den här perioden. Det är en standarddel av DNS-beteendet. Ur ett programperspektiv kan den totala stilleståndstiden under skalningen vara mellan 40 och 60 sekunder.

Överväganden och begränsningar

• För att skalning med nära nog noll driftstopp ska fungera, tillåt alla inkommande och utgående anslutningar mellan IP-adresserna i det delegerade undernätet när du använder virtuell nätverksintegrering. Om du inte tillåter dessa anslutningar fungerar inte skalningsprocessen nästan utan driftstopp, och skalning sker via det vanliga arbetsflödet för skalning.
• Skalning av nästan noll driftstopp fungerar inte om det finns regionala kapacitetsbegränsningar eller kvotgränser för din prenumeration.
• Skalning av nästan noll driftstopp fungerar inte för en replikserver, eftersom den endast stöds på den primära servern. För replikservrar går skalningsåtgärden automatiskt igenom den vanliga processen.
• Skalning med nästintill noll driftstopp fungerar inte om en server som injicerats i ett virtuellt nätverk inte har tillräckligt med användbara IP-adresser i det delegerade undernätet. Om du har en fristående server krävs en extra IP-adress. För en server med hög tillgänglighet aktiverat krävs två extra IP-adresser.
• Logiska replikeringsplatser bevaras inte vid en redundansväxling med nära nog noll driftstopp. Använd tillägget pg_failover_slot för att upprätthålla logiska replikeringsplatser och säkerställa datakonsistens efter en skalningsoperation. Mer information finns i aktivera tillägget pg_failover_slots i en instans av flexibel server.
• Skalning med nästan ingen nedtid fungerar inte med ologgade tabeller. Om du använder icke-loggade tabeller för några av dina data förlorar du all data i dessa tabeller efter skalning med nära noll driftstopp.
• Nästan noll fungerar inte om du skalar beräkningskapaciteten på din server från eller till en beräkningsstorlek på 1 eller 2 virtuella kärnor inom Burstable-nivån.

Relaterat innehåll

• Hantera Azure-databasen för PostgreSQL