Skalierung von Ressourcen in Azure Database for PostgreSQL – flexibler Server

Ein Azure Database for PostgreSQL flexible Server unterstützt sowohl vertikale als auch horizontale Skalierungsoptionen.

Vertikale Skalierung

Skalieren Sie Den Server vertikal, indem Sie ihrem Azure Database for PostgreSQL flexiblen Server weitere Ressourcen hinzufügen. Sie können die Anzahl der zugewiesenen CPUs und des Arbeitsspeichers vergrößern oder verkleinern.

Der Netzwerkdurchsatz ihres Servers hängt von den Werten ab, die Sie für CPU und Arbeitsspeicher auswählen.

Nachdem Sie einen Azure Database for PostgreSQL flexiblen Server erstellt haben, können Sie unabhängig skalieren:

• Computeebene und -SKU
• Speicherebene und -größe
• Aufbewahrungszeitraum von Sicherungen

Skalieren Sie die Computeebene zwischen Burstable, General Purpose und Memory Optimized, um die Anforderungen Ihrer Workload anzupassen. Wählen Sie in jeder dieser Ebenen eine breite Auswahl an vorkonfigurierten Hardware unterschiedlicher Generationen mit unterschiedlicher Anzahl von CPUs und Mengen installiertem Arbeitsspeicher aus. Wählen Sie die Option aus, die Ihre Ressourcenanforderungen unterstützt, während die Betriebskosten reduziert und an Ihre Anforderungen angepasst werden.

Skalieren Sie die Anzahl der vCores und installierten Arbeitsspeicher nach oben oder unten. Sie können auch die Speicherebene nach oben oder unten konfigurieren, um den Durchsatz und die IOPS-Anforderungen zu erfüllen, die Ihre Workload erfordert. Sie können die Speichergröße nur erhöhen. Sie können entsprechend Ihren Anforderungen den Aufbewahrungszeitraum für die Sicherungen zwischen 7 und 35 Tagen erhöhen oder verringern.

Skalieren Sie diese Ressourcen mithilfe mehrerer Schnittstellen. Sie können z. B. das Azure Portal oder Azure CLI verwenden.

Horizontale Skalierung

Mit den elastischen Clustern für Azure Database for PostgreSQL können Sie Ihre Datenbank horizontal skalieren, um Datenworkloads zu unterstützen, die über die Leistungsfähigkeit eines einzelnen Datenbankservers hinausgehen. Elastische Cluster bieten zudem die Möglichkeit, parallele Operationen auf allen Knoten eines Clusters gleichzeitig auszuführen, wodurch der Durchsatz erheblich steigt und eine extrem niedrige Latenz ermöglicht wird. Elastische Cluster bieten zwei Tabellenshardingmodelle: zeilenbasiertes Sharding und schemabasiertes Sharding.

Lesereplikat wird skaliert

Sie können den Server horizontal skalieren, indem Sie Lesereplikate erstellen. Mit Lesereplikaten können Sie Ihre Lesearbeitslasten auf separate Azure Database for PostgreSQL Flexible Server skalieren. Sie wirken sich nicht auf die Leistung und Verfügbarkeit des primären Servers aus.

In einem horizontal skalierten Setup können Sie auch den primären Server und die Lesereplikate vertikal skalieren.

Wenn Sie die Anzahl der vCores oder die Computeebene ändern, wird der Server neu gestartet, sodass die zugewiesene neue Hardware mit der Ausführung der Serverarbeitsauslastung beginnt. Währenddessen wechselt das System zum neuen Servertyp. Sie können keine neuen Verbindungen herstellen, und alle nicht abgeschlossenen Transaktionen werden zurückgesetzt.

Die insgesamt für den Neustart Ihres Servers benötigte Zeit hängt vom Absturzwiederherstellungsprozess und der Datenbankaktivität zum Zeitpunkt des Neustarts ab. Der Neustart dauert in der Regel höchstens eine Minute, kann jedoch mehrere Minuten in Anspruch nehmen. Die Dauer hängt von der Transaktionsaktivität ab, die zum Zeitpunkt der Einleitung des Neustarts stattfand.

Wenn Ihre Anwendung empfindlich auf den Verlust von In-Flight-Transaktionen reagiert, der bei der Compute-Skalierung auftreten kann, implementieren Sie ein Wiederholungsmusters für Transaktionen.

Die Skalierung des Speichers erfordert in den meisten Fällen keinen Serverneustart. Weitere Informationen finden Sie unter Speicheroptionen in Der Azure-Datenbank für PostgreSQL.

Die Änderung des Aufbewahrungszeitraums von Sicherungskopien ist ein Onlinevorgang.

Um die Neustartzeit zu verbessern, führen Sie Skalierungsvorgänge während der Nebenzeiten aus. Dieser Ansatz verringert die Zeit, die für den Neustart des Datenbankservers benötigt wird.

Skalierung mit nahezu null Ausfallzeiten

