Hohe Verfügbarkeit (Zuverlässigkeit) in Azure-Datenbank für PostgreSQL

In diesem Artikel wird die hohe Verfügbarkeit in der Azure-Datenbank für PostgreSQL beschrieben, einschließlich Verfügbarkeitszonen und regionsübergreifender Wiederherstellung und Geschäftskontinuität. Eine ausführlichere Übersicht über die Zuverlässigkeit in Azure finden Sie unter Azure-Zuverlässigkeit.

Azure Database for PostgreSQL unterstützt hohe Verfügbarkeit, indem physisch getrennte primäre und Standby-Replikate bereitgestellt werden, entweder innerhalb derselben Verfügbarkeitszone (Zonal) oder über Verfügbarkeitszonen (zonenredundant). Dieses Modell für hohe Verfügbarkeit ist so konzipiert, dass zugesicherte Daten bei Fehlern nie verloren gehen. Bei einem Setup mit Hochverfügbarkeit (High Availability, HA) werden Daten synchron sowohl auf dem Primärserver als auch auf den Standbyservern committet. Das Modell ist so konzipiert, dass die Datenbank nicht zu einem Single Point of Failure in Ihrer Softwarearchitektur wird. Weitere Informationen zur Hochverfügbarkeit und zur Unterstützung von Verfügbarkeitszonen finden Sie unter Unterstützung von Verfügbarkeitszonen.

Unterstützung für Verfügbarkeitszonen

Verfügbarkeitszonen sind physisch getrennte Gruppen von Rechenzentren innerhalb jeder Azure-Region. Wenn eine Zone ausfällt, erfolgt ein Failover der Dienste zu einer der verbleibenden Zonen.

Azure Database for PostgreSQL unterstützt sowohl zonenredundant als auch zonalmodelle für Konfigurationen mit hoher Verfügbarkeit. Beide Hochverfügbarkeitskonfigurationen ermöglichen ein automatisches Failover ohne Datenverlust während geplanten als auch ungeplanten Ereignissen.

• Zonenredundant. Mit der zonenredundanten Hochverfügbarkeit wird ein Standbyreplikat in einer anderen Zone mit automatischer Failoverfunktion bereitgestellt. Zonenredundanz bietet die höchste Verfügbarkeitsebene, Sie müssen jedoch Anwendungsredundanz über Zonen hinweg konfigurieren. Wählen Sie daher Zonenredundanz aus, wenn Sie sich vor Ausfällen auf Verfügbarkeitszonenebene schützen möchten und die verfügbarkeitszonenübergreifende Latenz akzeptabel ist. Während aufgrund der synchronen Replikation Auswirkungen auf Schreibvorgänge und Commits auftreten können, wirkt sich dies jedoch nicht auf Leseabfragen aus. Diese Auswirkung ist spezifisch für Ihre Workloads, den ausgewählten SKU-Typ und die Region.

  Sie können die Region sowie die Verfügbarkeitszonen für sowohl den primären Server als auch den Standbyserver auswählen. Der Standbyreplikatserver wird in der ausgewählten Verfügbarkeitszone in derselben Region mit einer ähnlichen Compute-, Speicher- und Netzwerkkonfiguration wie der primäre Server bereitgestellt. Datendateien und Transaktionsprotokolldateien (Schreib-Ahead-Protokolle, auch wal genannt) werden in jeder Verfügbarkeitszone auf lokal redundanten Speicher (LRS) gespeichert, wobei automatisch drei Datenkopien gespeichert werden. Eine zonenredundante Konfiguration ermöglicht eine physische Isolierung des gesamten Stapels zwischen primären und Standbyservern.

  

Option zone-redundant ist nur in Regionen verfügbar, die Unterstützung für Verfügbarkeitszonen bieten.

Für Folgendes wird keine Zonenredundanz unterstützt:

• Burstfähige Computeebene

• Regionen mit Verfügbarkeit in einer Zone

