Gränser i Azure Database for PostgreSQL

I följande avsnitt beskrivs kapacitets- och funktionsgränser för flexibla serverinstanser i Azure Database for PostgreSQL. Om du vill lära dig mer om resursnivåer (beräkning, minne, lagring) kan du läsa artiklarna om beräkning och lagring .

Maximalt antal anslutningar

I följande tabell visas det maximala standardantalet anslutningar för varje prisnivå och vCore-konfiguration. En flexibel Azure Database for PostgreSQL-serverinstans reserverar 15 anslutningar för fysisk replikering och övervakning av den flexibla serverinstansen Azure Database for PostgreSQL. Tabellen minskar därför värdet för maximala användaranslutningar med 15 från det totala maximala antalet anslutningar.

De reserverade anslutningsplatserna, som för närvarande är 15 till antalet, kan ändras. Vi rekommenderar att du regelbundet verifierar de totala reserverade anslutningarna på servern. Du beräknar det här talet genom att summera värdena för reserved_connections serverparametrarna och superuser_reserved_connections . Det maximala antalet tillgängliga användaranslutningar är max_connections - (reserved_connections + superuser_reserved_connections).

Systemet beräknar standardvärdet för max_connections serverparametern när du etablerar instansen av en flexibel Azure Database for PostgreSQL-server, baserat på det produktnamn som du väljer för beräkningen. Eventuella efterföljande ändringar av produktval till den beräkning som stöder instansen påverkar inte standardvärdet för serverparametern för den instansen max_connections . Vi rekommenderar att du när du ändrar den produkt som tilldelats till en instans också justerar värdet för parametern max_connections enligt värdena i föregående tabell.

Ändra värdet för max_connections

När du först konfigurerar din flexibla Azure Database for Postgres-serverinstans bestämmer den automatiskt det högsta antalet anslutningar som den kan hantera samtidigt. Serverns konfiguration avgör det här numret och du kan inte ändra det.

Du kan dock använda inställningen max_connections för att justera hur många anslutningar som tillåts vid en viss tidpunkt. När du har ändrat den här inställningen måste du starta om servern för att den nya gränsen ska börja fungera.

När anslutningar överskrider gränsen kan du få följande fel:

FATAL: sorry, too many clients already.

När du använder en flexibel Azure Database for PostgreSQL-serverinstans för en upptagen databas med ett stort antal samtidiga anslutningar kan det uppstå en betydande belastning på resurserna. Den här belastningen kan leda till hög CPU-användning, särskilt när många anslutningar upprättas samtidigt och när anslutningarna har korta varaktigheter (mindre än 60 sekunder). Dessa faktorer kan påverka databasens övergripande prestanda negativt genom att öka den tid som ägnas åt att bearbeta anslutningar och frånkopplingar.

Varje anslutning i en flexibel Azure Database for PostgreSQL-serverinstans, oavsett om den är inaktiv eller aktiv, förbrukar en betydande mängd resurser från databasen. Den här förbrukningen kan leda till prestandaproblem utöver hög CPU-användning, till exempel disk- och låskonkurring. I artikeln Antal databasanslutningar på PostgreSQL Wiki beskrivs den här artikeln mer detaljerat. Mer information finns i Identifiera och lösa anslutningsprestanda i Azure Postgres.

Funktionsbegränsningar

I följande avsnitt listas överväganden för vad som stöds och inte stöds för dina flexibla serverinstanser i Azure Database for PostgreSQL.

Skalningsåtgärder

• För närvarande kräver uppskalning av serverlagringen en omstart av servern.
• Serverlagring kan bara skalas i steg om 2x. Mer information finns i Lagring .
• För närvarande har vi inte stöd för att minska serverlagringsstorleken. Det enda sättet att göra den här åtgärden är att dumpa och återställa den till en ny flexibel Azure Database for PostgreSQL-serverinstans.

Förvaring

• När du har konfigurerat lagringsstorleken kan du inte minska den. Du måste skapa en ny server med önskad lagringsstorlek, utföra en manuell dumpnings- och återställningsåtgärd och migrera dina databaser till den nya servern.
• När lagringsanvändningen når 95% eller om den tillgängliga kapaciteten är mindre än 5 GiB (beroende på vilket som är mer) växlar systemet automatiskt servern till skrivskyddat läge för att undvika fel som är associerade med diskfyllda situationer. I sällsynta fall kan servern fortfarande få slut på lagringsutrymme om datatillväxten överskrider den tid det tar att växla till skrivskyddat läge. Du kan aktivera automatisk lagringsväxning för att undvika dessa problem och automatiskt skala lagringen baserat på dina arbetsbelastningskrav.
• Vi rekommenderar att du anger aviseringsregler för storage used eller storage percent när de överskrider vissa tröskelvärden så att du proaktivt kan vidta åtgärder som att öka lagringsstorleken. Du kan till exempel ange en avisering om lagringsprocenten överskrider 80 % användning.
• Om du använder logisk replikering måste du släppa det logiska replikeringsfacket på den primära servern om motsvarande prenumerant inte längre finns. Annars ackumuleras WAL-filerna (write-ahead loggning) i den primära filen och fyller upp lagringen. Om lagringen överskrider ett visst tröskelvärde och om det logiska replikeringsfacket inte används (på grund av en otillgänglig prenumerant) släpper en flexibel Azure Database for PostgreSQL-serverinstans automatiskt det oanvända logiska replikeringsfacket. Den här åtgärden frigör ackumulerade WAL-filer och förhindrar att servern blir otillgänglig eftersom lagringen är fylld.
• Vi stöder inte skapandet av tabellområden. Om du skapar en databas ska du inte ange något tabellområdesnamn. En flexibel Azure Database for PostgreSQL-serverinstans använder standardtabellområdet som malldatabasen ärver. Det är osäkert att tillhandahålla ett tabellområde som det tillfälliga, eftersom vi inte kan se till att sådana objekt förblir beständiga efter händelser som serveromstarter och redundansväxlingar med hög tillgänglighet (HA).

