Zuverlässigkeit in Azure-Datenbank für PostgreSQL

Azure Database for PostgreSQL ist ein vollständig verwalteter Datenbankdienst, der Ihnen präzise Kontrolle und Flexibilität bei Datenbankverwaltungsfunktionen und Konfigurationseinstellungen bietet. Der Dienst bietet hochverfügbarkeits- und Notfallwiederherstellungsfunktionen basierend auf Ihren Anforderungen.

Wenn Sie Azure verwenden, ist Zuverlässigkeit eine gemeinsame Verantwortung. Microsoft bietet eine Reihe von Funktionen zur Unterstützung von Resilienz und Wiederherstellung. Sie sind dafür verantwortlich, zu verstehen, wie diese Funktionen in allen von Ihnen verwendeten Diensten funktionieren, und die Funktionen auswählen, die Sie benötigen, um Ihre Geschäftsziele und Uptime-Ziele zu erfüllen.

In diesem Artikel wird beschrieben, wie Sie Azure Database for PostgreSQL für verschiedene potenzielle Ausfälle und Probleme widerstandsfähig machen, einschließlich vorübergehender Fehler, Ausfall der Verfügbarkeitszone, Regionsausfälle und Servicewartung. Außerdem wird beschrieben, wie Sie Sicherungen verwenden können, um aus anderen Arten von Problemen wiederherzustellen, und hebt wichtige Informationen zum Azure Database for PostgreSQL ServiceLevel Agreement (SLA) hervor.

Bereitstellungsempfehlungen für die Produktion

Informationen zum Bereitstellen von Azure Database for PostgreSQL zur Unterstützung der Zuverlässigkeitsanforderungen Ihrer Lösung und wie sich die Zuverlässigkeit auf andere Aspekte Ihrer Architektur auswirkt, finden Sie unter Architektur bewährte Methoden für Azure Database for PostgreSQL im Azure Well-Architected Framework.To learn how to deploy Azure Database for PostgreSQL to support your solution's reliability requirements, and how reliability affects other aspects of your architecture, see Architecture best practices for Azure Database for PostgreSQL in the Azure Well-Architected Framework.

Übersicht über die Zuverlässigkeitsarchitektur

In diesem Abschnitt werden einige der wichtigen Aspekte der Funktionsweise des Diensts beschrieben, die aus Zuverlässigkeitsperspektive am relevantesten sind. Im Abschnitt wird die logische Architektur vorgestellt, die einige der Ressourcen und Features enthält, die Sie bereitstellen und verwenden. Außerdem wird die physische Architektur erläutert, die Details zur Funktionsweise des Diensts unter den Deckeln bereitstellt.

Logische Architektur

Wenn Sie mit Azure Database for PostgreSQL arbeiten, stellen Sie einen Server bereit, der die Compute- und Speicherressourcen darstellt, die zur Unterstützung der Datenbanken erforderlich sind, die Sie auf dem Server bereitstellen.

Sie können Server in mehreren Computeebenen bereitstellen: Burstable, General Purpose und Memory Optimized. Jede Ebene ist für verschiedene Arten von Workloads optimiert. In einigen Azure-Regionen können Sie Server mit Azure Confidential Computing bereitstellen.

Weitere Informationen zu den allgemeinen Dienstarchitekturen und Bereitstellungsmodellen finden Sie unter Azure Database for PostgreSQL Übersicht.

Physische Architektur

• Compute- und Speichertrennung: Azure Database for PostgreSQL verwendet eine Compute- und Speichertrennungsarchitektur, um hohe Verfügbarkeit zu unterstützen. Das Datenbankmodul wird auf einem virtuellen Linux-Computer (VM) ausgeführt, während Azure Storage die Datendateien enthält und drei lokal redundante synchrone Kopien der Datenbankdateien hält, um die Datenbeständigkeit sicherzustellen.

• Hohe Verfügbarkeit: Sie können eine Hochverfügbarkeitskonfiguration auf Ihrem Server aktivieren. Wenn Sie die Hochverfügbarkeitskonfiguration aktivieren, stellt der Dienst einen Warm-Standby-Server bereit und verwaltet sie. Der primäre Server repliziert Datenänderungen synchron auf den Standbyserver, um sicherzustellen, dass während eines Ausfalls des primären Servers kein Datenverlust auftritt.

  Die Architektur trennt die Computeschicht von der Speicherebene, sodass der Dienst unterschiedliche Arten von Fehlern entsprechend verarbeiten kann. Für eine höhere Ausfallsicherheit können Sie die Server über Verfügbarkeitszonen verteilen.

  

  Diagramm mit der Hochverfügbarkeitsarchitektur für Azure Database for PostgreSQL. Zwei Server sind nebeneinander angeordnet. Auf der linken Seite befindet sich ein Feld mit der Bezeichnung primärer Server, und innerhalb dieses Felds handelt es sich um einen virtuellen Computer und einen Datenträger. Rechts befindet sich ein passendes Feld mit der Bezeichnung Standbyserver, der auch einen virtuellen Computer und einen Datenträger enthält. Ein horizontaler Pfeil zeigt vom primären Server auf der linken seite zum Standbyserver auf der rechten Seite, und der Pfeil wird als Streamingreplikation bezeichnet und gibt eine unidirektionale Beziehung an, in der Datenänderungen vom primären Server zum Standbyserver fließen.

  Ein Standbyserver wird in derselben VM-Konfiguration wie der primäre Server bereitgestellt, einschließlich vCores, Speicher und Netzwerkeinstellungen.

  Sie können zwischen Servern wechseln, indem Sie ein Failover ausführen. Es gibt zwei Arten von Failover: erzwungene Failovers, die verwendet werden, wenn der primäre Server fehlschlägt, und geplante Failovers, die während einiger Wartungsvorgänge und in anderen Szenarien verwendet werden, in denen Sie die Ausfallzeiten der Anwendung während eines Failovers minimieren müssen.

  Wenn Sie Vorgänge wie "Beenden", "Starten" und "Neustart" ausführen, treten sie auf primären und Standbydatenbankservern gleichzeitig auf. Geplante Ereignisse wie Computeskalierung und Speicherskalierung erfolgen zuerst im Standbymodus und dann auf dem primären Server. Derzeit fällt der Server bei diesen geplanten Vorgängen nicht aus.

  Weitere Informationen finden Sie unter "Hohe Verfügbarkeit" in der Azure-Datenbank für PostgreSQL.