• Zonal. Wählen Sie eine zonale Bereitstellung, wenn Sie die bestmögliche Verfügbarkeit innerhalb einer einzelnen Verfügbarkeitszone aber mit der geringstmöglichen Netzwerklatenz erzielen möchten. Sie können die Region und Verfügbarkeitszone auswählen, um beide Ihrer primären Datenbankserver bereitzustellen. Ein Standbyreplikatserver wird automatisch in derselben Verfügbarkeitszone mit einer ähnlichen Compute-, Speicher- und Netzwerkkonfiguration wie der primäre Server bereitgestellt und verwaltet. Eine Zonalkonfiguration schützt Ihre Datenbank vor Fehlern auf Knotenebene und hilft auch bei der Reduzierung der Downtime von Anwendungen während geplanter und ungeplanter Downtimeereignisse. Die Daten vom primären Server werden im synchronen Modus auf das Standbyreplikat repliziert. Bei einer Unterbrechung des primären Servers erfolgt automatisch ein Failover auf die Standby-Replik.

  

Die Zonalbereitstellungsoption ist in allen Azure-Regionen verfügbar, in denen Flexible Server bereitgestellt werden kann.

Konfigurieren der Zonalresilienz im Portal

Sie können hohe Verfügbarkeit (HA) auf zwei Arten konfigurieren: zonenredundanter HA, der den Standbyserver in einer anderen Verfügbarkeitszone für maximale Resilienz oder ha derselben Zone platziert, die den Standbyserver in derselben Zone wie der primäre Server bereitstellt, um die Latenz zu minimieren.

Um die Konfiguration zu vereinfachen und die Zonalresilienz sicherzustellen, bietet das Portal eine Zonal Resiliency-Option mit zwei Optionsfeldern: Aktiviert und deaktiviert. Wählen Sie "Aktivieren" aus, um zu versuchen, den Standby-Server in einer anderen Verfügbarkeitszone (zonenredundante HA-Modus) zu erstellen. Wenn der Bereich keinen zonenredundanten HA unterstützt, können Sie stattdessen das Fallback-Kontrollkästchen (in der folgenden Abbildung hervorgehoben) aktivieren, um den ha derselben Zone zu aktivieren.

Wenn Sie das Fallback-Kontrollkästchen aktivieren, erstellt das System den Standbyserver in derselben Zone und löst später während eines Wartungsfensters einen automatischen Migrationsworkflow aus, um ihn in eine andere Zone zu verschieben, sobald die Kapazität verfügbar ist. Wenn Sie das Kontrollkästchen nicht aktivieren und die Zonalkapazität nicht verfügbar ist, schlägt die HA-Aktivierung fehl. Dieser Entwurf erzwingt zonenredundanten HA als Standard und stellt gleichzeitig einen kontrollierten Fallback für die gleiche Zone HA bereit, wodurch sichergestellt wird, dass Workloads letztendlich eine vollständige Zonenresilienz ohne manuelle Eingriffe erreichen.

Hochverfügbarkeitsfeatures

• Ein Standbyreplikat wird in derselben VM-Konfiguration bereitgestellt – einschließlich vCores, Speicher und Netzwerkeinstellungen – als primärer Server.

• Sie können die Verfügbarkeitszonenunterstützung für einen vorhandenen Datenbankserver hinzufügen.

• Sie können das Standbyreplikat entfernen, indem Sie Hochverfügbarkeit deaktivieren.

• Sie können die Verfügbarkeitszonen für den primären Datenbankserver und den Standbydatenbankserver für die zonenredundante Verfügbarkeit auswählen.

• Vorgänge wie Beenden, Starten und Neustarten werden auf primären und Standbydatenbankservern gleichzeitig ausgeführt.

• In zonenredundanten und zonalen Modellen führt der primäre Datenbankserver regelmäßig automatische Sicherungen aus. Gleichzeitig archiviert das Standbyreplikat kontinuierlich die Transaktionsprotokolle im Sicherungsspeicher. Wenn die Region Verfügbarkeitszonen unterstützt, werden Sicherungsdaten in zonenredundantem Speicher (ZRS) gespeichert. Wenn die Region keine Verfügbarkeitszonen unterstützt, werden Sicherungsdaten in lokal redundantem Speicher (LRS) gespeichert.

• Clients stellen stets eine Verbindung mit dem Hostnamen des primären Datenbankservers her.

• Alle Änderungen an den Serverparametern werden auch auf das Standbyreplikat angewendet.

• Sie können den Server neu starten, um änderungen an statischen Serverparametern zu übernehmen.

• Regelmäßige Wartungsaktivitäten wie Nebenversionsupgrades erfolgen zuerst im Standbymodus. Um Ausfallzeiten zu reduzieren, wird der Standby-Knoten zum Primärknoten heraufgestuft, sodass Arbeitslasten fortgesetzt werden können, während die Wartungsaufgaben auf dem verbleibenden Knoten durchgeführt werden.

