Zuverlässigkeit in Azure-Datenbank für PostgreSQL

Azure Database for PostgreSQL ist ein vollständig verwalteter Datenbankdienst, der Ihnen eine präzise Kontrolle und Flexibilität gegenüber Datenbankverwaltungsfunktionen und Konfigurationseinstellungen ermöglicht. Der Dienst bietet funktionen für hohe Verfügbarkeit und Notfallwiederherstellung 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-Datenbank für PostgreSQL für eine Vielzahl potenzieller Ausfälle und Probleme widerstandsfähig machen, einschließlich vorübergehender Fehler, Ausfall der Verfügbarkeitszone, Regionsausfälle und Dienstwartung. Außerdem wird beschrieben, wie Sie Sicherungen verwenden können, um aus anderen Arten von Problemen wiederherzustellen, und hebt einige wichtige Informationen zur Azure-Datenbank für PostgreSQL Service Level 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.

Ü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 für PostgreSQL arbeiten, stellen Sie einen Server bereit, der die für die Unterstützung Ihres Datenbankservers erforderlichen Compute- und Speicherressourcen darstellt. Sie stellen eine oder mehrere Datenbanken auf dem Server bereit.

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

Weitere Informationen zu den allgemeinen Dienstarchitekturen und Bereitstellungsmodellen finden Sie unter Was ist Azure Database for PostgreSQL?.

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 ausgeführt, während Datendateien im Azure-Speicher gespeichert werden, wodurch drei lokal redundante synchrone Kopien der Datenbankdateien verwaltet werden, um die Datenbeständigkeit sicherzustellen.

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

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

  

  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.

  Vorgänge wie Beenden, Starten und Neustarten werden auf primären und Standbydatenbankservern gleichzeitig ausgeführt. Geplante Ereignisse wie Scale Computing und Skalierungsspeicher 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:

• Wenn in ihrer Anwendung vorübergehende Fehler auftreten, versuchen Sie den Vorgang mithilfe eines exponentiellen Backoffs erneut. Erhöhen Sie die Verzögerung zwischen Wiederholungen, und begrenzen Sie die Anzahl der Versuche. Wenn der Vorgang nach den maximalen Wiederholungsversuchen immer noch fehlschlägt, behandeln Sie ihn als Fehler.
• Verwenden Sie nach Möglichkeit Clientbibliotheken (auch als Treiber bezeichnet), die automatisch Wiederholungen behandeln.
• Vorübergehende Fehler, die während Schreibvorgängen auftreten, erfordern eine sorgfältigere Prüfung. Erwägen Sie, Ihre Schreibvorgänge idempotent zu machen, damit sie mehrmals sicher ausgeführt werden können.

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.

Sie können Ihre Art der Verfügbarkeitszonenunterstützung über die Hochverfügbarkeitskonfiguration auswählen. Durch aktivieren der hohen Verfügbarkeit wird neben dem primären Server ein Standbyserver bereitgestellt. Mit diesem Modell mit hoher Verfügbarkeit wird sichergestellt, dass zugesicherte Daten während Fehlern nie verloren gegangen sind. Unabhängig davon, welches Hochverfügbarkeitsbereitstellungsmodell Ihr Server verwendet, werden Daten synchron sowohl auf den primären als auch auf den Standbyservern zugesichert. Wenn eine Unterbrechung beim primären Server auftritt, wechselt der Server automatisch auf den Standbyserver.

Datendateien und WALs (Write-Ahead Logs) werden auf Premium-verwalteten Datenträgern innerhalb jeder Verfügbarkeitszone gespeichert, mit lokal redundantem Speicher (LRS), der 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 ähnliche Compute-, Speicher- und Netzwerkkonfigurationen wie die primäre. 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.

  

  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 bei der Reduzierung von Anwendungsausfallzeiten während geplanter und ungeplanter Ausfallzeiten. Sie schützt jedoch nicht vor einem Ausfall in dieser Zone.

  

  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 Konfiguration für hohe Verfügbarkeit, 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 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 Optionen für geschäftskritische Konfiguration (Hochverfügbarkeit).

  Da sich die Server in derselben Zone befinden, kann sie die Schreiblatenz für Anwendungen verringern, die Sie innerhalb derselben Zone bereitstellen.

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: Die Unterstützung von Azure Database for PostgreSQL für Verfügbarkeitszonenkonfigurationen unterscheidet sich zwischen Azure-Regionen. Eine vollständige Liste der Regionen sowie die Typen der Verfügbarkeitszonenunterstützung und alle spezifischen Überlegungen für diese Region finden Sie unter Azure-Regionen.

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

  Preisstufe	Zonen-redundant	Zonal (gleiche Zone)
  Burstfähig	Nicht unterstützt	Unterstützt
  Allgemeiner Zweck	Unterstützt	Unterstützt
  Arbeitsspeicheroptimiert	Unterstützt	Unterstützt

