Geo-Replikation in Azure Database for PostgreSQL Flexible Server

Sie können ein Lesereplikat in derselben Region wie der primäre Server oder in einer anderen geografischen Region erstellen. Georeplikation ist hilfreich für Szenarien wie die Notfallwiederherstellungsplanung oder das Näherbringen von Daten an Ihre Benutzer.

Sie können einen primären Server in einer beliebigen Azure-Datenbank für einen flexiblen Serverdienstbereich für PostgreSQL haben. Ein Primärserver kann auch Replikate in jeder globalen Region von Azure haben, die Azure Database for PostgreSQL flexiblen Server unterstützt. Darüber hinaus unterstützt der Dienst Regionen in den souveränen Clouds Azure Government und Microsoft Azure, betrieben durch 21Vianet.

Gekoppelte Regionen für die Notfallwiederherstellung

Sie können Replikate in jeder unterstützten Region erstellen, aber Sie erhalten wichtige Vorteile, wenn Sie Replikate in gekoppelten Azure Regionen auswählen, insbesondere wenn Sie für Notfallwiederherstellungszwecke entwerfen:

  • Region Recovery Sequence: In einem geografieweiten Ausfall wird die Wiederherstellung einer Region aus jedem gekoppelten Satz priorisiert. Diese Priorität stellt sicher, dass Anwendungen über gekoppelte Regionen hinweg immer eine Region haben, die für die Wiederherstellung beschleunigt wurde.

  • Sequenzielle Aktualisierung: Die Aktualisierungen der gekoppelten Regionen sind chronologisch gestaffelt, wodurch das Risiko von Ausfallzeiten aufgrund von Updateproblemen minimiert wird.

  • Datenresidenz: Mit wenigen Ausnahmen befinden sich Regionen in einem Regionenpaar in derselben Geografie, sodass sie die Anforderungen an die Datenresidenz erfüllen.

  • Leistung: Während gekoppelte Regionen in der Regel niedrige Netzwerklatenz bieten, wodurch die Barrierefreiheit und Benutzererfahrung der Daten verbessert wird, sind sie möglicherweise nicht immer die Regionen mit der absoluten niedrigsten Latenz. Wenn das primäre Ziel darin besteht, Daten näher an Benutzer zu bedienen, anstatt die Notfallwiederherstellung zu priorisieren, bewerten Sie alle verfügbaren Regionen für die Latenz. In einigen Fällen kann ein nicht gekoppelter Bereich die niedrigste Latenz aufweisen. Um ein umfassendes Verständnis zu erhalten, können Sie sich die Zahlen zur Roundtriplatenz von Azure ansehen, um eine fundierte Auswahl zu treffen.

Ein tieferes Verständnis der Vorteile von gekoppelten Regionen finden Sie in der Dokumentation von Azure zur regionsübergreifenden Replikation.

Regionale Fehler und Wiederherstellung

Azure-Einrichtungen in verschiedenen Regionen sind so konzipiert, dass sie sehr zuverlässig sind. Unter seltenen Umständen kann jedoch aufgrund von Netzwerkausfällen bis hin zu schweren Szenarien wie Naturkatastrophen eine ganze Region nicht zugänglich werden. mit den Funktionen von Azure können Sie Anwendungen erstellen, die über mehrere Regionen verteilt sind, um sicherzustellen, dass ein Fehler in einer Region keine Auswirkungen auf andere Hat.

Bereiten Sie sich auf regionale Katastrophen vor