Überwachen der Hochverfügbarkeitsintegrität

Die Überwachung des Verfügbarkeitsstatus (hohe Verfügbarkeit, HA) in Azure Database for PostgreSQL bietet einen kontinuierlichen Überblick über den Status und die Bereitschaft von HA-fähigen Instanzen. Dieses Überwachungsfeature wendet das Azure Resource Health Check (RHC) -Framework an, um Probleme zu erkennen und zu benachrichtigen, die sich auf die Failoverbereitschaft ihrer Datenbank oder die allgemeine Verfügbarkeit auswirken können. Durch die Bewertung wichtiger Metriken wie Verbindungsstatus, Failoverstatus und Datenreplikationsintegrität ermöglicht die HA-Integritätsstatusüberwachung proaktive Problembehandlung und hilft dabei, die Betriebszeit und Leistung Ihrer Datenbank aufrechtzuerhalten.

Verwenden Sie die HA-Integritätsstatusüberwachung, um:

• Erhalten Sie Echtzeit-Einblicke in die Integrität von primären und Standby-Replikaten mit Statusindikatoren, die potenzielle Probleme erkennen, z. B. beeinträchtigte Leistung oder Netzwerksperrung.
• Richten Sie Benachrichtigungen für zeitnahe Hinweise über Änderungen im HA-Status ein, damit Sie sofort Schritte unternehmen können, um potenzielle Störungen zu beheben.
• Optimieren der Failoverbereitschaft durch die Ermittlung und Behandlung von Problemen, bevor sie sich auf Datenbankvorgänge auswirken

Eine ausführliche Anleitung zum Konfigurieren und Interpretieren von HA-Gesundheitsstatus finden Sie unter Überwachung des Hochverfügbarkeits- (HA) Gesundheitsstatus für Azure-Datenbank für PostgreSQL.

Hochverfügbarkeit – Einschränkungen

• Aufgrund der synchronen Replikation auf den Standby-Server, insbesondere bei einer zonenredundanten Konfiguration, können Anwendungen eine erhöhte Schreib- und Commit-Latenz erfahren.

• Sie können das Standbyreplikat nicht für Leseabfragen verwenden.

• Je nach Workload und Aktivität auf dem primären Server dauert der Failoverprozess möglicherweise länger als 120 Sekunden, da das Standbyreplikat wiederhergestellt werden muss, bevor es höhergestuft werden kann.

• Der Standbyserver stellt WAL-Dateien in der Regel mit 40 MB/s wieder her. Bei größeren Versionen kann diese Rate auf bis zu 200 MB/s erhöht werden. Wenn Ihre Workload diesen Grenzwert überschreitet, kann die Wiederherstellung entweder während des Failovers oder nach dem Einrichten eines neuen Standbyservers länger dauern.

• Ein Neustart des primären Datenbankservers führt auch zu einem Neustart des Standbyreplikats.

• Sie können keinen zusätzlichen Standbymodus konfigurieren.

• Sie können während des verwalteten Wartungsfensters keine vom Kunden initiierten Verwaltungsaufgaben planen.

• Geplante Ereignisse wie Scale Computing und Skalierungsspeicher erfolgen zuerst im Standbymodus und dann auf dem primären Server. Der Server führt derzeit für diese geplanten Vorgänge kein Failover aus.

• Wenn die logische Decodierung oder logische Replikation auf einem hafähigen flexiblen Server konfiguriert ist.

  • In PostgreSQL 16 und früheren Versionen werden logische Replikationsplätze nach einem Failover standardmäßig nicht auf dem Standbyserver beibehalten.
  • Um sicherzustellen, dass die logische Replikation nach dem Failover weiterhin funktioniert, müssen Sie die pg_failover_slots-Erweiterung aktivieren und unterstützende Einstellungen konfigurieren, z. B. hot_standby_feedback = on.
  • Ab PostgreSQL 17 wird die Slotsynchronisierung nativ unterstützt. Wenn Sie die richtigen PostgreSQL-Konfigurationen (sync_replication_slots, hot_standby_feedback) aktivieren, werden logische Replikationsplätze nach dem Failover automatisch beibehalten, und es ist keine Erweiterung erforderlich.
  • Informationen zu Setupschritten und Voraussetzungen finden Sie in der Dokumentation zur PG_Failover_Slots Erweiterung .