• Sicherungen: Azure Database for PostgreSQL erstellt automatisch Server-Backups. Weitere Informationen finden Sie unter Sicherung und Wiederherstellung.

Resilienz für vorübergehende Fehler

Vorübergehende Fehler sind kurze, zeitweilige Fehler in Komponenten. Sie treten häufig in einer verteilten Umgebung wie der Cloud auf und sind ein normaler Bestandteil von Vorgängen. Vorübergehende Fehler korrigieren sich nach kurzer Zeit. Es ist wichtig, dass Ihre Anwendungen vorübergehende Fehler behandeln können, in der Regel durch Wiederholen betroffener Anforderungen.

Alle in der Cloud gehosteten Anwendungen sollten die Anleitung zur vorübergehenden Fehlerbehandlung von Azure befolgen, wenn sie mit cloudgehosteten APIs, Datenbanken und anderen Komponenten kommunizieren. Weitere Informationen finden Sie unter Empfehlungen zur Behandlung vorübergehender Fehler.

Ihre Anwendungen müssen vorübergehende Konnektivitätsfehler behandeln, die bei Wartungs-, Skalierungsvorgängen oder Netzwerkunterbrechungen auftreten können. Folgen Sie den folgenden Empfehlungen:

Weitere Informationen finden Sie unter Behandeln vorübergehender Konnektivitätsfehler in der Azure-Datenbank für PostgreSQL.

Ausfallsicherheit bei Ausfällen von Verfügbarkeitszonen

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

Wählen Sie ihre Art der Verfügbarkeitszone-Unterstützung über die Hochverfügbarkeitskonfiguration aus. Wenn Sie hohe Verfügbarkeit aktivieren, stellt der Dienst neben dem primären Server einen Standbyserver bereit. Dieses Hochverfügbarkeitsmodell trägt dazu bei, sicherzustellen, dass zugesicherte Daten bei Fehlern nie verloren gegangen sind. Unabhängig davon, welches Hochverfügbarkeitsbereitstellungsmodell Ihr Server verwendet, werden Daten synchron auf die primären und Standbyserver übertragen. Wenn eine Unterbrechung beim primären Server auftritt, wechselt der Server automatisch auf den Standbyserver.

Jede Verfügbarkeitszone speichert Datendateien und WALs (Write-Ahead Logs) auf Premium-verwalteten Datenträgern mit lokal redundantem Speicher (LRS), die automatisch drei Datenkopien in jeder Zone speichert.

Azure Database for PostgreSQL unterstützt zwei Konfigurationstypen für Verfügbarkeitszonen, wenn Sie hohe Verfügbarkeit verwenden:

• Zonenredundant hohe Verfügbarkeit: Zonenredundanz bietet die höchste Zonenresilienz, indem ein primärer Server in einer Verfügbarkeitszone und ein Standbyserver in einer anderen Verfügbarkeitszone bereitgestellt wird. Der Standbyserver verwendet Compute-, Speicher- und Netzwerkkonfigurationen, die dem des primären Servers ähneln. Eine zonenredundante Konfiguration ermöglicht eine physische Isolierung des gesamten Stapels zwischen primären und Standbyservern.

  Sie können entweder die Verfügbarkeitszonen für die primären und Standbyserver auswählen oder Microsoft diese auswählen lassen.

  Es wird empfohlen, zonenredundante Bereitstellungen für Produktionsserver zu verwenden.

  

  Diagramm einer zonenredundanten Azure Database for PostgreSQL-Bereitstellung über mehrere Verfügbarkeitszonen hinweg. Drei Zonen sind oben aufgeführt: Verfügbarkeitszone 1, Verfügbarkeitszone 2 und Verfügbarkeitszone 3. Unter Verfügbarkeitszone 1 befindet sich ein Kasten mit der Beschriftung „Primärserver“; innerhalb dieses Kastens befinden sich eine virtuelle Maschine und ein Datenträger, wodurch gezeigt wird, dass der Primärserver aus Rechenleistung und Speicher besteht. Unter der Verfügbarkeitszone 2 gibt es ein entsprechendes Feld mit der Bezeichnung Standby-Server, das ebenfalls eine virtuelle Maschine und einen Datenträger enthält. Zwischen diesen beiden Server-Boxen befindet sich ein nach rechts gerichteter Pfeil mit der Beschriftung „Streaming-Replikation“, der zeigt, dass Datenänderungen vom primären Server auf der linken Seite zum Standby-Server auf der rechten Seite fließen. Das Layout kommuniziert zonenübergreifende Resilienz: Primär- und Standbymodus werden über zwei Verfügbarkeitszonen getrennt, während die Verfügbarkeitszone 3 nicht verwendet wird.

  Die Schreibvorgänge können zu einer geringen Erhöhung der Commit-Latenz führen, da der Dienst Daten synchron auf den Standbyserver repliziert. Die Auswirkungen variieren je nach Workload, ausgewählter SKU und Region.

