Gränser i Azure Database for PostgreSQL – enskild server

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

I följande avsnitt beskrivs kapacitets- och funktionsgränser i databastjänsten. Om du vill lära dig mer om resursnivåer (beräkning, minne, lagring) kan du läsa artikeln prisnivåer .

Maximalt antal anslutningar

Det maximala antalet anslutningar per prisnivå och virtuella kärnor visas nedan. Azure-systemet kräver fem anslutningar för att övervaka Azure Database for PostgreSQL-servern.

Prisnivå virtuella kärnor Max antal anslutningar Maximalt antal användaranslutningar
Basic 1 55 50
Basic 2 105 100
Generell användning 2 150 145
Generell användning 4 250 245
Generell användning 8 480 475
Generell användning 16 950 945
Generell användning 32 1500 1495
Generell användning 64 1900 1895
Minnesoptimerad 2 300 295
Minnesoptimerad 4 500 495
Minnesoptimerad 8 960 955
Minnesoptimerad 16 1900 1895
Minnesoptimerad 32 1987 1982

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

ALLVARLIGT: Tyvärr, för många klienter redan

Viktigt

För bästa möjliga upplevelse rekommenderar vi att du använder en anslutningspool som pgBouncer för att effektivt hantera anslutningar.

En PostgreSQL-anslutning, även inaktiv, kan uppta upp till 2 MB minne. Det tar också tid att skapa nya anslutningar. De flesta program begär många kortvariga anslutningar, vilket förvärrar den här situationen. Resultatet är färre resurser som är tillgängliga för din faktiska arbetsbelastning, vilket leder till sämre prestanda. En anslutningspool som minskar inaktiva anslutningar och återanvänder befintliga anslutningar hjälper dig att undvika detta. Mer information finns i vårt blogginlägg.

Funktionsbegränsningar

Skalningsåtgärder

  • Dynamisk skalning till och från prisnivåerna Basic stöds för närvarande inte.
  • Minskande serverlagringsstorlek stöds för närvarande inte.

Serverversionsuppgraderingar

  • Automatisk migrering mellan större databasmotorversioner stöds för närvarande inte. Om du vill uppgradera till nästa huvudversion tar du en dump och återställer den till en server som har skapats med den nya motorversionen.

Observera att före PostgreSQL version 10 ansåg Principen för PostgreSQL-versionshantering att en högre versionsuppgradering var en ökning av det första eller andra numret (till exempel ansågs 9,5 till 9,6 vara en högre versionsuppgradering). Från och med version 10 betraktas endast en ändring i det första talet som en högre versionsuppgradering (till exempel är 10.0 till 10.1 en delversionsuppgradering och 10 till 11 är en högre versionsuppgradering).

VNet-tjänstslutpunkter

  • Stöd för VNet-tjänstslutpunkter är endast för Ogólnego przeznaczenia- och minnesoptimerade servrar.

Återställa en server

  • När du använder PITR-funktionen skapas den nya servern med samma konfigurationer på prisnivå som den server som den baseras på.
  • Den nya servern som skapades under en återställning har inte de brandväggsregler som fanns på den ursprungliga servern. Brandväggsregler måste konfigureras separat för den nya servern.
  • Det går inte att återställa en borttagen server.

UTF-8 tecken i Windows

  • I vissa fall stöds INTE UTF-8-tecken helt i Open Source PostgreSQL i Windows, vilket påverkar Azure Database for PostgreSQL. Mer information finns i tråden på Bugg #15476 i postgresql-archive .

GSS-fel

Om du ser ett fel som är relaterat till GSS använder du förmodligen en nyare klient-/drivrutinsversion som Azure Postgres – enskild server inte har fullständigt stöd för än. Det här felet är känt för att påverka JDBC-drivrutinsversion 42.2.15 och 42.2.16.

  • Uppdateringen förväntas vara klar i slutet av november. Använd en fungerande drivrutinsversion tills dess.
  • Du kan också inaktivera GSS-begäran. Använd en anslutningsparameter som gssEncMode=disable.

Minskning av lagringsstorlek

Det går inte att minska lagringsstorleken. Du måste skapa en ny server med önskad lagringsstorlek, utföra manuell dumpning och återställning och migrera dina databaser till den nya servern.

Nästa steg