Begränsningar i Azure Database for PostgreSQL – flexibel server

  • Artikel

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

I följande avsnitt beskrivs kapacitets- och funktionsgränser i Azure Database for PostgreSQL – flexibel server. Om du vill lära dig mer om resursnivåer (beräkning, minne eller lagring) kan du läsa artikeln Beräkning och lagring .

Maximalt antal anslutningar

I följande tabell visas det maximala standardantalet anslutningar för varje prisnivå och vCore-konfiguration. Azure Database for PostgreSQL – flexibel server reserverar 15 anslutningar för fysisk replikering och övervakning av Azure Database for PostgreSQL– flexibel serverinstans. Därför minskas värdet för maximala användaranslutningar som anges i tabellen med 15 från det totala maximala antalet anslutningar.

Produktnamn Virtuella kärnor Minnesstorlek Maximalt antal anslutningar Maximala användaranslutningar
Burstbar
B1ms 1 2 GiB 50 35
B2s 2 4 GiB 429 414
B2ms 2 8 GiB 859 844
B4ms 4 16 GiB 1,718 1,703
B8ms 8 32 GiB 3,437 3,422
B12ms 12 48 GiB 5 000 4,985
B16ms 16 64 GiB 5 000 4,985
B20ms 20 80 GiB 5 000 4,985
Generell användning
D2s_v3/D2ds_v4/D2ds_v5/D2ads_v5 2 8 GiB 859 844
D4s_v3/D4ds_v4/D4ds_v5/D4ads_v5 4 16 GiB 1,718 1,703
D8s_v3/D8ds_V4/D8ds_v5/D8ads_v5 8 32 GiB 3,437 3,422
D16s_v3/D16ds_v4/D16ds_v5/D16ads_v5 16 64 GiB 5 000 4,985
D32s_v3/D32ds_v4/D32ds_v5/D32ads_v5 32 128 GiB 5 000 4,985
D48s_v3/D48ds_v4/D48ds_v5/D48ads_v5 48 192 GiB 5 000 4,985
D64s_v3/D64ds_v4/D64ds_v5/D64ads_v5 64 256 GiB 5 000 4,985
D96ds_v5/D96ads_v5 96 384 GiB 5 000 4,985
Minnesoptimerad
E2s_v3/E2ds_v4/E2ds_v5/E2ads_v5 2 16 GiB 1,718 1,703
E4s_v3/E4ds_v4/E4ds_v5/E4ads_v5 4 32 GiB 3,437 3,422
E8s_v3/E8ds_v4/E8ds_v5/E8ads_v5 8 64 GiB 5 000 4,985
E16s_v3/E16ds_v4/E16ds_v5/E16ads_v5 16 128 GiB 5 000 4,985
E20ds_v4/E20ds_v5/E20ads_v5 20 160 GiB 5 000 4,985
E32s_v3/E32ds_v4/E32ds_v5/E32ads_v5 32 256 GiB 5 000 4,985
E48s_v3/E48ds_v4/E48ds_v5/E48ads_v5 48 384 GiB 5 000 4,985
E64s_v3/E64ds_v4/E64ds_v5/E64ads_v5 64 432 GiB 5 000 4,985
E96ds_v5/E96ads_v5 96 672 GiB 5 000 4,985

De reserverade anslutningsfacken, som för närvarande är 15 år, 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).

Standardvärdet för max_connections serverparametern beräknas när du etablerar instansen av en flexibel Azure Database for PostgreSQL-server baserat på det produktnamn som du väljer för dess beräkning. Eventuella efterföljande ändringar av produktval i beräkningen som stöder den flexibla servern 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. Det här numret baseras på serverns konfiguration och kan inte ändras.

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.

Varning

Även om det är möjligt att öka värdet max_connections för utöver standardinställningen rekommenderar vi det.

Instanser kan stöta på problem när arbetsbelastningen expanderas och kräver mer minne. När antalet anslutningar ökar ökar även minnesanvändningen. Instanser med begränsat minne kan stöta på problem som krascher eller långa svarstider. Även om ett högre värde för max_connections kan vara acceptabelt när de flesta anslutningar är inaktiva kan det leda till betydande prestandaproblem när de har blivit aktiva.

Om du behöver fler anslutningar rekommenderar vi att du i stället använder PgBouncer, den inbyggda Azure-lösningen för hantering av anslutningspooler. Använd den i transaktionsläge. Till att börja med rekommenderar vi att du använder konservativa värden genom att multiplicera de virtuella kärnorna inom intervallet 2 till 5. Övervaka därefter noggrant resursutnyttjande och programprestanda för att säkerställa en smidig drift. Detaljerad information om PgBouncer finns i PgBouncer i Azure Database for PostgreSQL – flexibel server.

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-server 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.

Tänk på att varje anslutning i Azure Database for PostgreSQL– flexibel server, 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 Number of Database Anslut ions på PostgreSQL Wiki beskrivs det här avsnittet mer detaljerat. Mer information finns i Identifiera och lösa anslutningsprestanda i Azure Database for PostgreSQL – flexibel server.

Funktionsbegränsningar

I följande avsnitt listas överväganden för vad som stöds och inte stöds i en flexibel Azure Database for PostgreSQL-server.

Skalningsåtgärder

  • För närvarande kräver uppskalning av serverlagringen en omstart av servern.
  • Du kan bara skala serverlagring i steg om 2 gånger. Mer information finns i Beräkning och lagring.

Lagring

  • 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äxlas servern automatiskt 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 Azure Database for PostgreSQL flexibel server automatiskt det oanvända logiska replikeringsfacket. Den å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. Azure Database for PostgreSQL – flexibel server använder standardservern som ärvs från malldatabasen. 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

  • Det går för närvarande inte att flytta in och ut från ett virtuellt nätverk.
  • Det går för närvarande inte att kombinera offentlig åtkomst med distribution i ett virtuellt nätverk.
  • Brandväggsregler stöds inte i virtuella nätverk. 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

Tillgänglighetszoner

  • Det går för närvarande inte att flytta servrar till en annan tillgänglighetszon manuellt. 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

  • Postgres 10 och äldre versioner stöds inte eftersom communityn med öppen källkod drog tillbaka dem. Om du måste använda någon av dessa versioner måste du använda alternativet Azure Database for PostgreSQL – enskild server , som stöder de äldre huvudversionerna 9.5, 9.6 och 10.
  • Azure Database for PostgreSQL – flexibel server stöder alla contrib tillägg med mera. Mer information finns i PostgreSQL-tillägg.
  • Den inbyggda PgBouncer-anslutningspoolen är för närvarande inte tillgänglig för Burstable-servrar.

Stoppa/starta åtgärder

  • När du har stoppat azure database for PostgreSQL-instansen för flexibel server startar den automatiskt efter 7 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. Det finns för närvarande inget sätt att 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 blir 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 för återställning till tidpunkt (PITR) skapas den nya servern med samma beräknings- och lagringskonfigurationer som den server som den baseras på.
  • Databasservrar i virtuella nätverk återställs 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.
  • Återställning till en annan prenumeration stöds inte. Som en lösning kan du återställa servern inom samma prenumeration och sedan migrera den återställde servern till en annan prenumeration.

Nästa steg