• Das Konfigurieren von Verfügbarkeitszonen zwischen privatem (virtuellem Netzwerk) und öffentlichem Zugriff mit privaten Endpunkten wird nicht unterstützt. Sie müssen Verfügbarkeitszonen innerhalb eines virtuellen Netzwerks (über Verfügbarkeitszonen in einer Region verteilt) oder den öffentlichen Zugriff mit privaten Endpunkten konfigurieren.

• Sie können Verfügbarkeitszonen nur innerhalb einer einzelnen Region konfigurieren. Verfügbarkeitszonen können in allen Regionen nicht konfiguriert werden.

Service Level Agreement (SLA)

• Das Zonal-Modell bietet eine Uptime für ein SLA für ca. 99%.

• Das Zonenredundanzmodell bietet eine Betriebszeit von etwa 99% im Rahmen einer SLA.

Erstellen einer Azure-Datenbank für PostgreSQL mit aktivierter Verfügbarkeitszone

Informationen zum Erstellen einer Azure-Datenbank für PostgreSQL für hohe Verfügbarkeit mit Verfügbarkeitszonen finden Sie in der Schnellstartanleitung: Erstellen einer Azure-Datenbank für PostgreSQL im Azure-Portal.

Erneute Bereitstellung und Migration von Verfügbarkeitszonen

Informationen zum Aktivieren oder Deaktivieren der Konfiguration für hohe Verfügbarkeit in Ihrem flexiblen Server in zonenredundanten und zonalen Bereitstellungsmodellen finden Sie unter Verwalten der hohen Verfügbarkeit in Flexible Server.

Komponenten und Workflows mit hoher Verfügbarkeit

Abschluss der Transaktion

Durch die Anwendungstransaktion ausgelöste Schreib- und Commitvorgänge führen das erste Protokoll an das WAL auf dem primären Server. Der primäre Server streamt diese Protokolle mithilfe des Postgres-Streamingprotokolls an den Standbyserver. Wenn der Speicher des Standby-Servers die Protokolle speichert, bestätigt der primäre Server die Fertigstellung des Schreibvorgangs. Die Anwendung setzt ihre Transaktion erst nach dieser Bestätigung fest. Dieser zusätzliche Roundtrip fügt Ihrer Anwendung Latenz hinzu. Der Prozentsatz der Auswirkungen hängt von der Anwendung ab. Dieser Bestätigungsprozess wartet nicht, bis die Protokolle auf dem Standbyserver übernommen wurden. Der Standbyserver bleibt im Wiederherstellungsmodus, bis er höhergestuft wird.

Gesundheitscheck

Flexible Serverintegritätsüberwachung überprüft regelmäßig die Integrität der primären und Standbyserver. Wenn nach mehreren Pings die Überwachung der Systemgesundheit erkennt, dass ein primärer Server nicht erreichbar ist, leitet der Dienst automatisch ohne manuelle Eingriffe auf den Standbyserver um. Der Gesundheitsüberwachungsalgorithmus verwendet mehrere Datenpunkte, um falsch positive Situationen zu vermeiden.

Failovermodi

Der flexible Server unterstützt zwei Failovermodi: Geplantes Failover und nicht geplantes Failover. In beiden Modi, sobald die Replikation fehlschlägt, führt der Standby-Server die Wiederherstellung durch, bevor er zum primären Server befördert wird und sich für Lese-/Schreibzugriff öffnet. Wenn automatische DNS-Einträge mit dem neuen primären Serverendpunkt aktualisiert werden, können Anwendungen mithilfe desselben Endpunkts eine Verbindung mit dem Server herstellen. Im Hintergrund wird ein neuer Standbyserver eingerichtet, sodass Ihre Anwendung die Konnektivität aufrecht erhalten kann.

Hochverfügbarkeitsstatus

Das System überwacht kontinuierlich die Integrität der primären und Standbyserver. Es führt geeignete Aktionen aus, um Probleme zu beheben, einschließlich des Auslösens eines Failovers auf den Standbyserver. In der folgenden Tabelle sind die möglichen Status für hohe Verfügbarkeit aufgeführt:

Vorgänge mit stabilem Zustand

