Freigeben über

Höherstufen von Lesereplikaten in Azure Database for PostgreSQL – Flexibler Server

  • Artikel

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

„Höherstufen“ bezieht sich auf den Prozess, bei dem ein Replikat angehalten wird, um den Replikatmodus zu beenden und in vollständige Lese-/Schreibvorgänge zu wechseln.

Wichtig

Der Höherstufen-Vorgang erfolgt nicht automatisch. Wenn ein Primärserverfehler auftritt, wechselt das System nicht unabhängig zum Lesereplikat. Für den Höherstufungsvorgang ist immer eine Benutzeraktion erforderlich.

Die Herabufufung von Replikaten kann auf zwei unterschiedliche Weise erfolgen:

Höherstufen auf primären Server

Diese Aktion erhöht ein Replikat auf die Rolle des primären Servers. Im Prozess wird der aktuelle primäre Server zu einer Replikatrolle herabgestuft, wobei seine Rollen ausgetauscht werden. Für eine erfolgreiche Heraufstufung muss ein virtueller Endpunkt sowohl für den aktuellen primären als Writer-Endpunkt als auch für das Replikat konfiguriert werden, das für die Heraufstufung als Leseendpunkt vorgesehen ist. Die Höherstufung ist nur erfolgreich, wenn das Zielreplikat in der Endpunktkonfiguration des Lesers enthalten ist.

Die folgende Abbildung veranschaulicht die Konfiguration der Server vor der Höherstufung und den resultierenden Zustand, nachdem der Höherstufungsvorgang erfolgreich abgeschlossen wurde.

Abbildung des Höherstufens zum primären Server

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

Wenn Sie diese Option auswählen, wird das Replikat zu einem unabhängigen Server höher gestuft und aus dem Replikationsprozess entfernt. Daher funktionieren sowohl der primäre als auch der höher gestufte Server als zwei unabhängige Lese-/Schreibzugriffsserver. Es sollte beachtet werden, dass virtuelle Endpunkte zwar konfiguriert werden können, sie jedoch keine Notwendigkeit für diesen Vorgang sind. Der neu höher gestufte Server ist nicht mehr Teil vorhandener virtueller Endpunkte, auch wenn der Leserendpunkt zuvor darauf verwiesen hat. Daher ist es wichtig, die Verbindungszeichenfolge Ihrer Anwendung so zu aktualisieren, dass sie direkt zum neu höhergestuften Replikat führt, wenn die Anwendung eine Verbindung damit herstellen soll.

Das Diagramm zeigt, wie die Server eingerichtet werden, bevor sie höhergestuft werden, und deren Konfiguration, nachdem sie erfolgreich zu unabhängigen Servern geworden sind.

Abbildung der Höherstufung auf einen unabhängigen Server und der Entfernung aus der Replikation

Wichtig

Die Aktion Höherstufen auf unabhängigen Server und das Entfernen aus der Replikation ist abwärtskompatibel mit der vorherigen Höherstufen-Funktion.

Wichtig

Serversymmetrie: Für eine erfolgreiche Höherstufung mit der Höherstufung zum primären Serverbetrieb müssen sowohl die primären als auch die Replikatserver identische Ebenen und Speichergrößen aufweisen. Wenn z. B. das primäre Element 2vCores und das Replikat 4vCores aufweist, besteht die einzige praktikable Option darin, die Aktion „Höherstufen zu unabhängigem Server und Entfernen aus der Replikation“ zu verwenden. Darüber hinaus müssen sie dieselben Werte für Serverparameter verwenden, die gemeinsam genutzten Arbeitsspeicher zuweisen.

Für beide Methoden der Höherstufung gibt es weitere Optionen, die Sie berücksichtigen sollten:

  • Geplant: Mit dieser Option wird sichergestellt, dass Daten vor der Werbung synchronisiert werden. Sie wendet alle ausstehenden Protokolle an, um die Datenkonsistenz sicherzustellen, bevor Clientverbindungen akzeptiert werden.

  • Erzwungen: Diese Option ist für eine schnelle Wiederherstellung in Szenarien wie regionalen Ausfällen konzipiert. Anstatt darauf zu warten, alle Daten aus dem primären zu synchronisieren, wird der Server betriebsbereit, sobald er WAL-Dateien verarbeitet, die erforderlich sind, um den nächsten konsistenten Zustand zu erreichen. Wenn Sie das Replikat mithilfe dieser Option höher stufen, bestimmt die Verzögerung zum Zeitpunkt der Trennung des Replikats vom primären Server, wie viele Daten verloren gehen.

Wichtig

Die Höherstufungsoption Erzwungen ist speziell darauf ausgelegt, regionale Ausfälle zu behandeln. In solchen Fällen werden alle Prüfungen übersprungen – einschließlich der Serversymmetrieanforderung – und direkt mit der Höherstufung fortgefahren. Dies liegt daran, dass die sofortige Serververfügbarkeit gegenüber der Behandlung von Notfallszenarien priorisiert wird. Die Verwendung der Option „Erzwungen“ außerhalb von regionalen Ausfallszenarien ist jedoch nicht zulässig, wenn die in der Dokumentation angegebenen Anforderungen für Lesereplikate – insbesondere die Serversymmetrieanforderung – nicht erfüllt sind, da dies zu Problemen wie Replikationsfehlern führen kann.

Erfahren Sie, wie Sie Replikate auf Primär höherstufen und auf unabhängigen Server höherstufen und aus der Replikation entfernen.

Konfigurationsverwaltung

