Limieten in Azure Database for PostgreSQL

In de volgende secties worden capaciteits- en functionele limieten beschreven voor exemplaren van flexibele Azure Database for PostgreSQL-servers. 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. Een exemplaar van een flexibele Azure Database for PostgreSQL-server reserveert 15 verbindingen voor fysieke replicatie en monitoring van het flexibele Azure Database for PostgreSQL-serverexemplaar. Daarom vermindert de tabel de waarde voor maximale gebruikersverbindingen met 15 van het totale maximum aantal verbindingen.

De gereserveerde verbindingsslots, 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_connections + superuser_reserved_connections).

Het systeem berekent de standaardwaarde voor de max_connections serverparameter wanneer u het exemplaar van de flexibele Server van Azure Database for PostgreSQL inricht op basis van de productnaam die u voor de berekening selecteert. Eventuele volgende wijzigingen van productselectie in de berekening die ondersteuning bieden voor het exemplaar, 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. De configuratie van uw server bepaalt dit getal en u kunt dit niet wijzigen.

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.

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

FATAL: sorry, too many clients already.

Wanneer u een exemplaar van een flexibele Azure Database for PostgreSQL-server gebruikt voor een drukke database met een groot aantal gelijktijdige verbindingen, is er mogelijk een aanzienlijke belasting voor 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.

Elke verbinding in een flexibele Azure Database for PostgreSQL-serverinstantie, ongeacht of deze inactief of actief is, verbruikt een aanzienlijke hoeveelheid resources van uw database. 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 artikel uitgebreider besproken. Zie Verbindingsprestaties identificeren en oplossen in Azure Postgres voor meer informatie.

Functionele beperkingen

De volgende secties bevatten overwegingen voor wat wel en niet wordt ondersteund voor uw flexibele Server-exemplaren van Azure Database for PostgreSQL.

Schaalbewerkingen

• Op dit moment moet de serveropslag opnieuw worden opgestart.
• Serveropslag kan alleen in stappen van 2x worden geschaald. Zie Storage voor meer informatie.
• Momenteel wordt geen ondersteuning geboden voor het verkleinen van de opslaggrootte van de server. De enige manier om deze bewerking uit te voeren, is door deze te dumpen en te herstellen naar een nieuw exemplaar van een flexibele Azure Database for PostgreSQL-server.

Opslag

• 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), schakelt het systeem de server automatisch over naar de modus Alleen-lezen om fouten te voorkomen die zijn gekoppeld aan situaties waarin de schijf volledig is. 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 wordt gebruikt (vanwege een niet-beschikbare abonnee), wordt die ongebruikte logische replicatiesite automatisch verwijderd door een flexibele Server-instantie van Azure Database for PostgreSQL. Met deze actie worden samengevoegde WAL-bestanden uitgebracht en wordt voorkomen 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. Een exemplaar van een flexibele Azure Database for PostgreSQL-server maakt gebruik van de standaardtabelruimte die door de sjabloondatabase wordt overgenomen. 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

• We bieden momenteel geen ondersteuning voor het binnen- en uitgaan van een virtueel netwerk.
• Momenteel bieden we geen ondersteuning voor het combineren van openbare toegang met implementatie in een virtueel netwerk.
• Virtuele netwerken bieden geen ondersteuning voor firewallregels. 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

• Zie beperkingen voor hoge beschikbaarheid.

Beschikbaarheidszones

• We bieden momenteel geen ondersteuning voor het handmatig verplaatsen van servers naar een andere beschikbaarheidszone. 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

• Een exemplaar van een flexibele Azure Database for PostgreSQL-server ondersteunt alle functies van de PostgreSQL-engine, waaronder partitionering, logische replicatie en wrappers voor refererende gegevens.
• Een exemplaar van een flexibele Azure Database for PostgreSQL-server ondersteunt alle contrib extensies en meer. Zie PostgreSQL-extensies voor meer informatie.
• Burstable-servers hebben momenteel geen toegang tot de ingebouwde PgBouncer-verbindingspooler.

Stop-/startbewerkingen

• Nadat u het exemplaar van de flexibele Azure Database for PostgreSQL-server hebt gestopt, wordt deze na zeven 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. U kunt momenteel geen back-ups handmatig uitvoeren. 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, maakt het systeem de nieuwe server met dezelfde reken- en opslagconfiguraties als de server waarop deze is gebaseerd.
• Het systeem herstelt databaseservers in virtuele netwerken 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.
• Herstel 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

• Postgres 14 en latere versies schakelen MD5-hashing uit en hashen systeemwachtwoorden alleen nog met behulp van de SCRAM-SHA-256-methode.

Gerelateerde inhoud

• Rekenopties in Azure Database for PostgreSQL.
• Opslagopties in Azure Database voor PostgreSQL.
• Ondersteunde versies van PostgreSQL in Azure Database for PostgreSQL.