PostgreSQL-Clientanwendungen stellen mithilfe des DB-Servernamens eine Verbindung mit dem primären Server her. Der primäre Server bedient Anwendungslesevorgänge direkt. Gleichzeitig erhält die Anwendung die Bestätigung für Commits und Schreiboperationen, nachdem die Protokolldaten sowohl auf dem primären Server als auch auf dem Standby-Replikat gespeichert wurden. Aufgrund dieses zusätzlichen Roundtrips ist bei Anwendungen mit einer höheren Latenz für Schreib- und Commitvorgänge zu rechnen. Sie können die Integrität der Hochverfügbarkeit im Portal überwachen.

1. Clients stellen eine Verbindung mit der Flexible Server-Instanz her und führen Schreibvorgänge aus.
2. Änderungen werden auf den Bereitschaftsstandort repliziert.
3. Der primäre Server empfängt eine Bestätigung.
4. Schreib- und Commitvorgänge werden bestätigt.

Point-in-Time-Wiederherstellung von Hochverfügbarkeitsservern

Für flexible Server, die mit hoher Verfügbarkeit konfiguriert sind, repliziert das System Protokolldaten in Echtzeit auf den Standbyserver. Alle Benutzerfehler auf dem primären Server – z. B. versehentliches Ablegen einer Tabelle oder falsche Datenaktualisierungen – werden in das Standbyreplikat repliziert. Daher können Sie den Standbymodus nicht verwenden, um solche logischen Fehler zu beheben. Um sich von solchen Fehlern zu erholen, müssen Sie eine Wiederherstellung zu einem bestimmten Zeitpunkt aus der Sicherung durchführen. Mithilfe der Point-in-Time-Wiederherstellungsfunktion eines flexiblen Servers können Sie die Zeit vor dem Auftreten des Fehlers wiederherstellen. Ein neuer Datenbankserver wird als flexibler Server mit einer einzelnen Zone und einem neuen vom Benutzer angegebenen Servernamen bei mit Hochverfügbarkeit konfigurierten Datenbanken wiederhergestellt. Sie können den wiederhergestellten Server für mehrere Anwendungsfälle verwenden:

• Verwenden Sie den wiederhergestellten Server für die Produktion, und aktivieren Sie optional hohe Verfügbarkeit mit Standbyreplikaten in derselben Zone oder einer anderen Zone in derselben Region.

• Wenn Sie ein Objekt wiederherstellen möchten, exportieren Sie das Objekt vom wiederhergestellten Datenbankserver und importieren es in Ihren Produktionsdatenbankserver.

• Wenn Sie Ihren Datenbankserver für Test- und Entwicklungszwecke klonen oder für andere Zwecke wiederherstellen möchten, können Sie auch eine Zeitpunktwiederherstellung durchführen.

Informationen zum Ausführen einer Zeitpunktwiederherstellung eines flexiblen Servers finden Sie unter Zeitpunktwiederherstellung eines flexiblen Servers.

Failover-Unterstützung

Geplantes Failover

Zu den geplanten Ausfallzeiten zählen regelmäßige geplante Softwareupdates und Upgrades von Nebenversionen in Azure. Sie können auch ein geplantes Failover verwenden, um den primären Server an eine bevorzugte Verfügbarkeitszone zurückzugeben. Wenn Sie hohe Verfügbarkeit konfigurieren, gelten diese Vorgänge zuerst für das Standbyreplikat, während Anwendungen weiterhin auf den primären Server zugreifen. Sobald der Prozess das Standbyreplikat aktualisiert hat, werden primäre Serververbindungen ausgelassen und ein Failover ausgelöst, das das Standbyreplikat als primärer Server mit demselben Datenbankservernamen aktiviert. Clientanwendungen stellen erneut eine Verbindung mit demselben Datenbankservernamen mit dem neuen primären Server her und können deren Vorgänge fortsetzen. Der Prozess richtet einen neuen Standbyserver in derselben Zone wie die alte Primäre ein.

Bei anderen vom Benutzer initiierten Vorgängen, wie der Skalierung von Berechnungen oder der Skalierung des Speichers, wendet der Prozess zuerst Änderungen am Standby und dann am Primärsystem an. Derzeit schaltet der Dienst nicht auf das Standby-System um. Während der Skalierungsvorgang auf dem primären Server ausgeführt wird, treten bei Anwendungen kurze Ausfallzeiten auf.