• Zonal (same-zone) hohe Verfügbarkeit: Die Primär- und Standby-Server verwenden dieselbe Verfügbarkeitszone. Wenn eine Unterbrechung auf dem primären Server auftritt, die Zone jedoch weiterhin fehlerfrei ist, schlägt der Server automatisch auf den Standbyserver zurück. Eine Zonalbereitstellung bietet Ihnen eine hohe Verfügbarkeit innerhalb einer einzelnen Verfügbarkeitszone. Es schützt Sie vor Fehlern auf Knotenebene und hilft auch, Die Ausfallzeiten der Anwendung während geplanter und ungeplanter Ausfallzeiten zu reduzieren. Sie schützt jedoch nicht vor einem Ausfall in dieser Zone.

  

  Diagramm, das eine zonenbasierte Bereitstellung von Azure Database for PostgreSQL in einer einzelnen Verfügbarkeitszone zeigt. Es werden drei Zonen angezeigt: Verfügbarkeitszone 1, Verfügbarkeitszone 2 und Verfügbarkeitszone 3. In der Verfügbarkeitszone 1 befinden sich zwei Kästchen nebeneinander. Das Feld auf der linken Seite ist als primärer Server gekennzeichnet, und innerhalb dieses Felds handelt es sich um einen virtuellen Computer und einen Datenträger. Das Feld auf der rechten Seite ist als Standbyserver bezeichnet, und innerhalb dieses Felds handelt es sich um einen virtuellen Computer und einen Datenträger. Zwischen diesen beiden Serverkästen befindet sich ein nach rechts gerichteter Pfeil mit der Beschriftung „Streaming-Replikation“, der zeigt, dass Datenänderungen vom Primärserver auf der linken Seite zum Standby-Server auf der rechten Seite fließen. Beide Server befinden sich in derselben Verfügbarkeitszone. Verfügbarkeitszone 2 und Verfügbarkeitszone 3 werden nicht verwendet.

  Hohe Verfügbarkeit innerhalb derselben Zone (same-zone) ist nur in den folgenden Situationen verfügbar:

  • Die Region unterstützt keine Verfügbarkeitszonen. Die Region funktioniert effektiv als einzelne Zone, sodass die einzige Hochverfügbarkeitskonfiguration, die Sie auswählen können, dieselbe Zone ist.
  • Wenn eine Region nicht über ausreichende Kapazität für eine zonenredundante Bereitstellung verfügt, kann der Dienst zunächst beide Server in derselben Verfügbarkeitszone platzieren und diese dann automatisch zu separaten Zonen migrieren, wenn die Kapazität verfügbar wird. Diese Option ist verfügbar, wenn Sie das Azure-Portal oder die Azure CLI verwenden, um einen Server bereitzustellen. Weitere Informationen finden Sie unter Konfigurieren von Business Critical-Optionen (hohe Verfügbarkeit).

  Wenn Sie die Server in derselben Zone platzieren, kann die Schreiblatenz für Anwendungen reduziert werden, die Sie innerhalb derselben Zone bereitstellen.

  Wenn sich die Server in derselben Zone befinden, kann die Schreiblatenz für Anwendungen, die Sie innerhalb derselben Zone bereitstellen, reduziert werden.

Wenn Sie Ihren Server ohne hohe Verfügbarkeit konfigurieren, wird er auf einem einzelnen Server ausgeführt. Wenn dieser Server oder seine Zone nicht mehr verfügbar ist, ist dein Server ebenfalls nicht erreichbar. Weitere Informationen finden Sie unter Konfigurationen ohne Verfügbarkeitszonen.

Anforderungen

• Regionsunterstützung: Azure Database for PostgreSQL unterstützt Konfigurationen von Verfügbarkeitszonen in Azure Regionen unterschiedlich. Eine vollständige Liste der Regionen sowie die Typen der Verfügbarkeitszonenunterstützung und alle spezifischen Überlegungen für jede Region finden Sie unter Azure Regionen.

• Rechenschicht: Die folgende Tabelle führt die Rechenschichtunterstützung für jeden Typ von Verfügbarkeitszonenunterstützung auf:

  Rechenebene	Zonenredundant	Zonal (gleiche Zone)
  Burstfähig	Nicht unterstützt	Nicht unterstützt
  Allgemeiner Zweck	Unterstützt	Unterstützt
  Arbeitsspeicheroptimiert	Unterstützt	Unterstützt

• Dienstebene: Beide Arten von hoher Verfügbarkeit erfordern allgemeine oder speicheroptimierte Ebenen.

Überlegungen

Regionskapazität: Wenn eine Region nicht über ausreichende Kapazität für eine zonenredundante Bereitstellung verfügt, kann der Dienst zunächst beide Server in derselben Verfügbarkeitszone platzieren und diese automatisch zu separaten Zonen migrieren, wenn die Kapazität verfügbar wird. Diese Option ist verfügbar, wenn Sie das Azure-Portal oder die Azure CLI verwenden, um einen Server bereitzustellen. Weitere Informationen finden Sie unter Business Critical-Optionen für Hochverfügbarkeit konfigurieren.

Cost

Wenn Sie hohe Verfügbarkeit aktivieren, wird ein Standbyserver erstellt, und er wird mit der gleichen Rate wie der primäre Server abgerechnet. Die Konfiguration der Verfügbarkeitszone wirkt sich nicht auf die Kosten aus. Es gibt keine Gebühren für die Datenreplikation innerhalb oder zwischen Verfügbarkeitszonen. Abhängig von Ihrem Sicherungsspeichervolume wird Ihnen möglicherweise auch der Sicherungsspeicher in Rechnung gestellt. Ausführliche Preisinformationen finden Sie unter Azure Database for PostgreSQL pricing.

Konfigurieren der Unterstützung von Verfügbarkeitszonen

Konfigurieren Sie die Hochverfügbarkeitseinstellungen, um die Verfügbarkeitszonenunterstützung für einen Server zu konfigurieren.

