Beschränkungen in Azure Database for PostgreSQL – Flexible Server

  • Artikel

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

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

Produktname V-Kerne Arbeitsspeichergröße Maximale Anzahl der Verbindungen Maximale Anzahl von 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 1.718 1.703
B8ms 8 32GiB 3\.437 3.422
B12ms 12 48 GiB 5,000 4.985
B16ms 16 64GiB 5,000 4.985
B20ms 20 80 GiB 5,000 4.985
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 1.718 1.703
D8s_v3 / D8ds_V4 / D8ds_v5 / D8ads_v5 8 32GiB 3\.437 3.422
D16s_v3 / D16ds_v4 / D16ds_v5 / D16ads_v5 16 64GiB 5,000 4.985
D32s_v3 / D32ds_v4 / D32ds_v5 / D32ads_v5 32 128 GB 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
Arbeitsspeicheroptimiert
E2s_v3 / E2ds_v4 / E2ds_v5 / E2ads_v5 2 16 GiB 1.718 1.703
E4s_v3 / E4ds_v4 / E4ds_v5 / E4ads_v5 4 32GiB 3\.437 3.422
E8s_v3 / E8ds_v4 / E8ds_v5 / E8ads_v5 8 64GiB 5,000 4.985
E16s_v3 / E16ds_v4 / E16ds_v5 / E16ads_v5 16 128 GB 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

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. 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).

Der Standardwert für den Serverparameter max_connections wird berechnet, wenn Sie die Instanz von Azure Database for PostgreSQL – Flexible Server basierend auf dem Produktnamen bereitstellen, den Sie für die Berechnung auswählen. Alle nachfolgenden Änderungen der Produktauswahl an der Berechnung, die den flexiblen Server unterstützt, haben keine Auswirkungen auf den Standardwert für den Serverparameter max_connections dieser Instanz. 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 – 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 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.

Achtung

Obwohl es möglich ist, den Wert von max_connections über die Standardeinstellung hinaus zu erhöhen, raten wir davon ab.

Bei Instanzen können Schwierigkeiten auftreten, wenn die Workload erweitert wird und mehr Arbeitsspeicher erfordert. 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 weitere Verbindungen benötigen, empfehlen wir Ihnen stattdessen die Verwendung von PgBouncer, der integrierten Azure-Lösung für die Verwaltung von Verbindungspools. Verwenden Sie es im Transaktionsmodus. Zu Beginn wird empfohlen, dass Sie konservative Werte 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.

Wenn Sie Azure Database for PostgreSQL – Flexible Server für eine 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.

Achten Sie darauf, 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. Im Artikel Anzahl der Datenbankverbindungen im PostgreSQL-Wiki wird dieses Thema ausführlicher erläutert. Weitere Informationen finden Sie unter Identifizieren und Behandeln der Verbindungsleistung in Azure Database for PostgreSQL – Flexible Server.

Funktionale Beschränkungen

In den folgenden Abschnitten werden Überlegungen zu dem aufgeführt, was in Azure Database for PostgreSQL – Flexible Server nicht unterstützt wird.

Skalierungsvorgänge

  • Zu diesem Zeitpunkt ist zum Hochskalieren des Serverspeichers ein Neustart des Servers erforderlich.
  • Sie können den Serverspeicher nur in 2x Schritten skalieren. Ausführliche Informationen finden Sie unter Compute and Storage.

Storage

  • 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 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 (Write-Ahead Logging) im primären und füllen den Speicher aus. Wenn der 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 gesammelte WAL-Dateien frei und verhindert, dass Ihr Server nicht verfügbar wird, da der Speicher voll ist.
  • Die Erstellung von Tabellenbereichen wird nicht unterstützt. Wenn Sie 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 Ereignissen wie Serverneustarts, Hochverfügbarkeitsfailovern (HA) usw. gespeichert bleiben.

Netzwerk

  • Das Ein- und Auslagern eines virtuellen Netzwerks wird derzeit nicht unterstützt.
  • Das Kombinieren des öffentlichen Zugriffs mit der Bereitstellung in einem virtuellen Netzwerk wird derzeit nicht unterstützt.
  • Firewallregeln werden in virtuellen Netzwerken nicht unterstützt. 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

Verfügbarkeitszonen

  • Manuelles 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

  • Postgres 10 und ältere Versionen werden nicht unterstützt, da die Open-Source-Community sie eingestellt hat. Wenn Sie eine dieser Versionen verwenden müssen, müssen Sie die Option Azure Database for PostgreSQL Single Server verwenden, welche 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 im Artikel zu PostgreSQL-Erweiterungen.
  • Der integrierte Verbindungspooler PgBouncer ist derzeit für Server im Tarif „Burstfähig“ nicht verfügbar.

Stopp-/Startvorgänge

  • Nachdem 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.

Serversicherungen

  • Das System verwaltet Sicherungen. Es gibt derzeit keine Möglichkeit, 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 sie werden fortlaufend archiviert.

Serverwiederherstellung

  • Bei Verwenden des Features „Zeitpunktwiederherstellung“ (point-in-time restore, PITR) wird der neue Server mit der dem zugrunde liegende Server entsprechenden Compute- und Speicherkonfiguration erstellt.
  • Datenbankserver in virtuellen Netzwerken werden in denselben virtuellen Netzwerken wiederhergestellt, wenn 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. Sie müssen Firewallregeln separat für den neuen Server erstellen.
  • Die Wiederherstellung in einem anderen Abonnement wird nicht unterstützt. Als Alternative können Sie den Server innerhalb desselben Abonnements wiederherstellen und dann den wiederhergestellten Server zu einem anderen Abonnement migrieren.

Nächste Schritte