Sie können diese Funktion auch für ein Failover auf den Standby-Server mit geringerer Ausfallzeit nutzen. Ihr primärer Server könnte sich beispielsweise in einer anderen Verfügbarkeitszone befinden als die Anwendung nach einem ungeplanten Failover. Sie sollten den primären Server in die vorherige Zone zurückbringen, um ihn mit Ihrer Anwendung zu verknüpfen.

Wenn Sie dieses Feature ausführen, bereitet der Prozess zuerst den Standbyserver vor, um sicherzustellen, dass er mit den letzten Transaktionen aufholt, sodass die Anwendung weiterhin Lese- und Schreibvorgänge ausführt. Der Prozess fördert den Standbymodus und entfernt die Verbindungen mit der primären. Ihre Anwendung kann weiterhin in die primäre Anwendung schreiben, während der Prozess einen neuen Standbyserver im Hintergrund erstellt. In der folgenden Tabelle werden die Schritte beschrieben, die mit dem geplanten Failover verbunden sind:

Die Ausfallzeit der Anwendung beginnt bei Schritt 3 und kann nach Schritt 5 den Betrieb wieder aufnehmen. Die übrigen Schritte erfolgen im Hintergrund, ohne die Schreib- und Commitvorgänge der Anwendung zu beeinträchtigen.

Eine Liste der möglichen geplanten Ausfallzeiten finden Sie unter Geplante Ausfallzeiten.

Nicht geplantes Failover

Ungeplante Ausfallzeiten können aufgrund unvorhergesehener Störungen wie zugrunde liegende Hardwarefehler, Netzwerkprobleme und Softwarefehler auftreten. Wenn der datenbankserver, der mit hoher Verfügbarkeit konfiguriert ist, unerwartet abläuft, aktiviert der Prozess das Standbyreplikat, und Clients können ihre Vorgänge fortsetzen. Wenn Sie keine hohe Verfügbarkeit (High Availability, HA) konfigurieren und der Neustartversuch fehlschlägt, stellt der Prozess automatisch einen neuen Datenbankserver zur Anwendung. Während eine ungeplante Ausfallzeit nicht vermieden werden kann, hilft der flexible Server, die Ausfallzeiten zu mindern, indem automatisch Wiederherstellungsvorgänge ausgeführt werden, ohne dass ein menschlicher Eingriff erforderlich ist.

Informationen zu ungeplanten Failovers und Ausfallzeiten, einschließlich möglicher Szenarien, finden Sie unter Entschärfung ungeplanter Ausfallzeiten.

Failover-Tests (erzwungenes Failover)

Mit einem erzwungenen Failover können Sie das Szenario eines ungeplanten Ausfalls simulieren, während Ihr Workload in der Produktion läuft, und die Ausfallzeiten Ihrer Anwendung beobachten. Sie können auch ein erzwungenes Failover verwenden, wenn der primäre Server nicht mehr reagiert.

Ein erzwungenes Failover fährt den primären Server herunter und leitet den Failoverworkflow ein, in dem das Höherstufen des Standbyservers erfolgt. Sobald der Standbymodus den Wiederherstellungsvorgang bis zu den letzten zugesicherten Daten abgeschlossen hat, wird er zum primären Server heraufgestuft. DNS-Einträge werden aktualisiert, und Ihre Anwendung kann eine Verbindung mit dem höher gestuften primären Server herstellen. Ihre Anwendung kann weiterhin Daten auf den primären Server schreiben, während im Hintergrund ein neuer Standbyserver eingerichtet wird. Dies wirkt sich nicht auf die Betriebszeit aus.

In der folgenden Tabelle werden die Schritte während des erzwungenen Failovers beschrieben:

Die Ausfallzeit der Anwendung beginnt nach Schritt 1 und wird fortgesetzt, bis Schritt 6 abgeschlossen ist. Die anderen Schritte werden im Hintergrund ausgeführt, ohne dass sich dies auf Schreibvorgänge und Commits der Anwendung auswirkt.

Überlegungen beim Ausführen erzwungener Failovers

• Die gesamte End-to-End-Betriebszeit kann länger sein als die tatsächlichen Ausfallzeiten, die von der Anwendung aufgetreten sind.

  Von Bedeutung

  Messen Sie die Ausfallzeit immer aus Sicht der Anwendung!