Skalierung mit nahezu null Downtime ist ein Feature zur Minimierung von Downtime, wenn Speicher- und Computeebenen geändert werden. Wenn Sie die Anzahl von vCores ändern oder die Computeebene ändern, wird der Server neu gestartet, um die neue Konfiguration anzuwenden. Während dieses Übergangs zum neuen Server können Sie keine neuen Verbindungen herstellen.

In der Regel dauert dieser Vorgang von 2 bis 10 Minuten mit normaler Skalierung. Wenn Sie die Skalierungsfunktion für nahezu null Ausfallzeiten verwenden, verringern Sie diese Dauer auf weniger als 30 Sekunden. Durch diese Reduzierung der Downtime während der Skalierung von Ressourcen wird die Gesamtverfügbarkeit Ihrer Datenbankinstanz verbessert.

Funktionsweise

Wenn Sie Ihren Azure Database for PostgreSQL flexiblen Server in Skalierungsszenarien aktualisieren, erstellt der Dienst einen neuen virtuellen Computer für Ihren Server mit der aktualisierten Konfiguration. Anschließend wird sie mit dem virtuellen Computer synchronisiert, auf dem der Server derzeit ausgeführt wird, und wechselt dann mit einer kurzen Unterbrechung auf den neuen virtuellen Computer. Ein Hintergrundprozess beseitigt den alten virtuellen Computer.

Dieser Prozess ermöglicht nahtlose Updates mit minimalen Ausfallzeiten und wird automatisch ausgelöst, wenn Sie Speicher- oder Computeebenen ändern. Sie müssen keine Maßnahmen ergreifen, um diese Funktion zu verwenden. Diese Funktion wird sowohl für HA- als auch für Nicht-HA-Server von Azure Database for PostgreSQL – Flexible Server unterstützt.

Bei horizontal skalierten Konfigurationen, die aus einem Primärserver und einem oder mehreren Lesereplikaten bestehen, müssen die Skalierungsvorgänge in einer bestimmten Reihenfolge erfolgen, um die Datenkonsistenz zu gewährleisten und Downtime zu minimieren. Ausführliche Informationen zu dieser Sequenz finden Sie unter Skalieren mit Lesereplikaten.

Genaue Erwartungen bezüglich der Downtime

• Downtimedauer: In den meisten Fällen beträgt die Downtime zwischen 10 und 30 Sekunden.
• Andere Überlegungen: Nach einem Skalierungsereignis tritt eine inhärente DNS Time-To-Live-Periode (TTL) von etwa 30 Sekunden auf. Dieser Skalierungsprozess steuert diesen Zeitraum nicht direkt. Er ist ein Standardbestandteil des DNS-Verhaltens. Aus der Anwendungsperspektive kann die gesamte Downtime während der Skalierung zwischen 40 und 60 Sekunden betragen.

Überlegungen und Einschränkungen

• Damit die Skalierung mit nahezu keiner Downtime funktioniert, müssen Sie alle ein- und ausgehenden Verbindungen zwischen den IP-Adressen im delegierten Subnetz zulassen, wenn Sie das integrierte VNet verwenden. Wenn Sie diese Verbindungen nicht zulassen, funktioniert der Skalierungsprozess bei nahezu null Ausfallzeiten nicht, und die Skalierung erfolgt über den Standardskalierungsworkflow.
• Die Skalierung mit nahezu keiner Downtime funktioniert nicht, wenn regionale Kapazitätsbeschränkungen oder Kontingentbeschränkungen für Ihr Abonnement gelten.
• Die Skalierung mit nahezu keiner Downtime funktioniert auf einem Replikationsserver nicht, da sie nur auf dem Primärserver unterstützt wird. Bei Replikatservern durchläuft der Skalierungsvorgang automatisch den regulären Prozess.
• Die Skalierung mit nahezu keiner Downtime funktioniert nicht, wenn ein in ein virtuelles Netzwerk eingebundener Server im delegierten Subnetz nicht über ausreichend verwendbare IP-Adressen verfügt. Wenn Sie einen eigenständigen Server haben, ist eine zusätzliche IP-Adresse erforderlich. Für einen Server mit aktivierter Hochverfügbarkeit sind zwei zusätzliche IP-Adressen erforderlich.
• Logische Replikationsslots bleiben während eines Failoverereignisses mit nahezu null Downtime nicht erhalten. Um logische Replikationsslots beizubehalten und die Datenkonsistenz nach einem Failover zu gewährleisten, verwenden Sie die Erweiterung pg_failover_slot. Weitere Informationen finden Sie unter Aktivieren der pg_failover_slots-Erweiterung in einer Instanz von Flexibler Server.
• Downtime-Skalierung von fast null funktioniert nicht mit nicht protokollierten Tabellen. Wenn Sie unprotokollierte Tabellen für einen Ihrer Datensätze verwenden, gehen alle Daten in diesen Tabellen nach der nahezu ausfallfreien Skalierung verloren.
• Near-Zero funktioniert nicht, wenn Sie die Berechnung Ihres Servers von oder auf eine Berechnungsgröße von 1 oder 2 vCores der Burstable-Ebene skalieren.

Verwandte Inhalte

• Verwalten der Azure-Datenbank für PostgreSQL