Beschränkungen in Azure Database for PostgreSQL – Flexible Server

GILT FÜR: Azure Database for PostgreSQL – Flexible Server

In den folgenden Abschnitten werden die Kapazitätsgrenzwerte und die funktionalen Grenzwerte in Azure Database for PostgreSQL Flexible Server beschrieben. Informationen zu den Tarifen für Ressourcen (Compute, Arbeitsspeicher, Speicher) finden Sie im Artikel Compute und Speicher.

Maximale Anzahl der Verbindungen

Unten 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 Server 15 Verbindungen für die physische Replikation und Überwachung der Instanz von Azure Database for PostgreSQL Flexible Server reserviert. Folglich wird der in der Tabelle aufgeführte max user connections-Wert um 15 aus der gesamten Anzahl von max connections reduziert.

SKU-Name V-Kerne Arbeitsspeichergröße Max. Anzahl von Verbindungen Max. Benutzerverbindungen
Burstfähig
B1ms 1 2 GiB 50 35
B2s 2 4 GiB 429 414
B2ms 2 8 GiB 859 844
B4ms 4 16 GiB 1718 1703
B8ms 8 32GiB 3437 3422
B12ms 12 48 GiB 5000 4985
B16ms 16 64GiB 5000 4985
B20ms 20 80 GiB 5000 4985
Allgemeiner Zweck
D2s_v3 / D2ds_v4 / D2ds_v5 / D2ads_v5 2 8 GiB 859 844
D4s_v3 / D4ds_v4 / D4ds_v5 / D4ads_v5 4 16 GiB 1718 1703
D8s_v3 / D8ds_V4 / D8ds_v5 / D8ads_v5 8 32GiB 3437 3422
D16s_v3 / D16ds_v4 / D16ds_v5 / D16ads_v5 16 64GiB 5000 4985
D32s_v3 / D32ds_v4 / D32ds_v5 / D32ads_v5 32 128 GB 5000 4985
D48s_v3 / D48ds_v4 / D48ds_v5 / D48ads_v5 48 192 GiB 5000 4985
D64s_v3 / D64ds_v4 / D64ds_v5 / D64ads_v5 64 256 GiB 5000 4985
D96ds_v5 / D96ads_v5 96 384 GiB 5000 4985
Arbeitsspeicheroptimiert
E2s_v3 / E2ds_v4 / E2ds_v5 / E2ads_v5 2 16 GiB 1718 1703
E4s_v3 / E4ds_v4 / E4ds_v5 / E4ads_v5 4 32GiB 3437 3422
E8s_v3 / E8ds_v4 / E8ds_v5 / E8ads_v5 8 64GiB 5000 4985
E16s_v3 / E16ds_v4 / E16ds_v5 / E16ads_v5 16 128 GB 5000 4985
E20ds_v4 / E20ds_v5 / E20ads_v5 20 160 GiB 5000 4985
E32s_v3 / E32ds_v4 / E32ds_v5 / E32ads_v5 32 256 GiB 5000 4985
E48s_v3 / E48ds_v4 / E48ds_v5 / E48ads_v5 48 384 GiB 5000 4985
E64s_v3 / E64ds_v4 / E64ds_v5 / E64ads_v5 64 432 GiB 5000 4985
E96ds_v5 / E96ads_v5 96 672 GiB 5000 4985

Hinweis

Die Anzahl der reservierten Verbindungssteckplätze, die derzeit bei 15 liegt, könnte sich ändern. Deshalb wird empfohlen, die Gesamtzahl der reservierten Verbindungen auf dem Server regelmäßig zu überprüfen. Diese wird berechnet, indem die Werte der Serverparameter reserved_connections und superuser_reserved_connections miteinander addiert werden. Die Anzahl der maximal verfügbaren Benutzerverbindungen ergibt sich aus: max_connections - (reserved_connections + superuser_reserved_connections).

Hinweis

Dieser Standardwert für den Serverparameter max_connections wird berechnet, wenn die Instanz von Azure Database for PostgreSQL Flexible Server basierend auf dem für die Berechnung ausgewählten SKU-Namen das erste Mal bereitgestellt wird. Alle nachfolgenden SKU-Änderungen an der Berechnung, die diesen flexiblen Server unterstützen, haben keine Auswirkungen auf den derzeit festgelegten Standardwert, der für den Serverparameter max_connections dieser Instanz ausgewählt wurde. Deshalb wird empfohlen, dass Sie bei jeder Änderung der SKU, die einer Instanz zugewiesen ist, den aktuell festgelegten Wert für den Parameter max_connections entsprechend den in der obigen Tabelle angegebenen Werten ebenfalls anpassen.