Die Vorbereitung auf potenzielle regionale Katastrophen ist entscheidend, um den unterbrechungsfreien Betrieb Ihrer Anwendungen und Dienste sicherzustellen. Wenn Sie einen robusten Notfallplan für Ihren Azure Database for PostgreSQL flexiblen Server in Betracht ziehen, sollten Sie die folgenden wichtigen Schritte und Überlegungen berücksichtigen:

  1. Erstellen Sie ein georepliziertes Lesereplikat: Richten Sie ein Lesereplikat in einer anderen Region als Ihrer primären Region ein. Diese Einrichtung stellt die Kontinuität sicher, falls der primäre Bereich einem Ausfall gegenübersteht.
  2. Stellen Sie die Serversymmetrie sicher: Die am häufigsten empfohlene Aktion für die Behandlung regionaler Ausfälle wird auf den primären Server heraufstufen, es ist jedoch eine Serversymmetrieanforderung erforderlich. Diese Anforderung bedeutet, dass sowohl die primären als auch die Replikatserver über identische Konfigurationen bestimmter Einstellungen verfügen müssen. Zu den Vorteilen dieser Aktion gehören:
    • Wenn Sie virtuelle Endpunkte verwenden, müssen Sie keine Verbindungszeichenfolgen der Anwendung ändern.
    • Sie bietet einen nahtlosen Wiederherstellungsprozess, bei dem der ursprüngliche primäre Server seine Funktion automatisch wieder aufnimmt, aber in einer neuen Replikatrolle.
  3. Einrichten virtueller Endpunkte: Virtuelle Endpunkte ermöglichen einen reibungslosen Übergang Ihrer Anwendung zu einer anderen Region, wenn ein Ausfall auftritt. Sie vermeiden die Notwendigkeit von Änderungen an den Verbindungszeichenfolgen Ihrer Anwendung.
  4. Konfigurieren des Lesereplikats: Nicht alle Einstellungen vom primären Server werden in das Lesereplikat repliziert. Stellen Sie sicher, dass Sie alle erforderlichen Konfigurationen und Funktionen (z. B. PgBouncer) auf Ihrem Lesereplikat ordnungsgemäß einrichten. Weitere Informationen finden Sie im Abschnitt Konfigurationsverwaltung.
  5. Vorbereiten auf hohe Verfügbarkeit (HA): Wenn Ihr Setup eine hohe Verfügbarkeit erfordert, wird sie nicht automatisch für ein höhergestuftes Replikat aktiviert. Sie muss nach dem Höherstufen aktiviert werden. Erwägen Sie die Automatisierung dieses Schritts, um Ausfallzeiten zu minimieren.
  6. Regelmäßige Tests: Simulieren Sie regelmäßig regionale Notfallszenarien, um vorhandene Schwellenwerte, Ziele und Konfigurationen zu überprüfen. Stellen Sie sicher, dass Ihre Anwendung während dieser Testszenarien erwartungsgemäß reagiert.
  7. Befolgen der allgemeinen Richtlinien von Azure: Azure bietet umfassende Leitfäden zu Zuverlässigkeit und Notfallbereitschaft. Wenden Sie sich an diese Ressourcen, und integrieren Sie bewährte Methoden in Ihren Bereitschaftsplan.

Die proaktive und vorbereitende Vorbereitung auf regionale Katastrophen stellt die Resilienz und Zuverlässigkeit Ihrer Anwendungen und Daten sicher.

Wenn sich Ausfälle auf Ihre SLA auswirken

Wenn ein längerer Ausfall mit einem Azure Database for PostgreSQL flexiblen Server in einer bestimmten Region auftritt, die den Service-Level-Vertrag (SLA) Ihrer Anwendung bedroht, beachten Sie, dass beide im folgenden Abschnitt beschriebenen Aktionen nicht dienstgesteuert sind. Für beide Aktionen ist ein Benutzereingriff erforderlich. Automatisieren Sie den gesamten Prozess so weit wie möglich und verfügen über eine robuste Überwachung. Weitere Informationen dazu, welche Informationen während eines Ausfalls bereitgestellt werden, finden Sie auf der Seite Dienstunterbrechung. In einem Szenario mit einem Regionsausfall ist nur eine Höherstufung mit der Option Erzwungen möglich, sodass der Umfang der Datenverluste ungefähr der aktuellen Verzögerung zwischen Replikat- und primärem Server entspricht. Daher ist es wichtig, die Verzögerung zu überwachen. Ziehen Sie folgende Möglichkeiten in Betracht:

Höherstufen auf primären Server

Diese Option erfordert keine Aktualisierung der Verbindungszeichenfolgen in Ihrer Anwendung, sofern Sie virtuelle Endpunkte konfigurieren. Nach der Aktivierung wird der Writer-Endpunkt auf die neue primäre Instanz in einer anderen Region umgeleitet, und in der Spalte Replikationsstatus im Azure-Portal wird „Wird neu konfiguriert“ angezeigt. Sobald die betroffene Region wiederhergestellt ist, nimmt der ehemalige Primärserver den Betrieb automatisch wieder auf, nun jedoch als Replikat.

Höherstufen auf unabhängigen Server und Entfernen aus der Replikation

In einigen Fällen ist diese Option möglicherweise die einzige lebensfähige Option. Aktualisieren Sie nach der Heraufstufung des Servers die Verbindungszeichenfolgen Ihrer Anwendung. Sobald die ursprüngliche Region wiederhergestellt wurde, wird die alte primäre möglicherweise wieder aktiv. Stellen Sie sicher, dass sie entfernt wird, um unnötige Kosten zu vermeiden. Wenn Sie die vorherige Topologie beibehalten möchten, erstellen Sie das Lesereplikat neu.

Verwandte Inhalte

  • Last updated on