Grenzwerte in Der Azure-Datenbank für PostgreSQL

In den folgenden Abschnitten werden kapazitäts- und funktionale Grenzwerte für azure Database für flexible Serverinstanzen von PostgreSQL beschrieben. Informationen zu den Tarifen für Ressourcen (Compute, Arbeitsspeicher, Speicher) finden Sie in den Artikeln Compute und Speicher.

Maximale Anzahl der Verbindungen

In der folgenden Tabelle finden Sie den Standardwert für die maximale Anzahl von Verbindungen für jede Tarif- und vCore-Konfiguration. Beachten Sie, dass Azure Database for PostgreSQL Flexible Serverinstanz 15 Verbindungen für die physische Replikation und Überwachung der Instanz von Azure Database for PostgreSQL Flexible Server reserviert. Folglich reduziert die Tabelle den Wert für maximale Benutzerverbindungen um 15 von der Gesamtanzahl der maximalen Verbindungen.

Die reservierten Verbindungsplätze, derzeit bei 15, können sich ändern. Deshalb wird empfohlen, die Gesamtzahl der reservierten Verbindungen auf dem Server regelmäßig zu überprüfen. Sie berechnen diese Zahl, indem Sie die Werte der Serverparameter reserved_connections und superuser_reserved_connections addieren. Die maximale Anzahl verfügbarer Benutzerverbindungen lautet max_connections - (reserved_connections + superuser_reserved_connections).

Das System berechnet den Standardwert für den max_connections-Serverparameter, wenn Sie eine Instanz der flexiblen Azure-Datenbank für PostgreSQL bereitstellen. Dies erfolgt basierend auf dem Produktnamen, den Sie für die Berechnung auswählen. Alle nachfolgenden Änderungen der Produktauswahl an der Berechnung, die die Instanz unterstützt, wirkt sich nicht auf den Standardwert für den max_connections Serverparameter dieser Instanz aus. Es wird empfohlen, dass Sie bei jeder Änderung des Produkts, das einer Instanz zugewiesen ist, auch den Wert für den max_connections-Parameter entsprechend den Werten in der vorherigen Tabelle anpassen.

Ändern des max_connections-Werts

Wenn Sie Ihre Instanz von Azure Database for Postgres – Flexibler Server zum ersten Mal einrichten, bestimmt diese automatisch die höchste Anzahl von Verbindungen, die sie gleichzeitig verarbeiten kann. Die Konfiguration Ihres Servers bestimmt diese Nummer, und Sie können sie nicht ändern.

Sie können die max_connections-Einstellung jedoch verwenden, um anzupassen, wie viele Verbindungen zu einem bestimmten Zeitpunkt zulässig sind. Sie müssen nach dem Ändern dieser Einstellung den Server neu starten, damit der neue Grenzwert funktioniert.

Wenn Verbindungen den Grenzwert übersteigen, erhalten Sie möglicherweise den folgenden Fehler:

FATAL: sorry, too many clients already.

Wenn Sie einen flexiblen Azure-Datenbankserver für PostgreSQL für eine stark ausgelastete Datenbank mit einer großen Anzahl gleichzeitiger Verbindungen verwenden, kann es zu einer erheblichen Belastung der Ressourcen kommen. Diese Belastung kann zu einer hohen CPU-Auslastung führen, insbesondere wenn viele Verbindungen gleichzeitig hergestellt werden und Verbindungen eine kurze Dauer haben (weniger als 60 Sekunden). Diese Faktoren können sich negativ auf die Gesamtleistung der Datenbank auswirken, da sie den Zeitaufwand für die Verarbeitung von Verbindungen und Trennungen erhöhen.

Jede Verbindung in einer azure-Datenbank für flexible Serverinstanz von PostgreSQL, unabhängig davon, ob sie im Leerlauf oder aktiv ist, verbraucht eine erhebliche Menge an Ressourcen aus Ihrer Datenbank. Dieser Verbrauch kann zu Leistungsproblemen führen, die über eine hohe CPU-Auslastung hinausgehen, z. B. Datenträger- und Sperrkonflikt. Der Artikel "Anzahl der Datenbankverbindungen " im PostgreSQL-Wiki erläutert diesen Artikel ausführlicher. Weitere Informationen finden Sie unter Identifizieren und Lösen der Verbindungsleistung in Azure Postgres.