• Erstellen eines zonenredundanten Servers: Informationen zum Erstellen eines Servers mit aktivierter Hoher Verfügbarkeit und Zonenredundanz finden Sie in der Schnellstartanleitung: Erstellen eines Azure Database for PostgreSQL Servers.

• Ändern der Verfügbarkeitszonenkonfiguration für vorhandene Server: Ändern Sie die Verfügbarkeitszonenkonfiguration für vorhandene Server, indem Sie die Einstellungen für hohe Verfügbarkeit ändern. Ausführliche Schritte finden Sie unter Aktivieren der hohen Verfügbarkeit für vorhandene Server.

  Sie können die Zone, die für den primären oder Standbyserver verwendet wird, nicht ändern. Sie müssen den Server erneut erstellen.

  Tipp

  Es wird empfohlen, zu warten, bis die Serveraktivität niedrig ist, bevor Sie die Konfiguration für hohe Verfügbarkeit ändern.

• Hohe Verfügbarkeit deaktivieren: Durch das Deaktivieren der hohen Verfügbarkeit wird der Standbyserver entfernt, sodass Ihr Server nicht widerstandsfähig gegen Ausfälle in der Verfügbarkeitszone ist. Weitere Informationen finden Sie unter "Deaktivieren der hohen Verfügbarkeit".

Verhalten, wenn alle Zonen fehlerfrei sind

In diesem Abschnitt wird beschrieben, was Sie erwarten müssen, wenn Sie Server mit Unterstützung für hohe Verfügbarkeit und Verfügbarkeitszone konfigurieren, und alle Verfügbarkeitszonen sind betriebsbereit.

• Zonenübergreifender Vorgang: PostgreSQL-Clientanwendungen stellen mithilfe des Datenbankservernamens eine Verbindung mit dem primären Server her. Azure Database for PostgreSQL verwendet eine aktiv passive Konfiguration, bei der der primäre Server in der zone der primären Verfügbarkeit alle Datenbankverbindungen und Abfragen verarbeitet. Der Standbyserver dient während des normalen Betriebs nicht dem Clientdatenverkehr.

• Zonenübergreifende Datenreplikation: Der primäre Server repliziert synchron Änderungen an dem Standbyserver. Transaktionen werden erst als abgeschlossen betrachtet, wenn sowohl die primären als auch die Standbyserver den Schreibvorgang bestätigen.

  Wenn eine Anwendung Daten schreibt und festschreibt, protokolliert PostgreSQL die Änderung zuerst im WAL auf dem Primärserver. Der primäre Server streamt diese Protokolle mithilfe des PostgreSQL-Streamingprotokolls an den Standbyserver. Nachdem der Standbyserver den WAL dauerhaft speichert, bestätigt der primäre Server den Schreibvorgang. Die Anwendung setzt ihre Transaktion erst nach dieser Bestätigung fest. Dieser Bestätigungsprozess wartet nicht, bis die Protokolle auf dem Standbyserver übernommen wurden.

  Die Auswirkungen der Replikation unterscheiden sich je nach der Von Ihrem Server genutzten Verfügbarkeitszonenkonfiguration:

  • Zonenredundant: Da sich die Server in separaten Zonen befinden, stellt dieser Ansatz während eines Zonenausfalls null Datenverluste sicher. Diese Situation wird manchmal auch als Erreichen eines Wiederherstellungspunktziels (RPO) von Null für Zonenfehler bezeichnet.

    Die zonenübergreifende Replikation kann jedoch eine geringe Menge an zusätzlicher Latenz aufweisen. Die Auswirkungen der Latenz hängen von der Anwendung ab. Für die meisten Anwendungen ist die zusätzliche Latenz vernachlässigbar.

  • Zonal: Da sich beide Server in derselben Zone befinden, wird kein Datenverkehr zwischen Zonen repliziert.

  Hinweis

  Das System repliziert Protokolldaten in Echtzeit auf den Standbyserver. Alle Benutzerfehler auf dem primären Server, z. B. ein versehentlicher Abbruch einer Tabelle oder falsche Datenaktualisierungen, werden auf den Standbyserver repliziert. Sie können den Standbymodus nicht verwenden, um diese Arten von Fehlern wiederherzustellen, und Sie müssen eine Point-in-Time-Wiederherstellung aus der Sicherung ausführen. Weitere Informationen finden Sie unter Sicherung und Wiederherstellung.

Verhalten bei einem Zoneausfall

In diesem Abschnitt wird beschrieben, was Sie erwartet, wenn Sie Server mit Hochverfügbarkeit und Unterstützung für Verfügbarkeitszonen konfigurieren und es zu einem Ausfall einer Verfügbarkeitszone kommt.

• Erkennung und Reaktion: Azure überprüft in regelmäßigen Abständen 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.

  Wenn eine Verfügbarkeitszone fehlschlägt, unterscheidet sich das Verhalten je nach der Vom Server genutzten Verfügbarkeitszonenkonfiguration:

  • Zonenredundant: Azure Database for PostgreSQL erkennt automatisch Ausfälle in den Verfügbarkeitszonen. Eine Übersicht über die möglichen Hochverfügbarkeits-Statustypen finden Sie unter Überwachung des Integritätsstatus für Hochverfügbarkeit (HA). Wenn eine Zone fehlschlägt, initiiert Azure ein erzwungenes Failover auf den Standbyserver, ohne dass Sie Maßnahmen ergreifen müssen.

  • Zonal: Wenn die Verfügbarkeitszone, in der ein Zonalserver gehostet wird, nicht verfügbar ist, sind sowohl die primären als auch die Standbyserver nicht verfügbar. In diesem Szenario stellt der Dienst kein automatisches Failover bereit. Sie sind dafür verantwortlich, den Zonenausfall zu erkennen und Wiederherstellungsaktionen auszuführen, z. B. das Wiederherstellen zonenredundanter Sicherungen auf einem separaten Server in einer anderen Verfügbarkeitszone oder Region.

