Freigeben über

Georeplikation in Azure Database for PostgreSQL – Flexibler Server

  • Artikel

GILT FÜR: Azure Database for PostgreSQL – Flexibler Server

Ein Lesereplikat kann in derselben Region wie der primäre Server oder in einer anderen geografischen Region erstellt werden. Die Georeplikation kann beispielsweise hilfreich sein, um die Notfallwiederherstellung zu planen oder Daten näher bei den Benutzern und Benutzerinnen bereitzustellen.

Sie können einen primären Server in einer beliebigen flexiblen Serverregion von Azure Database for PostgreSQL haben. Ein primärer Server kann auch über Replikate in jeder globalen Azure-Region verfügen, die den flexiblen Server Azure Database for PostgreSQL unterstützt. Darüber hinaus unterstützen wir die speziellen Regionen Azure Government und Microsoft Azure, betrieben von 21Vianet.

Regionspaare für die Notfallwiederherstellung

Während das Erstellen von Replikaten in jeder unterstützten Region möglich ist, gibt es wichtige Vorteile beim Auswählen von Replikaten in gekoppelten Regionen, insbesondere bei der Architektur für Notfallwiederherstellungszwecke:

  • Region Recovery Sequence: Bei einem geografieweiten Ausfall wird die Wiederherstellung einer Region aus jedem gekoppelten Satz priorisiert, wodurch sichergestellt wird, dass Anwendungen in gekoppelten Regionen immer eine Region für die Wiederherstellung beschleunigt haben.

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

  • Physische Isolation: Ein Mindestabstand von 300 Meilen wird zwischen Rechenzentren in gekoppelten Regionen beibehalten, wodurch das Risiko gleichzeitiger Ausfälle von signifikanten Ereignissen verringert wird.

  • Datenresidenz: Mit wenigen Ausnahmen befinden sich Regionen in einem gekoppelten Satz in derselben Geografie, die den Anforderungen an die Datenhaltung entspricht.

  • Leistung: Während gekoppelte Regionen in der Regel niedrige Netzwerklatenz bieten, die Datenbarrierefreiheit und die Benutzererfahrung verbessern, 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, ist es wichtig, alle verfügbaren Regionen für die Latenz auszuwerten. In einigen Fällen kann ein nicht gepaarter Bereich die niedrigste Latenz aufweisen. Um ein umfassendes Verständnis zu erhalten, können Sie auf die Zahlen zur Roundtriplatenz von Azure verweisen, 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. Die Azure-Funktionen ermöglichen das Erstellen von Anwendungen, die über mehrere Regionen verteilt werden, um sicherzustellen, dass ein Fehler in einer Region keine Auswirkungen auf andere hat.

Vorbereiten auf regionale Katastrophen

Die Vorbereitung auf potenzielle regionale Katastrophen ist entscheidend, um den unterbrechungsfreien Betrieb Ihrer Anwendungen und Dienste sicherzustellen. Wenn Sie einen robusten Notfallplan für Ihre flexible Serverinstanz von Azure Database for PostgreSQL in Betracht ziehen, finden Sie hier die wichtigsten Schritte und Überlegungen:

  1. Einrichten eines georeplizierten Lesereplikats: Es ist wichtig, dass ein Lesereplikat in einer separaten Region von Ihrer primären eingerichtet ist. Dadurch wird die Kontinuität sichergestellt, falls der primäre Bereich einem Ausfall gegenübersteht.
  2. Sicherstellen der Serversymmetrie: Die Aktion „Höherstufen auf primären Server“ wird am häufigsten für die Behandlung regionaler Ausfälle empfohlen, ist jedoch mit einer Serversymmetrieanforderung verbunden. Dies 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.
    • Es bietet einen nahtlosen Wiederherstellungsprozess, bei dem der ursprüngliche primäre Server seine Funktion automatisch wieder online nimmt, 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. Es ist wichtig, sicherzustellen, dass alle erforderlichen Konfigurationen und Features (z. B. PgBouncer) für Ihr Lesereplikat ordnungsgemäß eingerichtet sind. Weitere Informationen finden Sie im Abschnitt Konfigurationsverwaltung.
  5. Vorbereiten auf Hochverfügbarkeit (HA):Wenn für Ihr Setup eine hohe Verfügbarkeit erforderlich ist, 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. Es ist äußerst vorteilhaft, diese Ressourcen zu konsultieren und bewährte Methoden in Ihren Bereitschaftsplan zu integrieren.

Proaktive und vorbereitende Vorbereitung auf regionale Katastrophen stellen die Ausfallsicherheit und Zuverlässigkeit Ihrer Anwendungen und Daten sicher.

Wenn sich Ausfälle auf Ihre SLA auswirken

Beachten Sie bei einem längeren Ausfall mit Azure Database for PostgreSQL – flexibler Server in einer bestimmten Region, die die Vereinbarung zum Servicelevel Ihrer Anwendung bedroht, dass die beiden unten beschriebenen Aktionen nicht dienstorientiert sind. Es ist für beide kein Benutzereingriff erforderlich. Es ist eine bewährte Methode, den gesamten Prozess so weit wie möglich zu automatisieren und eine robuste Überwachung durchzuführen. 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. Berücksichtigen Sie die folgenden Schritte:

Höherstufen auf primären Server

Diese Option erfordert keine Aktualisierung der Verbindungszeichenfolgen in Ihrer Anwendung, sofern virtuelle Endpunkte konfiguriert sind. Nach der Aktivierung wird der Writer-Endpunkt auf den neuen primären in einer anderen Region verweisen, und die Spalte für den Replikationsstatus im Azure-Portal zeigt „Neukonfiguration“ an. Nachdem die betroffene Region wiederhergestellt wurde, wird der ehemalige primäre Server automatisch fortgesetzt, aber jetzt in einer Replikatrolle.

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

In diesem Fall ist dies die einzige geeignete Option. Nach dem Höherstufen des Servers müssen Sie die Verbindungszeichenfolgen Ihrer Anwendung aktualisieren. 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.

Zugehöriger Inhalt