Funktionale Beschränkungen

In den folgenden Abschnitten werden Überlegungen dazu aufgeführt, was für Ihre Azure-Datenbank für PostgreSQL-Flexible Serverinstanzen unterstützt wird und was nicht.

Skalierungsvorgänge

• Zu diesem Zeitpunkt ist zum Hochskalieren des Serverspeichers ein Neustart des Servers erforderlich.
• Der Serverspeicher kann nur in 2 x Schritten skaliert werden. Weitere Informationen finden Sie unter "Speicher ".
• Zurzeit wird das Verringern der Serverspeichergröße nicht unterstützt. Die einzige Möglichkeit, diesen Vorgang auszuführen, besteht darin, ihn in einer neuen Azure-Datenbank für flexible Serverinstanz von PostgreSQL zu sichern und wiederherzustellen .

Lagerung

• Nachdem Sie die Speichergröße konfiguriert haben, können Sie sie nicht reduzieren. Sie müssen einen neuen Server mit der gewünschten Speichergröße erstellen und einen manuellen Sicherungs- und Wiederherstellungsvorgang zum Migrieren Ihrer Datenbanken zum neuen Server durchführen.
• Wenn die Speicherauslastung 95% erreicht oder wenn die verfügbare Kapazität kleiner als 5 GiB ist (je nachdem, was mehr ist), wechselt das System den Server automatisch in den schreibgeschützten Modus , um Fehler im Zusammenhang mit Disk-Full-Situationen zu vermeiden. Wenn die Datenwachstumsrate in seltenen Fällen den Zeitaufwand für den Wechsel in den schreibgeschützten Modus übersteigt, verfügt der Server möglicherweise weiterhin nicht über genügend Speicher. Sie können die automatische Vergrößerung des Speichers aktivieren, um diese Probleme zu vermeiden und Ihren Speicher basierend auf Ihren Workloadanforderungen automatisch zu skalieren.
• Es wird empfohlen, Warnungsregeln für storage used oder storage percent festzulegen, wenn diese bestimmte Schwellenwerte überschreiten, damit Sie proaktiv Maßnahmen ergreifen können, z. B. eine Erhöhung der Speichergröße. Beispiel: Sie können eine Warnung festlegen, wenn der Speicherprozentsatz eine Nutzung von 80 % übersteigt.
• Wenn Sie die logische Replikation verwenden, müssen Sie den logischen Replikationsslot auf dem primären Server löschen, wenn der entsprechende Abonnent nicht mehr vorhanden ist. Andernfalls sammeln sich die WAL-Dateien (Write-Ahead Logging) im primären und füllen den Speicher aus. Wenn der Speicher einen bestimmten Schwellenwert überschreitet und der logische Replikationsslot nicht verwendet wird (aufgrund eines nicht verfügbaren Abonnenten), löscht eine Azure Database for PostgreSQL Flexible Server-Instanz automatisch diesen nicht verwendeten logischen Replikationsslot. Diese Aktion gibt gesammelte WAL-Dateien frei und verhindert, dass Ihr Server nicht verfügbar wird, da der Speicher gefüllt ist.
• Die Erstellung von Tabellenbereichen wird nicht unterstützt. Wenn Sie eine Datenbank erstellen, geben Sie keinen Tabellenbereichsnamen an. Eine Flexible Serverinstanz von Azure Database für PostgreSQL verwendet den Standardtabellenbereich, den die Vorlagendatenbank erbt. Es ist nicht sicher, einen Tabellenbereich wie den temporären bereitzustellen, da wir nicht sicherstellen können, dass solche Objekte nach Ereignissen wie Serverneustarts, Hochverfügbarkeitsfailovern (HA) usw. gespeichert bleiben.

Netzwerk

• Wir unterstützen derzeit das Ein- und Abmelden eines virtuellen Netzwerks nicht.
• Zurzeit wird die Kombination des öffentlichen Zugriffs mit der Bereitstellung in einem virtuellen Netzwerk nicht unterstützt.
• Virtuelle Netzwerke unterstützen keine Firewallregeln. Sie können stattdessen Netzwerksicherheitsgruppen verwenden.
• Öffentliche Zugriffsdatenbankserver können eine Verbindung mit dem öffentlichen Internet herstellen. Beispielsweise: über postgres_fdw. Sie können diesen Zugriff nicht einschränken. Server in virtuellen Netzwerken können eingeschränkten ausgehenden Zugriff über Netzwerksicherheitsgruppen haben.

