Delen via

Beperkingen in Azure Database for PostgreSQL - flexibele server

  • Artikel

VAN TOEPASSING OP: Azure Database for PostgreSQL - Flexibele server

In de volgende secties worden capaciteits- en functionele limieten beschreven in Azure Database for PostgreSQL Flexibele server. Als u meer wilt weten over resourcelagen (compute, geheugen, opslag), raadpleegt u de artikelen over berekeningen en opslag .

Maximum aantal verbindingen

In de volgende tabel ziet u het standaard maximum aantal verbindingen voor elke prijscategorie en vCore-configuratie. Azure Database for PostgreSQL Flexibele server reserveert 15 verbindingen voor fysieke replicatie en bewaking van het flexibele serverexemplaren van Azure Database for PostgreSQL. Daarom wordt de waarde voor maximale gebruikersverbindingen die in de tabel worden vermeld, verminderd met 15 van de totale maximumverbindingen.

Productnaam vCores Geheugengrootte Maximum aantal verbindingen Maximum aantal gebruikersverbindingen
Burstable
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
Algemeen doel
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
Geoptimaliseerd voor geheugen
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 gereserveerde verbindingssites, momenteel op 15, kunnen veranderen. We adviseren regelmatig de totale gereserveerde verbindingen op de server te controleren. U berekent dit getal door de waarden van de reserved_connections en superuser_reserved_connections serverparameters op te tellen. Het maximum aantal beschikbare gebruikersverbindingen is max_connections - ( + reserved_connectionssuperuser_reserved_connections).

De standaardwaarde voor de max_connections serverparameter wordt berekend wanneer u het exemplaar van de flexibele Server van Azure Database for PostgreSQL inricht op basis van de productnaam die u selecteert voor de berekening. Eventuele volgende wijzigingen van productselectie in de berekening die ondersteuning bieden voor de flexibele server, hebben geen invloed op de standaardwaarde voor de max_connections serverparameter van dat exemplaar. We raden u aan dat wanneer u het product wijzigt dat is toegewezen aan een exemplaar, u ook de waarde voor de max_connections parameter aanpast op basis van de waarden in de voorgaande tabel.

De max_connections-waarde wijzigen

Wanneer u uw exemplaar van azure Database for Postgres flexibele server voor het eerst instelt, wordt automatisch het hoogste aantal verbindingen bepaald dat gelijktijdig kan worden verwerkt. Dit nummer is gebaseerd op de configuratie van uw server en kan niet worden gewijzigd.

U kunt echter de max_connections instelling gebruiken om aan te passen hoeveel verbindingen op een bepaald moment zijn toegestaan. Nadat u deze instelling hebt gewijzigd, moet u de server opnieuw opstarten om de nieuwe limiet te laten werken.

Let op

Hoewel het mogelijk is om de waarde van max_connections buiten de standaardinstelling te verhogen, raden we dit aan.

Exemplaren kunnen problemen ondervinden wanneer de workload wordt uitgebreid en meer geheugen vereist. Naarmate het aantal verbindingen toeneemt, neemt het geheugengebruik ook toe. Exemplaren met beperkt geheugen kunnen problemen ondervinden, zoals crashes of hoge latentie. Hoewel een hogere waarde max_connections mogelijk acceptabel is wanneer de meeste verbindingen niet actief zijn, kan dit leiden tot aanzienlijke prestatieproblemen nadat ze actief zijn geworden.

Als u meer verbindingen nodig hebt, raden we u aan in plaats daarvan PgBouncer te gebruiken, de ingebouwde Azure-oplossing voor beheer van verbindingsgroepen. Gebruik deze in de transactiemodus. Om te beginnen raden we u aan conservatieve waarden te gebruiken door de vCores binnen het bereik van 2 tot 5 te vermenigvuldigen. Controleer daarna zorgvuldig het resourcegebruik en de prestaties van toepassingen om een soepele werking te garanderen. Zie PgBouncer in Azure Database for PostgreSQL - Flexible Server voor gedetailleerde informatie over PgBouncer.

Wanneer verbindingen de limiet overschrijden, wordt mogelijk de volgende fout weergegeven:

FATAL: sorry, too many clients already.