• Dienstebene: Zonenredundanz erfordert allgemeine oder speicheroptimierte Ebenen.

  Zonal (Same-Zone)-Bereitstellungen werden auf allen Preisstufen unterstützt.

Ü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 Konfigurieren von Business-Critical-Optionen (Hochverfügbarkeit).

Cost

Wenn Sie hohe Verfügbarkeit aktivieren, wird der Standbyserver erstellt und mit der gleichen Rate wie die primäre 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

Um die Verfügbarkeitszonenunterstützung für einen Server zu konfigurieren, konfigurieren Sie die Einstellungen für hohe Verfügbarkeit.

• Erstellen eines zonenredundanten Servers: Informationen zum Erstellen eines Servers mit aktivierter Hoher Verfügbarkeit und Zonenredundanz finden Sie in der Schnellstartanleitung: Erstellen einer Azure-Datenbank für PostgreSQL im Azure-Portal.

• Ändern der Verfügbarkeitszonenkonfiguration für vorhandene Server: Sie können die Verfügbarkeitszonenkonfiguration für vorhandene Server ändern, 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 den Standbyserver nach ihrer Erstellung verwendet wird, nicht ändern. Sie müssen den Server neu erstellen.

  Tipp

  Es empfiehlt sich, 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 Server mit Unterstützung für hohe Verfügbarkeits- und Verfügbarkeitszone konfiguriert sind und alle Verfügbarkeitszonen betriebsbereit sind.

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

• Zonenübergreifende Datenreplikation: Änderungen an Daten werden synchron zwischen den primären und Standbyservern repliziert. Transaktionen werden erst als abgeschlossen betrachtet, wenn sowohl die primären als auch die Standbyserver den Schreibvorgang bestätigen.

  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 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, und für die meisten Anwendungen ist sie 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 also 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 erwarten können, wenn Server mit Unterstützung für hohe Verfügbarkeit und Verfügbarkeitszonen konfiguriert sind und es einen Ausfall der Verfügbarkeitszone gibt.

• 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.

  Im Falle eines Zonenfehlers unterscheidet sich das Verhalten je nach der Konfiguration der Verfügbarkeitszone, die ihr Server verwendet:

  • Zonenredundant: Azure Database for PostgreSQL erkennt automatisch Ausfälle in den Verfügbarkeitszonen. Informationen zum Anzeigen der möglichen Statustypen für hohe Verfügbarkeit finden Sie unter " Hochverfügbarkeitsstatustypen". 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ätsstatus (High Availability, HA) in Azure Database for PostgreSQL bietet einen kontinuierlichen Überblick über die Integrität und Bereitschaft von HA-fähigen 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 Betriebszeit und Leistung Ihrer Datenbank aufrechtzuerhalten.

  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.

• 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 in einer anderen Verfügbarkeitszone oder Region vorkonfiguriert haben, sind Sie für die Umleitung des Datenverkehrs an diesen Server verantwortlich.

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. Der Dienst verschiebt die primäre Rolle nicht automatisch wieder in die ursprüngliche Zone, um unnötige Unterbrechungen zu vermeiden. 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 ihr Server nicht verfügbar ist, ähnlich wie bei einem Zonenausfall. 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. Es gibt verschiedene Arten von Failover, die Sie je nach Verwendung von Lesereplikaten auslösen können. 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.

Hinweis

In diesem Abschnitt werden einige der wichtigen Informationen darüber zusammengefasst, wie Lesereplikate die Ausfallsicherheit bei regionsweiten Ausfällen unterstützen können. Sie können auch Lesereplikate verwenden, um die Leistung zu verbessern und geografisch verteilte Benutzerbasen in großem Maßstab zu unterstützen. Weitere Informationen finden Sie unter Lesen von Replikaten.

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-gekoppelte Regionen 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 Anzahl von Faktoren variieren kann. Wenn die Replikationsverzögerung sehr 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 Überlegungen, die für den Heraufsteigerprozess gelten, finden Sie unter Höherstufen von Lesereplikaten in Azure Database for PostgreSQL – Ü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 Unterstützung für mehrere Regionen