Ändern des max_connections-Werts

Wenn Sie Ihre Instanz von Azure Postgres Flexible Server zum ersten Mal einrichten, bestimmt diese automatisch die höchste Anzahl von Verbindungen, die sie gleichzeitig verarbeiten kann. Diese Anzahl basiert auf der Konfiguration Ihres Servers und kann nicht geändert werden.

Sie können jedoch jederzeit anpassen, wie viele Verbindungen zulässig sind. Ändern Sie hierzu die Einstellung für max_connections. Denken Sie daran, dass Sie nach dem Ändern dieser Einstellung den Server neu starten müssen, damit der neue Grenzwert funktioniert.

Achtung

Obwohl es möglich ist, den Wert von max_connections über die Standardeinstellung hinaus zu erhöhen, wird das nicht empfohlen. Der Grund für diese Empfehlung ist, dass Instanzen möglicherweise Schwierigkeiten haben, wenn die Workload erweitert wird und mehr Arbeitsspeicher benötigt. Mit zunehmender Anzahl von Verbindungen steigt auch die Arbeitsspeicherauslastung. Bei Instanzen mit begrenztem Arbeitsspeicher können Probleme auftreten, z. B. Abstürze oder hohe Latenz. Obwohl ein höherer Wert für max_connections zulässig wäre, wenn sich die meisten Verbindungen im Leerlauf befinden, kann das zu erheblichen Leistungsproblemen führen, sobald die Verbindungen aktiv werden. Wenn Sie mehr Verbindungen benötigen, empfehlen wir stattdessen die Verwendung von pgBouncer, der in Azure integrierten Lösung für die Verwaltung von Verbindungspools, im Transaktionsmodus. Zu Beginn wird empfohlen, konservative Werte zu verwenden, indem die virtuellen Kerne im Bereich von 2 bis 5 multipliziert werden. Überwachen Sie anschließend die Ressourcenauslastung und die Anwendungsleistung sorgfältig, um einen reibungslosen Betrieb sicherzustellen. Ausführliche Informationen zu pgBouncer finden Sie unter PgBouncer in Azure Database for PostgreSQL – Flexible Server.

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

FATAL: sorry, too many clients already.

Bei der Verwendung von Azure Database for PostgreSQL Flexible Server für eine ausgelastete Datenbank mit einer großen Anzahl gleichzeitiger Verbindungen 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. Es ist wichtig zu beachten, dass jede Verbindung in Azure Database for PostgreSQL Flexible Server unabhängig davon, ob sie sich im Leerlauf befindet oder aktiv ist, eine erhebliche Menge von Ressourcen aus Ihrer Datenbank verbraucht. Dieser Verbrauch kann zu Leistungsproblemen führen, die über eine hohe CPU-Auslastung hinausgehen, z. B. Datenträger- und Sperrkonflikt. Das Thema wird im Artikel PostgreSQL Wiki ausführlicher in Anzahl der Datenbankverbindungen behandelt. Weitere Informationen finden Sie unter Identifizieren und Behandeln der Verbindungsleistung in Azure Database for PostgreSQL Flexible Server.

Funktionale Beschränkungen

Skalierungsvorgänge

  • Zu diesem Zeitpunkt ist zum Hochskalieren des Serverspeichers ein Neustart des Servers erforderlich.
  • Serverspeicher kann nur in Verdopplungsschritten skaliert werden. Weitere Informationen finden Sie unter Compute und Speicher.
  • Die Verringerung der Größe des Serverspeichers wird zurzeit nicht unterstützt. Die einzige Möglichkeit besteht in der Sicherung und Wiederherstellung in einer neuen Instanz von Azure Database for PostgreSQL Flexible Server.