• Benachrichtigung: Die Überwachung des Integritäts- und Bereitschaftsstatus der Hochverfügbarkeit in Azure Database for PostgreSQL bietet einen kontinuierlichen Überblick über die Integrität und Bereitschaft von für Hochverfügbarkeit aktivierten Instanzen. Das Überwachungsfeature basiert auf Azure Resource Health und kann probleme erkennen und benachrichtigen, die sich auf die Failoverbereitschaft ihrer Datenbank oder die allgemeine Verfügbarkeit auswirken können. Bewerten Sie wichtige Metriken wie Verbindungsstatus, Failoverstatus und Datenreplikationsintegrität, um proaktive Problembehandlung zu ermöglichen und die Verfügbarkeit und Leistung Ihrer Datenbank aufrechtzuerhalten.

  Eine ausführliche Anleitung zum Konfigurieren und Interpretieren von HA-Integritätsstatus finden Sie unter Integritätsstatusüberwachung für hohe Verfügbarkeit (HA).

• Aktive Anforderungen: Wenn eine Verfügbarkeitszone nicht verfügbar ist, werden alle laufenden Anforderungen an Server in der betroffenen Zone möglicherweise beendet. Anwendungen müssen diese Anfragen wiederholen. Wenn Ihre Clients vorübergehende Fehler angemessen behandeln, indem sie nach kurzer Zeit erneut versuchen, vermeiden sie in der Regel erhebliche Auswirkungen.

• Erwarteter Datenverlust: Die Menge des Datenverlusts hängt von der Konfiguration der Verfügbarkeitszone ab, die Ihr Server verwendet.

  • Zonenredundant: Null Datenverlust wird während des Zonenfailovers aufgrund der synchronen Replikation zwischen den primären und Standbyservern in verschiedenen Zonen erwartet.

  • Zonal: Daten auf Servern innerhalb der betroffenen Zone sind nicht verfügbar, bis die Zone wiederhergestellt ist.

• Erwartete Ausfallzeiten: Die Anzahl der Ausfallzeiten hängt von der Konfiguration der Verfügbarkeitszone ab, die Ihr Server verwendet.

  • Zonenredundant: Failover wird in der Regel innerhalb von 60 bis 120 Sekunden abgeschlossen. Wenn Ihre Clients vorübergehende Fehler angemessen behandeln, indem sie nach kurzer Zeit erneut versuchen, vermeiden sie in der Regel erhebliche Auswirkungen.

  • Zonal: Server in einer betroffenen Zone sind nicht verfügbar, bis die Verfügbarkeitszone wiederhergestellt wird.

• Umverteilung: Das Verhalten der Datenverkehrsumleitung hängt von der Konfiguration der Verfügbarkeitszone ab, die ihr Server verwendet.

  • Zonenredundant: Nach dem Failover wird der ehemalige Standbyserver zum neuen primären Server und beginnt mit der Annahme neuer Verbindungen. Azure richtet automatisch einen neuen Standbyserver in der ursprünglichen primären Zone ein, nachdem er wiederhergestellt wurde. Ausführliche Informationen finden Sie unter Erzwungenes Failover.

  • Zonal: Wenn eine Zone nicht verfügbar ist, ist Ihr Server nicht verfügbar. Wenn Sie über einen separaten Server verfügen, den Sie im Voraus in einer anderen Verfügbarkeitszone oder Region erstellt haben, sind Sie dafür verantwortlich, den Datenverkehr an diesen Server umzuleiten.

Zonenwiederherstellung

Das Verhalten der Zonenwiederherstellung hängt von der Konfiguration der Verfügbarkeitszone ab, die ihr Server verwendet.

• Zonenredundant: Wenn die Verfügbarkeitszone wiederhergestellt wird, erstellt Azure Database for PostgreSQL den Standbyserver automatisch in der wiederhergestellten Zone neu und synchronisiert ihn mit der aktuellen primären. Die wiederhergestellte Zone dient dann als Standby-Standort. Um unnötige Unterbrechungen zu vermeiden, verschiebt der Dienst die primäre Rolle nicht automatisch wieder in die ursprüngliche Zone. Sie können ein geplantes Failover manuell initiieren , wenn Sie die Primäre zur ursprünglichen Zone zurückgeben möchten.

• Zonal: Nachdem die Zone fehlerfrei ist, sind die Server in der Zone wieder verfügbar. Sie sind für alle Zonenwiederherstellungsprozeduren und die Datensynchronisierung verantwortlich, die Ihre Workloads erfordern.

Test auf Zonenfehler

Die Optionen zum Testen von Zonenausfällen hängen von der Konfiguration der Verfügbarkeitszone ab, die Ihre Instanz verwendet.

• Zonenredundant: Sie können die Resilienz Ihrer Anwendung zum Failover testen, indem Sie ein erzwungenes Failover initiieren. Mit einem erzwungenen Failover können Sie ein ungeplantes Ausfallszenario simulieren, während Sie Ihre Workload ausführen und Ihre Anwendungsausfallzeiten beobachten. Es wird empfohlen, Simulationen in einer Nichtproduktionsumgebung oder in einer ruhigen Zeit auszuführen. Weitere Informationen finden Sie unter "Initiieren eines erzwungenen Failovers".

• Zonal: Sie können zwar keinen vollständigen Zonenausfall simulieren, aber Sie können simulieren, dass Der Server nicht verfügbar ist, was einem Zonenausfall ähnelt. Weitere Informationen finden Sie unter Beenden der Berechnung eines Servers.

Widerstandsfähigkeit bei regionalen Ausfällen

Azure Database for PostgreSQL unterstützt regionsübergreifende Lesereplikate, mit denen Sie eine synchronisierte Kopie Ihrer Datenbank in einer anderen Region verwalten können, um eine schnellere Wiederherstellung zu ermöglichen.

