Skalieren von Ressourcen in Azure-Datenbank für PostgreSQL

Eine flexible Azure-Datenbank für PostgreSQL-Serverinstanz unterstützt sowohl vertikale als auch horizontale Skalierungsoptionen.

Vertikale Skalierung

Sie können Ihre Instanz vertikal skalieren, indem Sie Ihrer Azure-Datenbank für flexible Serverinstanz von PostgreSQL weitere Ressourcen hinzufügen. Sie können die Anzahl der zugewiesenen CPUs und des Arbeitsspeichers vergrößern oder verkleinern.

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

Nachdem Sie eine Azure-Datenbank für eine flexible Serverinstanz für PostgreSQL erstellt haben, können Sie unabhängig skalieren:

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

Sie können die Computeebene nach oben oder unten zwischen Burstable, General Purpose und Memory Optimized skalieren, um die Anforderungen Ihrer Workload anzupassen. In jeder dieser Ebenen können Sie aus einer breiten Auswahl vorkonfigurierten Hardware unterschiedlicher Generationen mit unterschiedlicher Anzahl von CPUs und Installiertem Arbeitsspeicher wählen. Sie können die Option auswählen, die Ihre Ressourcenanforderungen unterstützt, während Die Betriebskosten reduziert und an Ihre Anforderungen angepasst werden.

Sie können die Anzahl der vCores skalieren und den installierten Arbeitsspeicher nach oben oder unten skalieren. 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.

Sie können diese Ressourcen mithilfe mehrerer Schnittstellen skalieren. Sie können beispielsweise das Azure-Portal oder die Azure CLI verwenden.

Hinweis

Wenn Sie den Ihrer Instanz zugewiesenen Speicherplatz vergrößert haben, können Sie ihn nicht wieder verringern.

Horizontale Skalierung

Azure Database für PostgreSQL-Elastik-Cluster ermöglicht es Ihnen, Ihre Datenbank horizontal zu skalieren, um Datenarbeitslasten zu unterstützen, die über die Kapazitäten einer einzelnen Datenbankinstanz hinausgehen. Elastische Cluster ermöglichen es auch, parallele Vorgänge gleichzeitig über alle Knoten in einem Cluster auszuführen, wodurch der Durchsatz erheblich erhöht und ultra-niedrige Latenz ermöglicht wird. Elastische Cluster bieten zwei Tabellenshardingmodelle: zeilenbasiertes Sharding und schemabasiertes Sharding.

Lesereplikat wird skaliert

Ein weiterer Ansatz zum horizontalen Skalieren Ihrer Instanz besteht darin, Lesereplikate zu erstellen. Mit Lesereplikaten können Sie Ihre Leseworkloads auf separate flexible Serverinstanzen von Azure Database for PostgreSQL skalieren. Sie haben keinen Einfluss auf die Leistung und Verfügbarkeit der primären Instanz.

In einem horizontal skalierten Setup können Sie auch die primäre Instanz und die Lesereplikate vertikal skalieren.

Wenn Sie die Anzahl der vCores oder der Computeebene ändern, wird die Instanz neu gestartet, sodass die zugewiesene neue Hardware mit der Ausführung der Serverarbeitsauslastung beginnt. Währenddessen wechselt das System zum neuen Servertyp. Es können keine neuen Verbindungen hergestellt werden, und für alle nicht committeten Transaktionen wird ein Rollback ausgeführt.

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 keine neuen Verbindungen hergestellt werden.

In der Regel kann dieser Vorgang bei normaler Skalierung zwischen 2 und 10 Minuten dauern. Mit dem Skalierungsfeature mit nahezu keiner Downtime wird dies auf weniger als 30 Sekunden reduziert. Durch diese Reduzierung der Downtime während der Skalierung von Ressourcen wird die Gesamtverfügbarkeit Ihrer Datenbankinstanz verbessert.

Funktionsweise

Wenn Sie Ihre Azure Database for PostgreSQL – Flexibler Server-Instanz bei Skalierungsszenarien aktualisieren, erstellt der Dienst eine VM für Ihren Server mit der aktualisierten Konfiguration. Anschließend wird sie mit dem virtuellen Computer synchronisiert, der derzeit Ihre Instanz ausführt, und wechselt dann mit einer kurzen Unterbrechung auf den neuen virtuellen Computer. Anschließend beseitigt ein Hintergrundprozess die alte VM.

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 für Instanzen mit und ohne Hochverfügbarkeit von Azure Database for PostgreSQL – Flexibler 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.

Hinweis

Die Skalierung mit nahezu keiner Downtime ist der Standardbetriebstyp. Wenn die folgenden Einschränkungen auftreten, schaltet das System jedoch auf eine reguläre Skalierung um, die mehr Downtime als die Skalierung mit nahezu keiner Downtime mit sich bringt.

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 eine Instanz, bei der Hochverfügbarkeit aktiviert ist, 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