• Führen Sie nicht sofort ein erneutes Failover durch. Warten Sie mindestens 15 bis 20 Minuten zwischen Failovern, damit der neue Standbyserver vollständig eingerichtet werden kann.

• Führen Sie ein erzwungenes Failover während eines Zeitraums mit geringer Aktivität aus, um Ausfallzeiten zu reduzieren.

Bewährte Methoden für PostgreSQL-Statistiken nach einem Failover

Nach einem PostgreSQL-Failover erfordert die Aufrechterhaltung der optimalen Datenbankleistung ein Verständnis der unterschiedlichen Rollen von pg_statistic und den pg_stat_*-Tabellen. In der pg_statistic Tabelle werden Optimiererstatistiken gespeichert, die für den Abfrageplaner von entscheidender Bedeutung sind. Diese Statistiken umfassen Datenverteilungen innerhalb von Tabellen und bleiben nach einem Failover intakt, um sicherzustellen, dass der Abfrageplaner die Abfrageausführung basierend auf genauen, historischen Datenverteilungsinformationen effektiv optimieren kann.

Im Gegensatz dazu werden die Tabellen pg_stat_*, in denen Aktivitätsstatistiken wie die Anzahl der Scans, gelesene Tupel und Updates erfasst werden, beim Failover zurückgesetzt. Ein Beispiel für eine solche Tabelle ist pg_stat_user_tables, die die Aktivität für benutzerdefinierte Tabellen nachverfolgt. Diese Zurücksetzung spiegelt den betriebstechnischen Zustand des neuen primären Replikats genau wider, bedeutet aber auch den Verlust historischer Aktivitätsmetriken, auf denen der Autovacuumprozess und andere betriebliche Effizienzen aufbauen können.

Führen Sie in Anbetracht dieser Unterscheidung ANALYZE nach einem PostgreSQL-Failover aus. Mit dieser Aktion werden die Tabellen pg_stat_* wie etwa pg_stat_user_tables mit neuen Aktivitätsstatistiken aktualisiert, wodurch der Autovacuumprozess unterstützt und sichergestellt wird, dass die Datenbankleistung in ihrer neuen Rolle optimal bleibt. Dieser proaktive Schritt überbrückt die Lücke zwischen der Beibehaltung wesentlicher Optimiererstatistiken und der Aktualisierung von Aktivitätsmetriken, um den aktuellen Zustand der Datenbank auszurichten.

Zonenausfall

Zonal Um einen Fehler auf Zonenebene wiederherzustellen, können Sie mithilfe der Sicherung eine Point-in-Time-Wiederherstellung durchführen. Sie können einen benutzerdefinierten Wiederherstellungspunkt mit der neuesten Uhrzeit auswählen, um die neuesten Daten wiederherzustellen. Ein neuer flexibler Server wird in einer anderen nicht betroffenen Zone bereitgestellt. Die für die Wiederherstellung benötigte Zeit hängt von der vorherigen Sicherung und dem Volume der wiederherzustellenden Transaktionsprotokolle ab.

Weitere Informationen zur Point-in-Time-Wiederherstellung finden Sie unter Sicherung und Wiederherstellung in der Azure Database for PostgreSQL – flexibler Server.

Zonenredundant: Der flexible Server schlägt automatisch innerhalb von 60 bis 120 Sekunden ohne Datenverlust auf den Standbyserver über.

Konfigurationen ohne Verfügbarkeitszonen

Obwohl es nicht empfohlen wird, können Sie Ihren flexiblen Server konfigurieren, ohne dass eine hohe Verfügbarkeit aktiviert ist. Für flexible Server, die ohne hohe Verfügbarkeit konfiguriert sind, bietet der Dienst lokal redundanten Speicher mit drei Kopien von Daten, zonenredundanten Sicherungen (in Regionen, in denen es unterstützt wird) und integrierte Serverresilienz, um automatisch einen abgestürzten Server neu zu starten und den Server auf einen anderen physischen Knoten zu verschieben. Diese Konfiguration bietet eine Uptime SLA von 99,9%. Bei geplanten oder ungeplanten Failoverereignissen behält der Dienst die Verfügbarkeit der Server mithilfe des folgenden automatisierten Verfahrens bei:

1. Eine neue Computeressource in Form einer Linux-VM wird bereitgestellt.
2. Der Speicher mit Datendateien wird dem neuen virtuellen Computer zugeordnet.
3. Die PostgreSQL-Datenbank-Engine wird auf dem neuen virtuellen Computer online geschaltet.