Wanneer u een flexibele Azure Database for PostgreSQL-server gebruikt voor een drukke database met een groot aantal gelijktijdige verbindingen, is er mogelijk een aanzienlijke belasting op resources. Deze belasting kan leiden tot een hoog CPU-gebruik, met name wanneer veel verbindingen gelijktijdig tot stand worden gebracht en wanneer verbindingen korte duur hebben (minder dan 60 seconden). Deze factoren kunnen negatieve invloed hebben op de algehele databaseprestaties door de tijd te verhogen die wordt besteed aan het verwerken van verbindingen en verbroken verbindingen.

Houd er rekening mee dat elke verbinding in azure Database for PostgreSQL flexibele server, ongeacht of deze niet actief of niet actief is, een aanzienlijke hoeveelheid resources uit uw database verbruikt. Dit verbruik kan leiden tot prestatieproblemen buiten hoog CPU-gebruik, zoals schijf- en vergrendelingsconflicten. In het artikel Over het aantal databaseverbindingen op de PostgreSQL-wiki wordt dit onderwerp uitvoeriger besproken. Zie De verbindingsprestaties in Azure Database for PostgreSQL Flexibele server identificeren en oplossen voor meer informatie.

Functionele beperkingen

De volgende secties bevatten overwegingen voor wat wel en niet wordt ondersteund in flexibele Azure Database for PostgreSQL-server.

Schaalbewerkingen

  • Op dit moment moet de serveropslag opnieuw worden opgestart.
  • Serveropslag kan alleen in stappen van 2x worden geschaald. Zie Storage voor meer informatie.
  • Het verlagen van de opslaggrootte van de server wordt momenteel niet ondersteund. De enige manier om dit te doen is dumpen en herstellen naar een nieuw exemplaar van een flexibele Azure Database for PostgreSQL-server.

Storage

  • Nadat u de opslaggrootte hebt geconfigureerd, kunt u deze niet verkleinen. U moet een nieuwe server maken met de gewenste opslaggrootte, een handmatige dump- en herstelbewerking uitvoeren en uw databases migreren naar de nieuwe server.
  • Wanneer het opslaggebruik 95% bereikt of als de beschikbare capaciteit kleiner is dan 5 GiB (afhankelijk van wat er meer is), wordt de server automatisch overgeschakeld naar de modus Alleen-lezen om fouten met betrekking tot de volledige schijf te voorkomen. In zeldzame gevallen, als de snelheid van gegevensgroei de tijd overschrijdt die nodig is om over te schakelen naar de modus Alleen-lezen, kan uw server mogelijk nog steeds geen opslagruimte meer bevatten. U kunt automatische groei van opslag inschakelen om deze problemen te voorkomen en uw opslag automatisch te schalen op basis van uw workloadvereisten.
  • We raden u aan waarschuwingsregels in te stellen voor storage used of storage percent wanneer ze bepaalde drempelwaarden overschrijden, zodat u proactief actie kunt ondernemen, zoals het vergroten van de opslaggrootte. U kunt bijvoorbeeld een waarschuwing instellen als het opslagpercentage hoger is dan 80% gebruik.
  • Als u logische replicatie gebruikt, moet u de logische replicatiesite op de primaire server verwijderen als de bijbehorende abonnee niet meer bestaat. Anders verzamelen de WAL-bestanden (Write-Ahead Logging) zich in de primaire opslag en vullen ze de opslag in. Als de opslag een bepaalde drempelwaarde overschrijdt en de logische replicatiesite niet in gebruik is (vanwege een niet-beschikbare abonnee), wordt deze ongebruikte logische replicatiesite door Azure Database for PostgreSQL automatisch verwijderd. Deze actie brengt samengevoegde WAL-bestanden vrij en voorkomt dat uw server niet meer beschikbaar is omdat de opslag is gevuld.
  • Het maken van tablespaces wordt niet ondersteund. Als u een database maakt, geeft u geen tabelruimtenaam op. Flexibele Azure Database for PostgreSQL-server maakt gebruik van de standaardserver die wordt overgenomen van de sjabloondatabase. Het is onveilig om een tabelruimte, zoals de tijdelijke, te bieden, omdat we er niet zeker van kunnen zijn dat dergelijke objecten persistent blijven na gebeurtenissen zoals het opnieuw opstarten van de server en hoge beschikbaarheid (HA) failovers.

