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
oderstorage 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
- Weitere Informationen finden Sie in der Dokumentation zu HA-Einschränkungen.
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
- Grundlegendes zu verfügbaren Optionen für Compute- und Speicheroptionen
- Hier erfahren Sie mehr über Unterstützte Versionen der PostgreSQL-Datenbank.
- Weitere Informationen finden Sie in der Anleitung zum Sichern und Wiederherstellen eines Servers in Azure Database for PostgreSQL Flexible Server mithilfe des Azure-Portals.