Skala resurser i Azure Database for PostgreSQL

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

Vertikal skalning

Du kan skala instansen lodrätt genom att lägga till fler resurser i din flexibla Azure Database for PostgreSQL-serverinstans. Du kan öka eller minska antalet processorer och det tilldelade minnet.

Nätverkets dataflöde för din instans beror på de värden du väljer för CPU och minne.

När du har skapat en flexibel Azure Database för PostgreSQL-serverinstans kan du skala dem oberoende.

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

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

Du kan 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.

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

Kommentar

När du har ökat storleken på lagringen som tilldelats din instans kan du inte krympa den till en mindre storlek.

Horisontell skalning

Med elastiska Azure Database for PostgreSQL-kluster kan du skala ut databasen vågrätt för att stödja dataarbetsbelastningar som sträcker sig bortom funktionerna i en enskild databasinstans. Elastiska kluster gör det också möjligt 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

En annan metod för att skala instansen vågrätt är genom att skapa läsrepliker. Med läsrepliker kan du skala dina läsarbetsbelastningar till separata flexibla Azure Database for PostgreSQL-serverinstanser. De påverkar inte prestanda och tillgänglighet för den primära instansen.

I en horisontellt skalad konfiguration kan du även skala den primära instansen och läsreplikor vertikalt.

När du ändrar antalet virtuella kärnor eller beräkningsnivån startas instansen 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. Det går inte att upprätta några 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.

Nästan noll skalning av stilleståndstid

Skalning av nästan noll driftstopp är en funktion som är utformad för att minimera stilleståndstiden 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 inga nya anslutningar upprättas.

Normalt kan den här processen ta mellan 2 och 10 minuter med regelbunden skalning. Med skalningsfunktionen för nästan noll driftstopp minskas 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.

Hur det fungerar

När du uppdaterar azure database for PostgreSQL-instansen för flexibel server i skalningsscenarier skapar tjänsten en ny virtuell dator för servern med den uppdaterade konfigurationen. Sedan synkroniseras den med den virtuella dator som för närvarande kör din instans och växlar sedan till den nya virtuella datorn med ett kort avbrott. Sedan eliminerar en bakgrundsprocess 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 HA- och icke-HA Azure Database for PostgreSQL flexibel serverinstans.

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.

Kommentar

Skalning av driftstopp nära noll är standardåtgärdstypen . När följande begränsningar påträffas växlar systemet till regelbunden skalning, vilket innebär mer stilleståndstid jämfört med nästan noll nedtidsskalning.

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.

Beaktanden och begränsningar

• För att skalning av driftstopp på nästan noll ska fungera tillåter du alla inkommande och utgående anslutningar mellan IP-adresserna i det delegerade undernätet när du använder integrerat nätverk i det virtuella nätverket. 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 av driftstopp nästan noll fungerar inte om en virtuell nätverksinmatad server 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 instans med hög tillgänglighet aktiverat krävs två extra IP-adresser.
• Logiska replikeringsfack bevaras inte under en redundansväxling på nästan noll. Om du vill underhålla logiska replikeringsfack och säkerställa datakonsekvens efter en skalningsåtgärd använder du tillägget pg_failover_slot . Mer information finns i aktivera tillägget pg_failover_slots i en instans av en flexibel server.
• Skalning av nästan noll driftstopp 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