Netwerken

  • Het binnen- en uitschakelen van een virtueel netwerk wordt momenteel niet ondersteund.
  • Het combineren van openbare toegang met implementatie in een virtueel netwerk wordt momenteel niet ondersteund.
  • Firewallregels worden niet ondersteund in virtuele netwerken. U kunt in plaats daarvan netwerkbeveiligingsgroepen gebruiken.
  • Databaseservers voor openbare toegang kunnen verbinding maken met het openbare internet; bijvoorbeeld via postgres_fdw. U kunt deze toegang niet beperken. Servers in virtuele netwerken kunnen beperkte uitgaande toegang hebben via netwerkbeveiligingsgroepen.

Hoge beschikbaarheid

Beschikbaarheidszones

  • Het handmatig verplaatsen van servers naar een andere beschikbaarheidszone wordt momenteel niet ondersteund. Als u echter de voorkeurs-beschikbaarheidszone als stand-byzone gebruikt, kunt u hoge beschikbaarheid inschakelen. Nadat u de stand-byzone hebt gemaakt, kunt u er een failover naartoe uitvoeren en vervolgens hoge beschikbaarheid uitschakelen.

Postgres-engine, extensies en PgBouncer

  • Postgres 10 en oudere versies worden niet ondersteund, omdat de opensource-community ze buiten gebruik heeft gesteld. Als u een van deze versies moet gebruiken, moet u de optie voor één server van Azure Database for PostgreSQL gebruiken, die ondersteuning biedt voor de oudere primaire versies 9.5, 9.6 en 10.
  • Flexibele Azure Database for PostgreSQL-server ondersteunt alle contrib extensies en meer. Zie PostgreSQL-extensies voor meer informatie.
  • De ingebouwde PgBouncer-verbindingspooler is momenteel niet beschikbaar voor Burstable-servers.

Stop-/startbewerkingen

  • Nadat u het exemplaar van de flexibele Azure Database for PostgreSQL-server hebt gestopt, wordt deze na 7 dagen automatisch gestart.

Gepland onderhoud

  • U kunt het aangepaste onderhoudsvenster wijzigen in elke dag/tijd van de week. Wijzigingen die u aanbrengt nadat u de onderhoudsmelding hebt ontvangen, hebben echter geen invloed op het volgende onderhoud. Wijzigingen worden alleen van kracht met het volgende maandelijkse geplande onderhoud.

Serverback-ups

  • Het systeem beheert back-ups. Er is momenteel geen manier om handmatig back-ups uit te voeren. U wordt aangeraden in plaats daarvan te gebruiken pg_dump .

  • De eerste momentopname is een volledige back-up en opeenvolgende momentopnamen zijn differentiële back-ups. De differentiële back-ups maken alleen een back-up van de gewijzigde gegevens sinds de laatste momentopnameback-up.

    Als de grootte van uw database bijvoorbeeld 40 GB is en uw ingerichte opslag 64 GB is, is de eerste back-up van de momentopname 40 GB. Als u nu 4 GB aan gegevens wijzigt, is de volgende back-upgrootte van de differentiële momentopname slechts 4 GB. De transactielogboeken (write-ahead-logboeken) staan los van de volledige en differentiële back-ups en worden continu gearchiveerd.

Serverherstel

  • Wanneer u de functie herstel naar een bepaald tijdstip (PITR) gebruikt, wordt de nieuwe server gemaakt met dezelfde reken- en opslagconfiguraties als de server waarop deze is gebaseerd.
  • Databaseservers in virtuele netwerken worden hersteld in dezelfde virtuele netwerken wanneer u herstelt vanuit een back-up.
  • De nieuwe server die tijdens een herstelbewerking is gemaakt, beschikt niet over de firewallregels die aanwezig zijn op de oorspronkelijke server. U moet voor de nieuwe server afzonderlijk firewallregels maken.
  • Herstellen naar een ander abonnement wordt niet ondersteund. Als tijdelijke oplossing kunt u de server binnen hetzelfde abonnement herstellen en vervolgens de herstelde server migreren naar een ander abonnement.

Beveiliging

  • MD5-hashing is uitgeschakeld vanuit Postgres 14 en latere versies en systeemeigen Postgres-wachtwoorden worden alleen gehasht met de SCRAM-SHA-256-methode.

Gerelateerde inhoud