Hochverfügbarkeit (HA)

• Siehe Hochverfügbarkeit – Einschränkungen.

Verfügbarkeitszonen

• Das manuelle Verschieben von Servern in eine andere Verfügbarkeitszone wird derzeit nicht unterstützt. Wenn Sie jedoch die bevorzugte Verfügbarkeitszone als Standbyzone verwenden, können Sie HA aktivieren. Nachdem Sie die Standbyzone hergestellt haben, können Sie zu dieser den Failover ausführen und dann HA deaktivieren.

Postgres-Engine, Erweiterungen und PgBouncer

• Eine Azure-Datenbank instanz für einen flexiblen PostgreSQL-Server unterstützt alle Funktionen der PostgreSQL-Datenbank-Engine, einschließlich Partitionierung, logischer Replikation und Fremddatenwrapper.
• Eine flexible Azure-Datenbank für PostgreSQL-Serverinstanz unterstützt alle contrib Erweiterungen und vieles mehr. Weitere Informationen finden Sie im Artikel zu PostgreSQL-Erweiterungen.
• Burstable-Server haben derzeit keinen Zugriff auf den integrierten PgBouncer-Verbindungspooler.

Stopp-/Startvorgänge

• Nachdem Sie die Azure-Datenbank für die flexible Serverinstanz von PostgreSQL beendet haben, wird sie automatisch nach sieben Tagen gestartet.

Geplante Wartung

• Sie können das benutzerdefinierte Wartungsfenster auf einen beliebigen Tag/Zeitpunkt der Woche ändern. Änderungen, die nach Erhalt der Wartungsbenachrichtigung vorgenommen wurden, haben jedoch keine Auswirkungen auf die nächste Wartung. Änderungen werden erst bei der nächsten monatlich geplanten Wartung wirksam.

Serversicherungen

• Das System verwaltet Sicherungen. Zurzeit können Sie Keine Sicherungen manuell ausführen. Stattdessen wird die Verwendung von pg_dump empfohlen.

• Die erste Momentaufnahme ist eine vollständige Sicherung, und aufeinanderfolgende Momentaufnahmen sind differenzielle Sicherungen. Die differenziellen Sicherungen sichern nur die geänderten Daten seit der letzten Momentaufnahmensicherung.

  Wenn die Größe Ihrer Datenbank beispielsweise 40 GB beträgt und der bereitgestellte Speicher 64 GB beträgt, beträgt die erste Momentaufnahmesicherung 40 GB. Wenn Sie nun 4 GB Daten ändern, beträgt die Größe der nächsten differenziellen Momentaufnahmensicherung nur 4 GB. Die Transaktionsprotokolle (Write-Ahead-Protokolle, WAL) sind von den vollständigen/differenziellen Sicherungen getrennt und sie werden fortlaufend archiviert.

Serverwiederherstellung

• Wenn Sie das Feature "Point-in-Time Restore" (PITR) verwenden, erstellt das System den neuen Server mit den gleichen Compute- und Speicherkonfigurationen wie der Server, auf dem er basiert.
• Das System stellt Datenbankserver aus virtuellen Netzwerken in dieselben virtuellen Netzwerke wieder her, wenn Sie eine Sicherungskopie wiederherstellen.
• Der neue Server, der während einer Wiederherstellung erstellt wird, weist nicht die Firewallregeln auf, die auf dem ursprünglichen Server vorhanden waren. Sie müssen Firewallregeln separat für den neuen Server erstellen.
• Wir unterstützen die Wiederherstellung in einem anderen Abonnement nicht. Als Alternative können Sie den Server innerhalb desselben Abonnements wiederherstellen und dann den wiederhergestellten Server zu einem anderen Abonnement migrieren.

Sicherheit

• Postgres 14 und höhere Versionen deaktivieren das MD5-Hashing, und das System hashiert die nativen Postgres-Kennwörter nur durch die SCRAM-SHA-256-Methode.

Verwandte Inhalte

• Berechnungsoptionen in Azure Database for PostgreSQL.
• Speicheroptionen in Azure-Datenbank für PostgreSQL.
• Unterstützte Versionen von PostgreSQL in Azure Database for PostgreSQL.