Sie können auch georedundante Sicherungen in unterstützten Regionen verwenden, um eine regionsübergreifende Wiederherstellung bereitzustellen. Sicherungen umfassen jedoch in der Regel mehr Ausfallzeiten und Datenverlust als replikation. Weitere Informationen finden Sie unter Sicherung und Wiederherstellung.

Regionsübergreifende Lesereplikate

Sie können Lesereplikate bereitstellen, um Ihre Datenbanken vor Fehlern auf Regionsebene zu schützen. Jedes Lesereplikat ist eine separate Azure-Datenbank für PostgreSQL-Server. Wenn Sie ein Lesereplikat in einer zweiten Azure-Region platzieren, kann Ihr Datenbankserver Resilienz gegen regionale Ausfälle bieten. Sie können bis zu fünf Lesereplikate bereitstellen, die optional in verschiedenen Azure-Regionen liegen können. Die physische Replikationstechnologie von PostgreSQL aktualisiert Lesereplikas asynchron, und sie können hinter dem Primärsystem zurückbleiben. Regionsübergreifende Lesereplikate können optional schreibgeschützte Workloads bereitstellen, um die Latenz für global verteilte Anwendungen zu reduzieren oder Lesedatenverkehr vom primären Server zu entladen. Weitere Informationen über Funktionen und Überlegungen zu Lesereplikaten finden Sie unter Lesereplikate.

Virtuelle Endpunkte bieten Lese-Schreib-Endpunkte und schreibgeschützte Endpunkte und leiten den Datenverkehr automatisch um, wenn ein Replikat promotiert wird, was dazu beiträgt, Ausfallzeiten während Failover-Ereignissen zu minimieren. Es wird dringend empfohlen, virtuelle Endpunkte mit regionsübergreifenden Lesereplikaten zu verwenden, um die Anwendungsresilienz zu verbessern. Weitere Informationen finden Sie unter "Virtuelle Endpunkte" zum Lesen von Replikaten in Azure-Datenbank für PostgreSQL.

Wenn der primäre Bereich fehlschlägt, können Sie eine Heraufstufung auslösen, sodass Das sekundäre Replikat zur primären Replikat wird. Je nachdem, wie Sie Lesereplikate verwenden, können unterschiedliche Failovertypen sinnvoll sein. Wenn Sie Lesereplikate verwenden, um Ausfallsicherheit bei regionalen Ausfällen bereitzustellen, verwenden Sie in der Regel die zum primären Server befördern Methode, die Ihren virtuellen Endpunkt aktualisiert. Während eines Regionsausfalls müssen Sie eine erzwungene Heraufstufung durchführen, was zu einem Datenverlust für alle nicht komplizierten Daten führen kann. In geplanten Szenarien, in denen die primäre Region fehlerfrei ist, können Sie eine geplante Heraufstufung durchführen, um Datenverluste zu vermeiden. Weitere Informationen finden Sie unter Aktivieren von Lesereplikaten in der Azure-Datenbank für PostgreSQL.

Anforderungen

• Regionsunterstützung: Sie können regionsübergreifende Lesereplikate in jeder Region erstellen, die Azure-Datenbank für PostgreSQL unterstützt. Sie sind nicht auf Azure-Regionspaare beschränkt.

• Rechenebenen: Die Rechenebenen "Allgemeine Zwecke" und "Speicheroptimiert" unterstützen Lesereplikate. Die Burstable-Stufe unterstützt keine Lesereplikate.

Überlegungen

• Konfigurationsunterschiede: Lesereplikate erben möglicherweise nicht alle Konfigurationseinstellungen vom primären Server. Planen Sie die Konfiguration der erforderlichen Einstellungen nach dem Failover. Ihre primären Server und Replikate sollten symmetrisch sein, was bedeutet, dass sie dieselben Ebenen, Speichergrößen und Werte für einige Einstellungen aufweisen müssen. Bei Regionsausfällen kann die symmetrische Serveranforderung für erzwungene Werbeaktionen aufgehoben werden. Es empfiehlt sich jedoch, symmetrische Konfigurationen durchzuführen, um unerwartete Probleme zu vermeiden. Weitere Informationen finden Sie unter Konfigurationsverwaltung.

• Überwachung der Replikationsverzögerung: Für den asynchronen Replikationsprozess ist eine Replikationsverzögerung erforderlich, die je nach vielen Faktoren variieren kann. Wenn die Replikationsverzögerung hoch ist, treten möglicherweise Probleme auf dem Server auf. Es ist wichtig, die Replikationsverzögerung zu überwachen, damit Sie Probleme beheben können, bevor sie eskalieren. Weitere Informationen finden Sie unter Überwachen der Replikation.

• Hohe Verfügbarkeit: Lesereplikate können keine hohe Verfügbarkeit aktiviert haben, und wenn sie höhergestuft werden, verfügen sie auch nicht über hohe Verfügbarkeit. Sie sind dafür verantwortlich, hohe Verfügbarkeit nach dem Bewerben eines Replikats zu konfigurieren.

Weitere Faktoren für den zu berücksichtigenden Promotionsprozess finden Sie unter Überlegungen.

Cost

Das Lesen von Replikaten verursacht Rechen- und Speicherkosten sowie regionsübergreifende Datenübertragungsgebühren für die Replikation. Ausführliche Preisinformationen finden Sie unter Azure Database for PostgreSQL pricing and Bandwidth pricing.

Konfigurieren der Multiregion-Unterstützung

• Erstellen eines Lesereplikats: Informationen zum Erstellen eines Lesereplikats finden Sie unter Erstellen eines Lesereplikats. Sie können Replikate nach dem Erstellen des primären Servers konfigurieren, solange der primäre Server ausgeführt und darauf zugegriffen werden kann.

  Informationen zum Erstellen eines virtuellen Endpunkts finden Sie unter Erstellen virtueller Endpunkte.