Nätverk

• Vi stöder för närvarande inte att flytta in och ut ur ett virtuellt nätverk.
• Vi stöder för närvarande inte att kombinera offentlig åtkomst med distribution i ett virtuellt nätverk.
• Virtuella nätverk stöder inte brandväggsregler. Du kan använda nätverkssäkerhetsgrupper i stället.
• Databasservrar för offentlig åtkomst kan ansluta till det offentliga Internet. till exempel via postgres_fdw. Du kan inte begränsa den här åtkomsten. Servrar i virtuella nätverk kan ha begränsad utgående åtkomst via nätverkssäkerhetsgrupper.

Hög tillgänglighet

• Se Begränsningar för hög tillgänglighet.

Tillgänglighetszoner

• Vi stöder för närvarande inte manuellt flytt av servrar till en annan tillgänglighetszon. Men genom att använda den önskade tillgänglighetszonen som väntelägeszon kan du aktivera HA. När du har upprättat väntelägeszonen kan du redundansväxla till den och sedan inaktivera HA.

Postgres-motor, tillägg och PgBouncer

• En flexibel Azure Database for PostgreSQL-serverinstans stöder alla funktioner i PostgreSQL-motorn, inklusive partitionering, logisk replikering och externa dataomslutningar.
• En flexibel Azure Database for PostgreSQL-serverinstans stöder alla contrib tillägg med mera. Mer information finns i PostgreSQL-tillägg.
• Burst-servrar har för närvarande inte åtkomst till den inbyggda PgBouncer-anslutningspoolen.

Stoppa/starta åtgärder

• När du har stoppat Azure Database for PostgreSQL-instansen för den flexibla servern startar den automatiskt efter sju dagar.

Schemalagt underhåll

• Du kan ändra fönstret för anpassat underhåll till valfri dag/tid i veckan. Ändringar som du gör när du har fått underhållsmeddelandet påverkar dock inte nästa underhåll. Ändringarna börjar gälla endast med följande månatliga schemalagda underhåll.

Serversäkerhetskopior

• Systemet hanterar säkerhetskopior. Du kan för närvarande inte köra säkerhetskopior manuellt. Vi rekommenderar att du använder pg_dump i stället.

• Den första ögonblicksbilden är en fullständig säkerhetskopia och på varandra följande ögonblicksbilder är differentiella säkerhetskopior. Differentiella säkerhetskopior säkerhetskopierar endast ändrade data sedan den senaste säkerhetskopieringen av ögonblicksbilden.

  Om storleken på databasen till exempel är 40 GB och din etablerade lagring är 64 GB är den första säkerhetskopieringen av ögonblicksbilden 40 GB. Om du nu ändrar 4 GB data blir nästa differentiella säkerhetskopieringsstorlek för ögonblicksbilder bara 4 GB. Transaktionsloggarna (loggningsloggarna) är separata från de fullständiga och differentiella säkerhetskopiorna och arkiveras kontinuerligt.

Serveråterställning

• När du använder funktionen punkt-i-tid-återställning (PITR) skapar systemet den nya servern med samma beräknings- och lagringskonfigurationer som den server som den baseras på.
• Systemet återställer databasservrar i virtuella nätverk till samma virtuella nätverk när du återställer från en säkerhetskopia.
• Den nya servern som skapades under en återställning har inte de brandväggsregler som fanns på den ursprungliga servern. Du måste skapa brandväggsregler separat för den nya servern.
• Vi stöder inte återställning till en annan prenumeration. Som en lösning kan du återställa servern inom samma prenumeration och sedan migrera den återställde servern till en annan prenumeration.

Säkerhet

• Postgres 14 och senare versioner inaktiverar MD5-hashning och systemet hashar interna Postgres-lösenord med hjälp av SCRAM-SHA-256-metoden endast.

Relaterat innehåll

• Beräkningsalternativ i Azure Database for PostgreSQL.
• Lagringsalternativ i Azure Database for PostgreSQL.
• Versioner av PostgreSQL som stöds i Azure Database for PostgreSQL.