Die folgende Abbildung zeigt den Übergang zwischen VM und Speicherfehlern.

Regionsübergreifende Notfallwiederherstellung und Geschäftskontinuität

Wenn eine regionweite Katastrophe eintritt, kann Azure Schutz vor regionalen oder großen geografischen Katastrophen mit Notfallwiederherstellung bieten, indem eine andere Region genutzt wird. Weitere Informationen zur Architektur der Azure-Notfallwiederherstellung finden Sie unter Architektur der Notfallwiederherstellung von Azure zu Azure.

Flexible Server bietet Features, die Daten schützen und Ausfallzeiten für Ihre unternehmenskritischen Datenbanken während geplanter und ungeplanter Ausfallzeiten minimieren. Der flexible Server baut auf der Azure-Infrastruktur auf, die robuste Resilienz und Verfügbarkeit bietet, und er stellt Features für die Geschäftskontinuität bereit, die zusätzlichen Fehlerschutz bieten, Anforderungen an die Wiederherstellungszeit erfüllen und die Gefahr von Datenverlusten verringern. Berücksichtigen Sie beim Entwerfen Ihrer Anwendungen die Ausfallzeittoleranz – das Wiederherstellungszeitziel (RTO) und die Gefährdung von Datenverlust – das Wiederherstellungspunktziel (RPO). Beispielsweise müssen für Ihre unternehmenskritische Datenbank strengere Uptimeanforderungen erfüllt werden als bei einer Testdatenbank.

Notfallwiederherstellung in multinationaler Geografie

Georedundante Sicherung und Wiederherstellung

Georedundante Sicherung und Wiederherstellung bieten Ihnen die Möglichkeit, Ihren Server in einer anderen Region wiederherzustellen, wenn ein Notfall auftritt. Sie bietet zudem eine Dauerhaftigkeit der Sicherungsobjekte von mindestens 99,99999999999999 Prozent (16 Neunen) für die Dauer eines Jahres.

Sie können beim Erstellen des Servers nur georedundante Sicherungen konfigurieren. Wenn Sie den Server mit georedundanter Sicherung konfigurieren, werden die Sicherungsdaten und Transaktionsprotokolle asynchron über die Speicherreplikation in den gekoppelten Bereich kopiert.

Weitere Informationen zur georedundanten Sicherung und Wiederherstellung finden Sie unter Georedundante Sicherung und Wiederherstellung.

Lesereplikate

Sie können regionsübergreifende Lesereplikate bereitstellen, um Ihre Datenbanken vor Fehlern auf Regionsebene zu schützen. Lesereplikate werden mithilfe der physischen Replikationstechnologie von PostgreSQL asynchron aktualisiert und sie können damit zu Verzögerungen auf dem primären Server führen. Allgemeine und speicherbezogen optimierte Berechnungsebenen unterstützen Lesereplikate.

Weitere Informationen über Funktionen und Überlegungen zu Lesereplikaten finden Sie unter Lesereplikate.

Erkennung, Benachrichtigung und Verwaltung von Ausfällen

Wenn Sie Ihren Server mit georedundanter Sicherung konfigurieren, können Sie geowiederherstellung in der gekoppelten Region durchführen. Ein neuer Server wird bereitgestellt und mit den letzten verfügbaren Daten wiederhergestellt, die in diese Region kopiert wurden.

Sie können auch regionsübergreifende Lesereplikate verwenden. Wenn ein Regionsfehler auftritt, können Sie einen Notfallwiederherstellungsvorgang ausführen, indem Sie Ihr Lesereplikat zu einem eigenständigen schreib- und lesbaren Server befördern. RPO wird voraussichtlich bis zu 5 Minuten (Datenverlust möglich) sein, es sei denn, ein schwerwiegender regionaler Fehler tritt auf, wobei das RPO zum Zeitpunkt des Ausfalls nahe der Replikationsverzögerung liegen kann.

Weitere Informationen zur Entschärfung ungeplanter Downtime und zur Wiederherstellung nach einer regionalen Störung finden Sie unter Entschärfung ungeplanter Downtime.

Verwandte Inhalte

• Dokumentation zu Azure Database for PostgreSQL
• Zuverlässigkeit in Azure