Begränsningar i Azure Database för PostgreSQL – Flexibel server

I följande avsnitt beskrivs kapacitets- och funktionsgränser för Azure Database for PostgreSQL flexibla servrar. Information om resursnivåer för beräkning, minne och lagring finns i 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 Azure Database for PostgreSQL flexibel server reserverar 15 anslutningar för fysisk replikering och övervakning av den Azure Database for PostgreSQL flexibla servern. 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 parametrarna reserved_connections 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 parametern max_connections när du etablerar instansen av Azure Database for PostgreSQL flexibel server, baserat på produktnamnet som du väljer för dess beräkning. Eventuella efterföljande ändringar av produktval till den beräkning som stöder instansen påverkar inte standardvärdet för parametern 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 konfigurerar din Azure Database for PostgreSQL flexibla servern avgör den automatiskt det högsta antalet samtidiga anslutningar som den kan hantera. 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 Azure Database for PostgreSQL flexibel server för en upptagen databas med ett stort antal samtidiga anslutningar kan det uppstå 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 på en 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 Antal databasanslutningar på PostgreSQL Wiki beskrivs det här avsnittet 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 Azure Database for PostgreSQL flexibla servrar.

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 .
• Det går inte att minska serverlagringsstorleken. För att minska lagringsstorleken måste du dumpa och återställa till en ny Azure Database for PostgreSQL flexibel server.

Storage

• 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 den logiska replikeringsplatsen inte används (på grund av en otillgänglig prenumerant) släpper en Azure Database for PostgreSQL flexibel server 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.
• Det går inte att skapa tabellytor. Om du skapar en databas ska du inte ange något tabellområdesnamn. En flexibel server i Azure Database for PostgreSQL använder standardtablespace som ärvs av malldatabasen. Det är osäkert att ange en tabellyta såsom den tillfälliga, eftersom tjänsten inte kan garantera att sådana objekt består efter händelser som serveromstarter och växlingar vid hög tillgänglighet (HA).
• Överblivna datafiler och diskanvändningsavvikelser: I sällsynta fall kan PostgreSQL lämna överblivna datafiler på disken. Dessa filer har inte längre motsvarande poster i databasens systemkatalog (som spårar alla tabeller och data). Det här villkoret kan inträffa om en tabell skapas och fylls i i en transaktion som inte kan slutföras (till exempel på grund av en serverkrasch eller ett avbrott), vilket resulterar i ett matchningsfel mellan den databasrapporterade storleken och den faktiska diskanvändningen. Det här beteendet kommer från PostgreSQL-communityns kodbas och är inte specifikt för Azure. PostgreSQL-communityn är medveten om problemet och utforskar förbättringar för automatisk rensning i framtida versioner. Mer information finns i: PostgreSQL: Föräldralösa filer i PostgreSQL. Det här villkoret kan leda till oväntat hög disk- eller lagringsförbrukning.
  • Hur man identifierar: Jämför den databasrapporterade storleken (med frågor som ) med mått från Azure-portalen för faktisk diskanvändning. Om det finns en betydande avvikelse kan överblivna filer vara orsaken. I såfall:
    • Kör VACUUM FULL på berörda tabeller för att frigöra utrymme (obs! det här är resursintensivt, kräver ett tabelllås och kan kräva stilleståndstid).
    • Du kan också använda verktyg som pg_repack eller pg_squeeze tillägg för omorganisering utan avbrott, men testa i en icke-produktionsmiljö först.
    • Övervaka med hjälp av Azure Portal-metrik för att nå tröskelvärden för diskanvändning. Om problemet kvarstår eller om du är osäker kan du kontakta Azure Support för att få hjälp.
  • Så här förhindrar du: Se till att transaktioner hanteras korrekt i dina program för att minimera ofullständiga åtgärder. Övervaka regelbundet diskanvändningen via Azure-portalens mått. Uppgradering till den senaste PostgreSQL-versionen som stöds kan innehålla community-korrigeringar för relaterade problem.

Nätverkande

• 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 skapat standbyzonen kan du växla över till den och sedan stänga av HA.

Postgres-motor, tillägg och PgBouncer

• En Azure Database for PostgreSQL flexibel server stöder alla funktioner i PostgreSQL-motorn, inklusive partitionering, logisk replikering och externa dataomslutningar.
• En Azure Database for PostgreSQL flexibel server 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 flexibel server 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.

Security

• PostgreSQL 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