• Erstellen eines Lesereplikats: Informationen zum Erstellen eines Lesereplikats finden Sie unter Erstellen eines Lesereplikats. Replikate können konfiguriert werden, nachdem der primäre Server erstellt wurde, 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 einer Reihe von 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 viel 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 Anforderungen: Alle aktiven Verbindungen zur primären Region werden abgebrochen. Anwendungen müssen versuchen, Verbindungen mit dem höhergestuften Replikat herzustellen, nachdem der Heraufstufungsprozess abgeschlossen ist.

• 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 viel 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 befördert wurde, ist die Hochverfügbarkeitskonfiguration nicht aktiviert. Sie müssen die Konfiguration für hohe Verfügbarkeit manuell aktivieren oder zu 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- und RPO-Anforderungen 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. Beachten Sie, dass geplante Werbeaktionen einem anderen Prozess als der Förderung während eines Ausfalls einer Region folgen.

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 führt automatisch Sicherungen durch, die Point-in-Time-Wiederherstellungsfunktionen bereitstellen, und sie vor versehentlicher Beschädigung und Löschung von Daten schützen. Sicherungen werden vollständig von Microsoft verwaltet, unterbrechen die Verfügbarkeit des Servers nicht und umfassen sowohl vollständige Sicherungen als auch Transaktionsprotokollsicherungen.

• Sicherungsspeicher: Wenn der Server mit zonenredundanter Hoher Verfügbarkeit konfiguriert ist, werden Sicherungen im zonenredundanten Speicher (ZRS) gespeichert. Bei Servern, die ohne Hochverfügbarkeit konfiguriert sind oder mit zonaler (Einzel-Zonen) Hochverfügbarkeit, werden Sicherungen im lokal redundanten Speicher (LRS) gespeichert.

  In Azure-Regionen mit Paaren können Sie bei der Servererstellung den GEO-redundanten Sicherungsspeicher (GRS) konfigurieren, um Sicherungen durch Replikation in die gekoppelte Azure-Region zusätzlichen Schutz vor Regionsfehlern zu bieten. Sicherungen werden asynchron repliziert.

  Der standardmäßige Aufbewahrungszeitraum für die Sicherung beträgt 7 Tage, wobei die Möglichkeit besteht, die Aufbewahrung bis zu 35 Tage zu 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 vom Benutzer festgelegten Servernamen, den Sie entweder direkt verwenden oder von dem Sie Daten kopieren können.

  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 verarbeitet 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:

• Hohe Verfügbarkeit aktivieren: Während der Wartung muss der Server möglicherweise im Rahmen des Updateprozesses neu gestartet werden. Wenn Hohe Verfügbarkeit aktiviert ist, verwenden Wartungsvorgänge in der Regel Rollupdates, um Ausfallzeiten zu minimieren. Regelmäßige Wartungsaktivitäten wie Nebenversionsupgrades erfolgen zuerst im Standbyreplikat. 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. Diese Sequenzierung gilt unabhängig davon, ob Ihr Server zonenredundante oder zonenübergreifende Hochverfügbarkeit verwendet.

  Erwarten Sie für Server ohne hohe Verfügbarkeit kurze Ausfallzeiten während des Wartungsbetriebs. Mit aktivierter hoher Verfügbarkeit werden Wartungsvorgänge in der Regel mit minimalen oder ohne Ausfallzeiten abgeschlossen.

• Konfigurieren von benutzerdefinierten Wartungsfenstern: Sie können den Wartungszeitplan so konfigurieren, dass er vom System verwaltet wird, oder ein benutzerdefiniertes Wartungsfenster definieren, um die Auswirkungen auf Ihre Geschäftsvorgänge zu minimieren. Planen Sie die Wartung während weniger Aktivitätszeiträume, um die Geschäftlichen Auswirkungen zu minimieren. Weitere Informationen finden Sie unter Planen der Wartung.

• Implementieren Sie die Wiederholungslogik: Stellen Sie sicher, dass Ihre Anwendungen kurze Verbindungsunterbrechungen verarbeiten können, die bei Wartungsneustarts auftreten können. Um Ihre Anwendungen widerstandsfähig gegen diese Arten von Problemen zu gestalten, lesen Sie die Anleitung zu Resilienz für vorübergehende Fehler.

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 verschiedene Verfügbarkeits-SLAs basierend auf der Konfiguration des Servers:

• Server, die mit zonenredundanter hoher Verfügbarkeit konfiguriert sind.
• Server, die mit Zonen-basierter (Einzelzonen) hoher Verfügbarkeit konfiguriert sind.
• Server wurden ohne hohe Verfügbarkeit konfiguriert.

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
• Azure Database for PostgreSQL Resiliency Solution Accelerator – Terraform-Skripts, um viele der in diesem Artikel beschriebenen Prinzipien zur Resilienz und Wiederherstellbarkeit zu implementieren.