Lesereplikate werden als separate Server in Bezug auf Steuerungsebenenkonfigurationen behandelt. Dieser Ansatz bietet mehr Flexibilität für Szenarien mit Leseskalierung. Bei der Verwendung von Replikaten für Notfallwiederherstellungszwecke müssen Benutzer jedoch sicherstellen, dass die Konfiguration den Vorstellungen entspricht.

Der Höherstufungsvorgang übernimmt keine bestimmten Konfigurationen und Parameter. In Folgenden werden einige der wichtigsten aufgeführt:

  • PgBouncer: Die Einstellungen und Status des integrierten PgBouncer-Verbindungspoolings werden während der Höherstufung nicht repliziert. Wenn PgBouncer auf dem Primär, aber nicht für das Replikat aktiviert wurde, bleibt es nach der Höherstufung für das Replikat deaktiviert. Wenn Sie PgBouncer auf dem neu höhergestuften Server verwenden möchten, müssen Sie ihn entweder vor oder nach der Aktion zur Höherstufung aktivieren.
  • Georedundanter Sicherungsspeicher: Geo-Backup-Einstellungen werden nicht übertragen. Da Replikate keine Geosicherung aktiviert haben können, verfügt die höhergestufte primäre (vormals Replikat) nicht über sie nach der Höherstufung. Das Feature kann nur zur Erstellungszeit des Standardservers (kein Replikat) aktiviert werden.
  • Serverparameter: Wenn sich ihre Werte im primären und Lesereplikat unterscheiden, werden sie während der Höherstufung nicht geändert. Es ist wichtig zu beachten, dass Parameter, die die Größe des gemeinsam genutzten Speichers beeinflussen, dieselben Werte sowohl für den primären als auch für Replikate aufweisen müssen. Diese Anforderung ist im Abschnitt Serverparameter beschrieben.
  • Microsoft Entra-Authentifizierung: Wenn das primäre die Microsoft Entra-Authentifizierung konfiguriert hat, das Replikat jedoch mit der PostgreSQL-Authentifizierung eingerichtet wurde, wechselt das Replikat nach der Höherstufung nicht automatisch zur Microsoft Entra-Authentifizierung. Sie behält die PostgreSQL-Authentifizierung bei. Benutzer müssen die Microsoft Entra-Authentifizierung für das höhergestufte Replikat entweder vor oder nach dem höhergestuften Prozess manuell konfigurieren.
  • Hohe Verfügbarkeit (HA): Wenn Sie nach der Höherstufung Hochverfügbarkeit benötigen, muss sie auf dem frisch höhergestuften primären Server nach der Rollenumkehr konfiguriert werden.

Überlegungen

Serverzustände während der Höherstufung

In den Höherstufungsszenarien „Geplant“ und „Erzwungen“ ist es erforderlich, dass die Server (sowohl der primäre als auch der Replikatserver) den Zustand „Verfügbar“ aufweisen. Wenn der Serverzustand nichts „Verfügbar“ lautet (sondern z. B. „Wird aktualisiert“ oder „Wird neu gestartet“), kann die Höherstufung in der Regel nicht ohne Probleme fortgesetzt werden. Im Fall von regionalen Ausfällen wird jedoch eine Ausnahme gemacht.

Bei solchen regionalen Ausfällen kann die Höherstufungsmethode „Erzwungen“ unabhängig vom aktuellen Zustand des primären Servers implementiert werden. Dieser Ansatz ermöglicht schnelle Maßnahmen als Reaktion auf potenzielle regionale Katastrophen unter Umgehung der normalen Überprüfungen der Serververfügbarkeit.

Beachten Sie, dass, wenn der frühere primäre Server während der Höherstufung des Replikats über die Wiederherstellung hinaus fehlschlägt, die einzige Option besteht darin, den ehemaligen primären Server zu löschen und den Replikatserver neu zu erstellen.

Sichtbarkeit mehrerer Replikate während der Höherstufung in nicht gepaarten Bereichen

Beim Umgang mit mehreren Replikaten und wenn der primäre Bereich keinen gepaarten Bereich hat, muss das besonders berücksichtigt werden. Im Fall eines regionalen Ausfalls, der sich auf den primären Server auswirkt, werden die anderen Replikate nicht automatisch vom neu höher gestuften Replikat erkannt. Während Anwendungen weiterhin an das höhergestufte Replikat weitergeleitet werden können, bleiben die nicht erkannten Replikate während des Ausfalls getrennt. Diese zusätzlichen Replikate werden erst nach dem Wiederherstellen der ursprünglichen primären Region erneut ihren Rollen zugeordnet und fortgesetzt.

Häufig gestellte Fragen

  • Kann ich ein Replikat höher stufen, wenn mein primärer Server eine hohe Verfügbarkeit (HA) aktiviert hat?

    Ja, unabhängig davon, ob auf dem primären Server HA-aktiviert ist oder nicht, können Sie das Lesereplikat höher stufen. Die Möglichkeit zum Höherstufen eines Lesereplikats auf einen primären Server ist unabhängig von der HA-Konfiguration des primären Servers.

  • Wenn ich über einen primären Server mit aktivierter Hochverfügbarkeit und ein Lesereplikat verfüge, das Replikat höher stufe und dann zurück auf den ursprünglichen primären Server umstelle, bietet der Server dann weiterhin Hochverfügbarkeit?

    Nein, Hochverfügbarkeit wird während der ersten Höherstufung deaktiviert, da Lesereplikate mit Hochverfügbarkeit nicht unterstützt werden. Das Höherstufen eines Lesereplikats auf einen primären Server bedeutet, dass der ursprüngliche primäre Server eine neue Rolle als Replikat einnimmt. Wenn Sie zurückwechseln, müssen Sie auf dem ursprünglichen primären Server wieder die Hochverfügbarkeit aktivieren.

Zugehöriger Inhalt