Storage

  • Nach der Konfiguration kann die Speichergröße nicht mehr verringert werden. Sie müssen einen neuen Server mit der gewünschten Speichergröße erstellen und einen manuellen Sicherungs- und Wiederherstellungsprozess zum Migrieren Ihrer Datenbanken zum neuen Server durchführen.
  • Wenn die Speichernutzung 95 % erreicht oder die verfügbare Kapazität weniger als 5 GiB beträgt, wird der Server automatisch in den schreibgeschützten Modus umgeschaltet, um Fehler im Zusammenhang mit vollen Datenträgern zu vermeiden, je nachdem, welcher Wert höher ist. 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 Replikations-Slot auf dem primären Server löschen, wenn der entsprechende Abonnent nicht mehr vorhanden ist. Andernfalls sammeln sich die WAL-Dateien im primären Server an und füllen dessen Speicher. Wenn der Schwellenwert für den Speicher einen bestimmten Schwellenwert übersteigt und der logische Replikationssteckplatz aufgrund eines nicht verfügbaren Abonnentens nicht verwendet wird, verwirft Azure Database for PostgreSQL Flexible Server diesen nicht verwendeten logischen Replikationssteckplatz automatisch. Diese Aktion gibt akkumulierte WAL-Dateien frei und verhindert, dass Ihr Server aufgrund der Speichersituation nicht mehr verfügbar ist.
  • Wir unterstützen die Erstellung von Tabellenbereichen nicht. Wenn Sie also eine Datenbank erstellen, geben Sie keinen Tabellenbereichsnamen an. Azure Database for PostgreSQL Flexible Server verwendet den Standardserver, der von der Vorlagendatenbank geerbt wird. Es ist nicht sicher, einen Tabellenbereich wie den temporären bereitzustellen, da wir nicht sicherstellen können, dass solche Objekte nach Serverneustarts, Hochverfügbarkeitsfailovern usw. gespeichert bleiben.

Netzwerk

  • Das Verschieben in und aus einem VNET wird derzeit nicht unterstützt.
  • Das Kombinieren des öffentlichen Zugriffs mit der Bereitstellung in einem VNET wird derzeit nicht unterstützt.
  • Firewallregeln werden im VNet nicht unterstützt. Stattdessen können Netzwerksicherheitsgruppen verwendet werden.
  • Datenbankserver mit öffentlichem Zugriff können beispielsweise über postgres_fdw eine Verbindung mit dem öffentlichen Internet herstellen, und dieser Zugriff kann nicht eingeschränkt werden. Für VNET-basierte Server kann der ausgehende Zugriff mithilfe von Netzwerksicherheitsgruppen eingeschränkt werden.

Hochverfügbarkeit

Verfügbarkeitszonen

  • Manuelles Verschieben von Servern in eine andere Verfügbarkeitszone wird derzeit nicht unterstützt. Wenn Sie jedoch die bevorzugte VZ als Standbyzone verwenden, können Sie die Hochverfügbarkeit aktivieren. Nach der Einrichtung können Sie ein Failover in den Stand-by-Modus ausführen und dann die Hochverfügbarkeit deaktivieren.

Postgres-Engine, Erweiterungen und PgBouncer

  • Postgres 10 und niedriger werden nicht unterstützt, da diese bereits von der Open-Source-Community eingestellt wurden. Wenn Sie eine dieser Versionen verwenden müssen, müssen Sie die Option Azure Database for PostgreSQL Single Server verwenden, die die älteren Hauptversionen 9.5, 9.6 und 10 unterstützt.
  • Azure Database for PostgreSQL Flexible Server unterstützt alle contrib-Erweiterungen und vieles mehr. Weitere Informationen finden Sie unter PostgreSQL-Erweiterungen.
  • Der integrierte Verbindungspooler PgBouncer ist derzeit für Server im Tarif „Burstfähig“ nicht verfügbar.

Vorgang „Anhalten/Starten“

  • Sobald Sie die Instanz von Azure Database for PostgreSQL Flexible Server beenden, wird sie nach sieben Tagen automatisch 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.

Sichern eines Servers

  • Sicherungen werden vom System verwaltet. Es gibt derzeit keine Möglichkeit, diese Sicherungen manuell auszufü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 ihre Datenbank beispielsweise 40 GB groß ist und Ihr bereitgestellter Speicherplatz 64 GB beträgt, beträgt die erste Momentaufnahmensicherung 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 werden fortlaufend archiviert.

Wiederherstellen eines Servers

  • Bei Verwenden des Features „Zeitpunktwiederherstellung“ wird der neue Server mit der dem zugrunde liegende Server entsprechenden Compute- und Speicherkonfiguration erstellt.
  • VNET-basierte Datenbankserver werden im selben VNET wiederhergestellt, wenn Sie sie aus einer Sicherung wiederherstellen.
  • Der neue Server, der während einer Wiederherstellung erstellt wird, weist nicht die Firewallregeln auf, die auf dem ursprünglichen Server vorhanden waren. Firewallregeln müssen für den neuen Server separat erstellt werden.
  • Die Wiederherstellung in einem anderen Abonnement wird nicht unterstützt. Als Problemumgehung können Sie jedoch den Server innerhalb desselben Abonnements wiederherstellen und dann den wiederhergestellten Server zu einem anderen Abonnement migrieren.

Nächste Schritte