• Löschen eines Lesereplikats: Informationen zum Löschen eines Lesereplikats finden Sie unter Löschen eines Lesereplikats.

Verhalten, wenn alle Regionen funktionsfähig sind

In diesem Abschnitt wird beschrieben, was Sie erwarten müssen, wenn Ihr Server mit einem Lesereplikat in einer anderen Region und einem virtuellen Endpunkt konfiguriert ist, und alle Regionen sind betriebsbereit:

• Datenverkehrsrouting zwischen Regionen: In normalen Vorgängen leitet Ihr virtueller Endpunkt Datenverkehr für den Lese-/Schreibzugriffsendpunkt an den primären Server in der primären Region weiter. Wenn Sie auch den schreibgeschützten Endpunkt des virtuellen Endpunkts verwenden, leitet er den Datenverkehr an das replizierbare Replikat weiter, das Sie konfigurieren.

• Datenreplikation zwischen Regionen: Regionsübergreifende Lesereplikate verwenden asynchrone Replikation, um auswirkungen auf die Leistung des primären Servers zu minimieren. Die Replikationsverzögerung hängt von vielen Faktoren ab, einschließlich der Schreiblast und der Latenz zwischen dem primären Server und Replikaten. Die Replikationsverzögerung beträgt in der Regel mindestens mehrere Minuten, kann aber länger sein. Weitere Informationen finden Sie unter Überwachen der Replikation.

Verhalten während eines Regionenausfalls

In diesem Abschnitt wird beschrieben, was Sie erwarten müssen, wenn Ihr Server mit einem Lesereplikat in einer anderen Region und einem virtuellen Endpunkt konfiguriert ist, und es gibt einen Ausfall in der primären Region:

• Erkennung und Reaktion: Sie sind dafür verantwortlich, einen Ausfall in der primären Region zu erkennen und manuell ein Lesereplikat zum neuen primären Server zu befördern. Während eines Regionsausfalls müssen Sie eine erzwungene Promotion durchführen, was zu einem Verlust von nicht replizierten Daten führt.

  Von Bedeutung

  Sie sind für das Auslösen der Kampagne verantwortlich. Azure fördert lesereplikate nicht automatisch, auch wenn ein Regionsfehler auftritt.

  Detaillierte Schritte zum Initiieren einer Beförderung finden Sie unter Lesereplikat zur primären Instanz umschalten.

• Benachrichtigung: Microsoft benachrichtigt Sie nicht automatisch, wenn eine Region abfällt. Sie können jedoch Azure Service Health verwenden, um die allgemeine Integrität des Diensts zu verstehen, einschließlich aller Regionsfehler, und Sie können Dienststatuswarnungen einrichten, um Sie über Probleme zu informieren.

• Aktive Anfragen: Der Hochstufungsprozess trennt alle aktiven Verbindungen zur primären Region. Nach Abschluss des Heraufstufungsprozesses müssen Anwendungen erneut versuchen, Verbindungen zur heraufgestuften Replik herzustellen.

• Erwarteter Datenverlust: Während eines Regionsausfalls müssen Sie eine erzwungene Heraufstufung durchführen, was zu einem dauerhaften Verlust von nicht mehr betroffenen Daten führt.

  Die Menge des Datenverlusts hängt von der Replikationsverzögerung zum Zeitpunkt des Ausfalls ab. Die Replikationsverzögerung beträgt in der Regel mindestens mehrere Minuten, kann aber länger sein. Weitere Informationen finden Sie unter Überwachen der Replikation.

• Erwartete Ausfallzeiten: Die erzwungene Aktualisierung wird normalerweise innerhalb von 1 bis 3 Minuten nach dem Auslösen abgeschlossen. Anwendungen müssen möglicherweise auch eine erneute Verbindung mit dem richtigen Endpunkt herstellen. Virtuelle Endpunkte werden als Teil des erzwungenen Beförderungsprozesses aktualisiert. Anwendungen sollten die Time-to-Live (TTL) Werte der DNS-Einträge des Endpunkts berücksichtigen, um sicherzustellen, dass sie nach Abschluss der Promotion schnell wieder mit dem richtigen Replikat verbinden.

• Datenverkehrsumleitung: Der virtuelle Endpunkt für den Server leitet den Anwendungsdatenverkehr automatisch an das neue primäre Replikat weiter.

  Hinweis

  Nachdem ein Lesereplikat zum primären Server hochgestuft wurde, ist die Hochverfügbarkeitskonfiguration nicht aktiviert. Sie müssen die Konfiguration mit hoher Verfügbarkeit manuell aktivieren oder ihren eigenen Automatisierungsprozessen hinzufügen.

Region-Wiederherstellung

Wenn Sie virtuelle Endpunkte verwenden, wird der alte primäre Server automatisch als Lesereplikat konfiguriert, nachdem die primäre Region wiederhergestellt wurde. Sie können eine weitere Heraufstufung durchführen, um die primären Vorgänge an Ihre bevorzugte primäre Region zurückzugeben.

Test auf Regionsfehler

Testen Sie regelmäßig Lesereplikat-Heraufstufungsverfahren, um sicherzustellen, dass Ihre Prozesse gültig sind und dass die Funktionen Ihren RTO-Anforderungen (Recovery Time Objective) und den Anforderungen des Wiederherstellungspunktziels (Recovery Point Objective, RPO) entsprechen.

Sie können ein Lesereplikat jederzeit zum primären Server heraufstufen, auch wenn alle Regionen fehlerfrei sind. Zu Testzwecken:

