Skalierung von Ressourcen in Azure Database for PostgreSQL – flexibler Server
GILT FÜR: 
Azure Database for PostgreSQL – Flexibler Server
Azure Database for PostgreSQL – flexible Server unterstützt sowohl vertikale als auch horizontale Skalierungsoptionen.
Vertikale Skalierung: Sie können vertikal skalieren, indem Sie der flexiblen Serverinstanz von Azure Database for PostgreSQL weitere Ressourcen hinzufügen, z. B. die CPU-Anzahl und die Arbeitsspeichergröße erhöhen. Der Netzwerkdurchsatz Ihrer Instanz hängt von den Werten ab, die Sie für CPU und Arbeitsspeicher auswählen.
Nachdem eine flexible Serverinstanz von Azure Database for PostgreSQL erstellt wurde, können Sie Folgendes unabhängig voneinander ändern:
- CPU (virtuelle Kerne)
- Speichermenge
- Aufbewahrungszeitraum von Sicherungen
Die Anzahl der virtuellen Kerne kann nach oben oder unten skaliert werden, aber die Speichergröße kann nur erhöht werden. Sie können auch den Aufbewahrungszeitraum für Sicherungen auf einen Wert zwischen 7 und 35 Tagen nach oben oder unten skalieren. Die Ressourcen können mithilfe mehrerer Tools skaliert werden, z. B. mit dem Azure-Portal oder der Azure CLI.
Hinweis
Nachdem Sie die Speichergröße erhöht haben, können Sie nicht mehr zu einer kleineren Speichergröße zurückkehren.
Horizontale Skalierung: Sie können horizontal skalieren, indem Sie Lesereplikate 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.
Wenn Sie die Anzahl der virtuellen Kerne oder die Computeebene ändern, wird die Instanz neu gestartet, damit der neue Servertyp wirksam wird. 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 Skalierung der Datenverarbeitung auftreten kann, empfehlen wir die Implementierung eines Wiederholungsmusters für Transaktionen.
Für die Skalierung des Speichers ist in den meisten Fällen kein Neustart des Servers erforderlich. Weitere Einzelheiten finden Sie unter Speicheroptionen in Azure Database for PostgreSQL – Flexibler Server. Auch die Änderung des Aufbewahrungszeitraums von Sicherungskopien ist ein Online-Vorgang. Um die Neustartzeit zu verkürzen, empfehlen wir Ihnen, die Skalierung außerhalb der Hauptgeschäftszeiten durchzuführen. 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 virtuellen Kernen 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 neuen Skalierungsfeature mit nahezu null 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 flexible Serverinstanz von Azure Database for PostgreSQL Skalierungsszenarien aktualisieren, erstellen wir eine neue Kopie Ihres Servers (VM) mit der aktualisierten Konfiguration. Wir synchronisieren sie mit Ihrer aktuellen Instanz, und wechseln nach einer Unterbrechung von 30 Sekunden zur neuen Kopie. Anschließend wird der alte Server außer Betrieb genommen. Dieser Vorgang ist für Sie kostenlos.
Dieser Prozess ermöglicht nahtlose Updates, wobei Downtime minimiert und Kosteneffizienz sichergestellt werden. Dieser Skalierungsprozess wird durch Änderungen an den Speicher- und Computeebenen ausgelöst. Für die Nutzung dieser Funktion ist keine Kundenaktion erforderlich.
Bei Servern mit konfigurierten Lesereplikaten müssen Skalierungsvorgänge eine bestimmte Sequenz befolgen, um die Datenkonsistenz sicherzustellen und Ausfallzeiten zu minimieren. Ausführliche Informationen zu dieser Sequenz finden Sie unter Skalieren mit Lesereplikaten.
Hinweis
Die Skalierung mit nahezu null Downtime ist der Standardvorgang. Wenn die folgenden Einschränkungen auftreten, schaltet das System jedoch auf eine reguläre Skalierung um, die mehr Downtime als die Skalierung mit nahezu null 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 Zeitraum wird nicht direkt vom Skalierungsprozess gesteuert. 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 null Downtime funktioniert, müssen Sie alle ein- und ausgehenden Verbindungen zwischen den IP-Adressen im delegierten Teilnetz aktivieren, wenn Sie das integrierte virtuelle Netzwerk verwenden. Wenn diese Verbindungen nicht aktiviert sind, funktioniert der Skalierungsprozess mit nahezu null Downtime nicht, und die Skalierung erfolgt über den Standardskalierungsworkflow.
- Die Skalierung mit nahezu null Downtime funktioniert nicht, wenn regionale Kapazitätsbeschränkungen oder Kontingentbeschränkungen für Kundenabonnements vorhanden sind.
- Die Skalierung von nahezu null Downtime funktioniert bei einem Replikationsserver nicht, da sie nur auf dem Primärserver unterstützt wird. Replikatserver durchlaufen automatisch den regulären Skalierungsprozess.
- Die Skalierung mit nahezu null Downtime funktioniert nicht, wenn ein VNet-Server mit einem delegiertem 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 HA-fähigen Server 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 Erweiterung in einem flexiblen Server.
- Downtime-Skalierung von fast null funktioniert nicht mit nicht protokollierten Tabellen. Kunden, die für bestimmte Daten nicht protokollierte Tabellen verwenden, verlieren nach der Downtime-Skalierung von fast null alle Daten in diesen Tabellen.