Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
„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.
Von Bedeutung
Der Höherstufungsvorgang erfolgt nicht automatisch. Wenn ein Fehler im Primärserver auftritt, wechselt das System nicht unabhängig zum Lesereplikat. Für den Höherstufungsvorgang ist immer eine Benutzeraktion erforderlich.
Sie können Replikate auf zwei verschiedene Arten heraufstufen:
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 müssen Sie einen virtuellen Endpunkt sowohl für den aktuellen primären als Writer-Endpunkt als auch für das Replikat konfigurieren, das für die Heraufstufung als Leserendpunkt vorgesehen ist. Die Höherstufung ist nur erfolgreich, wenn das Zielreplikat in der Endpunktkonfiguration des Lesers enthalten ist. Ein Benutzer mit der Berechtigung „Microsoft.DBforPostgreSQL/servers/write“ auf dem Quellserver kann den Switchovervorgang durchführen.
Wenn der primäre Server fehlerhafte Replikate aufweist, entfernen Sie diese Replikate, bevor Sie die Aktion „Zu primärem Server heraufstufen“ starten. Während dieses Prozesses wird das lesende Replikat zum neuen primären Server befördert. Dieser Vorgang kann zu einer kurzen Ausfallzeit von etwa 1–3 Minuten führen, abhängig von der Replikationsverzögerung zum Zeitpunkt der Promotion (bei geplanten Promotions). Nachdem die Heraufstufung abgeschlossen ist, wird der vorherige primäre Server neu konfiguriert, um als Lese-Replikat zu arbeiten.
Das folgende Diagramm zeigt die Konfiguration der Server vor der Höherstufung und den resultierenden Zustand nach erfolgreichem Abschluss des Höherstufungsvorgangs.
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. Sie können zwar virtuelle Endpunkte konfigurieren, sie sind jedoch keine Notwendigkeit für diesen Vorgang. Der neu höher gestufte Server ist nicht mehr Teil vorhandener virtueller Endpunkte, auch wenn der Leserendpunkt zuvor darauf verwiesen hat. Aktualisieren Sie die Verbindungszeichenfolge Ihrer Anwendung so, dass sie auf das neu heraufgestufte Replikat verweist, wenn die Anwendung eine Verbindung damit herstellen soll.
Das folgende Diagramm zeigt, wie die Server eingerichtet werden, bevor sie höhergestuft werden, und deren Konfiguration, nachdem sie erfolgreich unabhängige Server wurden.
Von Bedeutung
Die Aktion Höherstufen auf unabhängigen Server und das Entfernen aus der Replikation ist abwärtskompatibel mit der vorherigen Höherstufen-Funktion.
Von Bedeutung
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 der primäre Server beispielsweise 2 vCores hat und das Replikat 4 vCores hat, besteht die einzige mögliche Option darin, die Aktion „Zu eigenständigem Server heraufstufen und aus der Replikation entfernen“ zu verwenden. Darüber hinaus müssen sie für Parameter, die gemeinsamen Speicher zuweisen, dieselben Werte verwenden.
Berücksichtigen Sie für beide Heraufsufungsmethoden die folgenden Optionen:
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 heraufstufen, gibt die Verzögerung zum Zeitpunkt der Delinkung des Replikats von der primären Option an, wie viele Daten verloren gehen.
Von Bedeutung
Die Höherstufungsoption Erzwungen ist 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. Diese Priorität ist die sofortige Serververfügbarkeit zur Behandlung von Notfallszenarien. Die Verwendung der Option „Erzwungen“ außerhalb von Szenarien mit Ausfall einer Region ist jedoch nicht zulässig, wenn die in der Dokumentation angegebenen Anforderungen für Lesereplikate, insbesondere die Anforderung an die Serversymmetrie, nicht erfüllt sind, da dies zu Problemen wie einer unterbrochenen Replikation führen könnte.
Erfahren Sie, wie Sie das Lesereplikat auf das primäre Replikat umschalten und zu einem unabhängigen Server heraufstufen und aus der Replikation entfernen.
Konfigurationsverwaltung
Die Steuerebene behandelt Lesereplikate als separate Server, sodass Sie Konfigurationen unabhängig voneinander verwalten. Dieser Ansatz bietet mehr Flexibilität für Szenarien mit Leseskalierung. Wenn Sie jedoch Replikate für die Notfallwiederherstellung verwenden, müssen Sie sicherstellen, dass die Konfiguration wie gewünscht ist.
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 Sie PgBouncer für die primäre, aber nicht für das Replikat aktiviert haben, bleibt sie nach der Heraufstufung für das Replikat deaktiviert. Um PgBouncer auf dem neu heraufgestuften Server zu verwenden, müssen Sie ihn entweder vor oder nach der Heraufstufungsaktion 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. Sie können das Feature nur aktivieren, wenn Sie den Standardserver (kein Replikat) erstellen.
- Parameter: Wenn sich ihre Werte im primären und lesereplikat unterscheiden, ändern sie sich während der Heraufstufung nicht. Parameter, die die Größe des gemeinsam genutzten Speichers beeinflussen, müssen die gleichen Werte sowohl für die primären als auch für Replikate aufweisen. Diese Anforderung ist im Abschnitt "Parameter" beschrieben.
- Microsoft Entra-Authentifizierung: Wenn auf dem Primärserver die Microsoft Entra-Authentifizierung konfiguriert ist, das Replikat jedoch die PostgreSQL-Authentifizierung verwendet, wird das Replikat bei der Heraufstufung nicht automatisch auf die Microsoft Entra-Authentifizierung umgestellt. Das Replikat behält die PostgreSQL-Authentifizierung bei. Sie müssen die Microsoft Entra-Authentifizierung für das hochgestufte Replikat entweder vor oder nach der Heraufstufung manuell konfigurieren.
- High Availability (HA): Wenn Sie HA nach der Heraufstufung benötigen, müssen Sie sie auf dem frisch höhergestuften primären Server konfigurieren, nachdem Sie die Rollenumkehr ausgeführt haben.
Überlegungen
Serverzustände während der Höherstufung
Sowohl in den geplanten als auch den erzwungenen Hochstufungsszenarien müssen sich Server (sowohl primäre als auch Replikate) im Status Ready befinden. Wenn der Status eines Servers nichts anderes als "Bereit " (z. B. "Aktualisieren" oder " Neu starten") ist, kann die Heraufstufung normalerweise nicht ohne Probleme fortgesetzt werden. Im Fall von regionalen Ausfällen wird jedoch eine Ausnahme gemacht.
Während dieser regionalen Ausfälle können Sie die erzwungene Heraufstufungsmethode unabhängig vom aktuellen Status des primären Servers implementieren. Dieser Ansatz ermöglicht schnelle Maßnahmen als Reaktion auf potenzielle regionale Katastrophen unter Umgehung der normalen Überprüfungen der Serververfügbarkeit.
Wenn der frühere primäre Server während der Höherstufung des Replikats über die Wiederherstellung hinaus fehlschlägt, besteht die einzige Option 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
Wenn Sie mit mehreren Replikaten arbeiten und die primäre Region über keine gepaarte Region verfügt, sind besondere Überlegungen erforderlich. Wenn sich ein regionaler Ausfall auf das Primäre auswirkt, erkennt das neu heraufgestufte Replikat keine anderen Replikate automatisch. Sie können Anwendungen zwar weiterhin für den weiteren Betrieb an das heraufgestufte Replikat weiterleiten, die nicht erkannten Replikate bleiben während des Ausfalls jedoch getrennt. Diese zusätzlichen Replikate verbinden sich erneut und nehmen ihre Rollen erst wieder auf, sobald die ursprüngliche primäre Region wiederhergestellt ist.
Wiederherstellung zu einem bestimmten Zeitpunkt während der Hochstufung
Sowohl in den geplanten als auch in erzwungenen Werbeszenarien müssen die neuesten automatisierten Sicherungen verfügbar sein, um sicherzustellen, dass point-in-time restore (PITR)-Vorgänge erfolgreich sind. Es gibt ein bekanntes Problem, bei dem der PITR-Vorgang nach Failover- und Failbackvorgängen möglicherweise den folgenden Fehler verursacht. Dieses Problem soll in einem zukünftigen Release behoben werden. Um erfolgreiche PITR-Vorgänge bis zur neuesten Zeit sicherzustellen, warten Sie, bis die automatisierte Sicherung nach einem Promotion-Vorgang abgeschlossen ist.
Error : Point-in-time-restore of server to the period when the siteswap operation for this server was in-progress or when the server was replica is not allowed.
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 eine HA-fähige Primärinstanz und ein Lesereplikat habe, das Replikat heraufstufe und dann wieder zur ursprünglichen Primärinstanz zurückwechsle, befindet sich der Server dann noch im HA-Modus?
Nein, der Höherstufungsprozess deaktiviert HA, da Azure Database for PostgreSQL keine HA-fähigen Lesereplikate unterstützt. Die Heraufstufung einer Lesereplik zu einer primären Instanz bedeutet, dass die ursprüngliche primäre Instanz ihre Rolle in die einer Replik ändert. Wenn Sie zurückwechseln, müssen Sie auf dem ursprünglichen primären Server wieder die Hochverfügbarkeit aktivieren.