• Sie können erzwungene Heraufstufungstests durchführen. Es wird empfohlen, diese Tests in einer Nichtproduktionsumgebung durchzuführen, da sie zu Datenverlust führen kann. Erzwungene Promotionstests helfen, das Verhalten zu simulieren, das während eines Regionsausfalls auftritt.
• Verwenden Sie für geplante Wartungs- oder Testszenarien, in denen Sie Datenverluste vermeiden möchten, stattdessen eine geplante Werbeaktion. Geplante Werbeaktionen folgen jedoch einem anderen Prozess als der Förderung während eines Regionsausfalls, sodass sie das Verhalten während eines tatsächlichen Regionsausfalls möglicherweise nicht widerspiegeln.

Schrittweise Anleitungen finden Sie unter Umschalten der Lesereplik auf Primär.

Führen Sie im Rahmen Ihrer Notfallwiederherstellungsstrategie regelmäßig vollständige Wiederherstellungs-Drills aus. Diese Drills sollten Datenüberprüfungen, Anwendungsfunktionalitätstests und dokumentierte Rollbackprozeduren umfassen.

Sichern und Wiederherstellen

Azure Database for PostgreSQL sichert Ihre Daten automatisch. Diese Sicherungen bieten Point-in-Time-Wiederherstellungsfunktionen und schützen Sie vor versehentlicher Beschädigung und Löschung von Daten. Microsoft verwaltet die Sicherungen vollständig. Sie unterbrechen nicht die Verfügbarkeit des Servers, und sie umfassen sowohl vollständige Sicherungen als auch Transaktionsprotokollsicherungen.

• Sicherungsspeicher: Wenn Sie den Server in einer Region mit Verfügbarkeitszonen bereitstellen, speichert der Dienst Sicherungen unabhängig von der Hochverfügbarkeitskonfiguration des Servers in zonenredundanten Speicher (ZRS). Für Server, die in Regionen ohne Verfügbarkeitszonen bereitgestellt werden, speichert der Dienst Sicherungen im lokal redundanten Speicher (LRS).

  In Azure-Regionen mit Regionspaaren können Sie beim Erstellen des Servers georedundanten Sicherungsspeicher so konfigurieren, dass Sicherungen zur zusätzlichen Absicherung gegen Regionalausfälle in die zugeordnete Azure-Region repliziert werden. Der Dienst repliziert Sicherungen asynchron.

  Der standardmäßige Aufbewahrungszeitraum für Backups beträgt sieben Tage, Sie können diesen Zeitraum jedoch auf bis zu 35 Tage verlängern. Sie können Azure Backup auch für die langfristige Speicherung manueller Sicherungen für bis zu 10 Jahre verwenden. Alle Sicherungen sind verschlüsselt.

• Wiederherstellen: Mit der Point-in-Time-Wiederherstellung können Sie Ihre Datenbank jederzeit innerhalb des Sicherungsaufbewahrungszeitraums wiederherstellen. Der Wiederherstellungsvorgang erstellt einen neuen Datenbankserver mit einem neuen vom Benutzer bereitgestellten Servernamen. Sie können den neuen Server as-is verwenden oder Daten daraus kopieren.

  Wenn Sie eine georedundante Sicherung wiederherstellen, erstellen Sie einen neuen Server in der gekoppelten Region.

  Diese Funktion ist nützlich, um versehentliche Datenänderungen, Anwendungsfehler oder Testszenarien wiederherzustellen.

Für die meisten Lösungen sollten Sie sich nicht ausschließlich auf Sicherungen verlassen. Verwenden Sie stattdessen die in diesem Handbuch beschriebenen anderen Funktionen, um Ihre Resilienzanforderungen zu unterstützen. Sicherungen schützen jedoch vor einigen Risiken, die andere Ansätze nicht vermeiden. Weitere Informationen finden Sie unter Was sind Redundanz, Replikation und Sicherung?.

Weitere Informationen finden Sie unter Sicherung und Wiederherstellung in der Azure-Datenbank für PostgreSQL.

Resilienz gegenüber Wartungsarbeiten an Diensten

Azure Database for PostgreSQL übernimmt automatisch kritische Wartungsaufgaben, einschließlich Patching der zugrunde liegenden Hardware, des Betriebssystems und des Datenbankmoduls. Der Dienst umfasst Sicherheitsupdates, Softwareupdates und Nebenversionsupgrades im Rahmen der geplanten Wartung.

Befolgen Sie die folgenden Empfehlungen, um sicherzustellen, dass Ihr Server während der Wartungsfenster verfügbar bleibt:

Service-Level-Vereinbarung

Der Service level agreement (SLA) für Azure-Dienste beschreibt die erwartete Verfügbarkeit jedes Diensts und die Bedingungen, die Ihre Lösung erfüllen muss, um diese Verfügbarkeitserwartungen zu erreichen. Weitere Informationen finden Sie unter Dienstleistungsvereinbarungen für Onlinedienste.

Azure Database for PostgreSQL bietet je nach Konfiguration des Servers unterschiedliche Verfügbarkeits-SLAs:

• Server, die mit zonenredundanter Hoher Verfügbarkeit konfiguriert sind, bieten eine Verfügbarkeits-SLA von 99,99%.
• Server, die mit zonal hoher Verfügbarkeit konfiguriert sind, bieten eine VERFÜGBARKEITs-SLA von 99,95%.
• Server, die ohne hohe Verfügbarkeit konfiguriert sind, bieten eine UPTIME-SLA von 99.9%.

Verwandte Inhalte

• Azure Zuverlässigkeit
• Bewährte Methoden für die Architektur für Azure-Datenbank für PostgreSQL
• Übersicht über die Geschäftskontinuität mit Azure Database for PostgreSQL
• Geo-Notfallwiederherstellung in Azure-Datenbank für PostgreSQL
• Terraform-Skripts zur Implementierung von Resilienz- und Wiederherstellbarkeitsprinzipien