Freigeben über

Lesereplikate in Azure Database for PostgreSQL: flexibler Server

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

Mit der Funktion Lesereplikat können Sie Daten von einer Azure Database for PostgreSQL flexible Serverinstanz auf ein schreibgeschütztes Replikat replizieren. Replikate werden asynchron mithilfe der nativen physischen Replikationstechnologie der PostgreSQL-Engine aktualisiert. Die Streamingreplikation anhand von Replikationsslots ist der Standardbetriebsmodus. Bei Bedarf wird der dateibasierte Protokollversand verwendet, um aufzuholen. Sie können vom primären Server auf bis zu fünf Replikate replizieren.

Replikate sind neue Server, die Sie ähnlich wie die regulären flexiblen Serverinstanzen von Azure Database for PostgreSQL verwalten. Für jedes Lesereplikat werden Ihnen die bereitgestellten Computeressourcen in Form von virtuellen Kernen sowie der Speicher in GB/Monat in Rechnung gestellt.

Erfahren Sie, wie Sie ein Lesereplikat erstellen.

Einsatzmöglichkeiten von Lesereplikaten

Das Feature für Lesereplikate kann die Leistung und Skalierung von leseintensiven Workloads verbessern. Leseworkloads können in den Replikaten isoliert werden, während Schreibworkloads an den primären Server weitergeleitet werden können. Lesereplikate können auch in einer anderen Region bereitgestellt werden. Außerdem können sie zu einem Lese-/Schreibserver hochgestuft werden, wenn eine Notfallwiederherstellung notwendig ist.

In einem typisch anzutreffenden Szenario verwenden BI- und Analyseworkloads das Lesereplikat als Datenquelle für die Berichterstellung.

Da Replikate schreibgeschützt sind, führen sie nicht direkt zu einer verringerten Auslastung der Schreibkapazität auf dem primären Server.

Überlegungen

Lesereplikate sind in erster Linie für Szenarien konzipiert, in denen das Auslagern von Abfragen von Vorteil ist und eine geringe Verzögerung akzeptiert werden kann. Sie sind so optimiert, dass sie für die meisten Workloads Aktualisierungen nahezu in Echtzeit von der primären Festplatte bereitstellen, was sie zu einer ausgezeichneten Lösung für leseintensive Szenarien macht. Es muss jedoch beachtet werden, dass sie nicht für Szenarien mit synchroner Replikation vorgesehen sind, die eine Genauigkeit der Daten auf die Minute erfordern. Während die Daten des Replikats schließlich mit dem primären Server übereinstimmen, könnte es eine Verzögerung geben, die in der Regel von einigen Sekunden bis zu Minuten reicht und in einigen Szenarien mit großer Workload oder hoher Latenz mehrere Stunden umfassen kann. In der Regel haben Lesereplikate in derselben Region wie die primäre Replik weniger Verzögerung als Georeplikate, da letztere oft mit geografisch bedingter Latenz zu kämpfen haben. Weitere Einblicke in die Leistungsauswirkungen der Georeplikation finden Sie im Artikel zur Georeplikation. Letztendlich sind die Daten auf dem Replikat mit den Daten auf dem primären Server konsistent. Verwenden Sie das Feature für Workloads, für die diese Verzögerung akzeptabel ist.

Hinweis

Bei den meisten Workloads stellen Lesereplikate Aktualisierungen vom primären Server nahezu in Echtzeit bereit. Bei persistenten, sehr schreibintensiven primären Workloads kann die Verzögerung der Replikation jedoch immer weiter anwachsen, bis der Stand des primären Servers möglicherweise gar nicht mehr erreicht werden kann. Dadurch kann auch die Speicherauslastung auf dem primären Server ansteigen, weil die WAL-Dateien nur gelöscht werden, sobald sie im Replikat empfangen wurden. Wenn diese Situation weiterhin andauert, können Sie das Replikat löschen und neu erstellen, nachdem die schreibintensiven Workloads abgeschlossen wurden, das Replikat wieder in einen guten Zustand zurückversetzt werden. Asynchrone Lesereplikate eignen sich nicht für solche schreibintensiven Workloads. Wenn Sie Lesereplikate für Ihre Anwendung evaluieren, überwachen Sie die Verzögerung im Replikat über einen vollständigen Workloadzyklus der App innerhalb und außerhalb von Spitzenzeiten, um die mögliche Verzögerung und die erwartete RTO/RPO an verschiedenen Punkten des Workloadzyklus zu ermitteln.

Erstellen eines Replikats

Ein primärer Server für Azure Database for PostgreSQL – Flexibler Server kann in jeder Region bereitgestellt werden, die den Dienst unterstützt. Sie können Replikate des primären Servers innerhalb derselben Region oder in verschiedenen globalen Azure-Regionen erstellen, in denen Azure Database for PostgreSQL – Flexibler Server verfügbar ist. Die Möglichkeit zum Erstellen von Replikaten erstreckt sich jetzt auf einige spezielle Azure-Regionen. Im Artikel Georeplikation finden Sie eine Liste mit speziellen Regionen, in denen Sie Replikate erstellen können.

Wenn Sie den Workflow „Replikat erstellen“ starten, wird eine leere Instanz von Azure Database for PostgreSQL – Flexibler Server erstellt. Der neue Server wird mit den Daten gefüllt, die auf dem primären Server vorhanden sind. Für die Erstellung von Replikaten in derselben Region wird der Ansatz einer Momentaufnahme verwendet. Daher ist die Erstellungszeit unabhängig von der Größe der Daten. Da Georeplikate unter Verwendung einer Basissicherung der primären Instanz erstellt werden, die dann über das Netz übertragen wird, kann die Erstellungszeit je nach Größe der primären Instanz zwischen Minuten und mehreren Stunden liegen.

Ein Replikat gilt nur dann als erfolgreich erstellt, wenn zwei Bedingungen erfüllt sind: Die gesamte Sicherung der primären Instanz ist auf das Replikat kopiert worden, und die Transaktionsprotokolle sind mit einer Verzögerung von nicht mehr als 1 GB synchronisiert worden.

Um einen erfolgreichen Erstellungsvorgang zu erzielen, vermeiden Sie Replikate in Zeiten hoher Transaktionslast. Sie sollten beispielsweise das Erstellen von Replikaten bei Migrationen von anderen Quellen zu Azure Database for PostgreSQL – Flexibler Server oder bei übermäßigen Massenladevorgängen vermeiden. Wenn Sie Daten migrieren oder gerade große Datenmengen laden, ist es am besten, diese Aufgabe zuerst abzuschließen. Nach Abschluss dieser Aufgabe können Sie mit der Einrichtung der Replikate beginnen. Überprüfen Sie nach Abschluss des Migrations- oder Massenladevorgangs, ob die Transaktionsprotokollgröße wieder ihre normale Größe hat. In der Regel sollte die Transaktionsprotokollgröße in der Nähe des Werts liegen, der im max_wal_size-Serverparameter für Ihre Instanz definiert ist. Sie können den Speicherbedarf des Transaktionsprotokollspeichers mithilfe der Metrik Transaktionsprotokollspeicher verwendet nachverfolgen, die Einblicke in die Menge des vom Transaktionsprotokoll verwendeten Speichers bietet. Durch die Überwachung dieser Metrik können Sie sicherstellen, dass die Transaktionsprotokollgröße innerhalb des erwarteten Bereichs liegt und dass der Erstellungsprozess des Replikats gestartet werden kann.

Wichtig

Lesereplikate werden derzeit für die Computeebenen „Universell“ und „Arbeitsspeicheroptimiert“ unterstützt. Die Servercomputeebene „Burstfähig“ wird nicht unterstützt.

Wichtig

Beim Erstellen, Löschen und Höherstufen von Replikaten wechselt der primäre Server in den Status Wird aktualisiert. Während dieser Zeit werden Serververwaltungsvorgänge wie das Ändern von Serverparametern, das Ändern von Hochverfügbarkeitsoptionen oder das Hinzufügen oder Entfernen von Firewalls nicht verfügbar sein. Es ist wichtig zu beachten, dass sich der Status „Wird aktualisiert“ nur auf Serververwaltungsvorgänge auswirkt und nicht auf Vorgänge auf Datenebene. Dies bedeutet, dass Ihr Datenbankserver weiterhin voll funktionsfähig bleibt und Verbindungen akzeptieren und Lese- und Schreibdatenverkehr verarbeiten kann.

Erfahren Sie, wie Sie ein Lesereplikat erstellen.

Konfigurationsverwaltung

Beim Einrichten von Lesereplikaten für Azure Database for PostgreSQL – Flexibler Server ist es wichtig, die Serverkonfigurationen zu verstehen, die angepasst werden können, welche vom Primärserver übernommen werden und welche Einschränkungen damit verbunden sind.

Geerbte Konfigurationen

Wenn ein Lesereplikat erstellt wird, erbt es bestimmte Serverkonfigurationen vom primären Server. Diese Konfigurationen können entweder während der Erstellung des Replikats oder nach der Einrichtung geändert werden. Bestimmte Einstellungen, z. B. Geosicherung, werden jedoch nicht in das Lesereplikat repliziert.

Konfigurationen während der Replikaterstellung

  • Ebene, Speichergröße: Für den Vorgang „Höherstufen auf primären Server“ muss sie mit dem primären Server identisch sein. Für den Vorgang „Höherstufen auf unabhängigen Server und Entfernen aus der Replikation“ kann sie identisch oder höher sein als der primäre Server.
  • Leistungsstufe (IOPS): Anpassbar.
  • Datenverschlüsselung: Anpassbar, umfasst den Wechsel von dienstverwalteten Schlüsseln zu kundenseitig verwalteten Schlüsseln.

Konfigurationen nach der Erstellung

  • Firewallregeln: Können hinzugefügt, gelöscht oder geändert werden.
  • Ebene, Speichergröße: Für den Vorgang „Höherstufen auf primären Server“ muss sie mit dem primären Server identisch sein. Für den Vorgang „Höherstufen auf unabhängigen Server und Entfernen aus der Replikation“ kann sie identisch oder höher sein als der primäre Server.
  • Leistungsstufe (IOPS): Anpassbar.
  • Authentifizierungsmethode: Anpassbar, Optionen umfassen den Wechsel von der PostgreSQL-Authentifizierung zu Microsoft Entra.
  • Serverparameter: Die meisten sind anpassbar. Diejenigen, die sich auf die Größe des gemeinsamen Speichers auswirken, sollten jedoch mit dem primären Speicher übereinstimmen, insbesondere für potenzielle Szenarien, in denen der Server „zum primären Server hochgestuft“ wird. Für den Vorgang „Höherstufen auf unabhängigen Server und Entfernen aus der Replikation“ sollten diese Parameter identisch sein oder die für den primären Server überschreiten.
  • Wartungszeitplan: Anpassbar.

Nicht unterstützte Features für Lesereplikate

Bestimmte Funktionen sind auf primäre Server beschränkt und können nicht für Lesereplikate eingerichtet werden. Dazu gehören:

  • Sicherungen, einschließlich Geosicherungen.
  • Hochverfügbarkeit

Wenn Ihre Instanz von Azure Database for PostgreSQL – Flexibler Server mit kundenseitig verwalteten Schlüsseln verschlüsselt ist, finden Sie weitere Überlegungen in der Dokumentation.

Herstellen einer Verbindung mit einem Replikat

Wenn Sie ein Replikat erstellen, erbt dieses die Firewallregeln oder den VNET-Dienstendpunkt des primären Servers. Diese Regeln können während der Replikaterstellung und zu einem späteren Zeitpunkt geändert werden.

Das Replikat erbt das Admin-Konto vom primären Server. Alle Benutzerkonten auf dem primären Server werden auf die Lesereplikate repliziert. Sie können nur mit denjenigen Benutzerkonten eine Verbindung mit einem Lesereplikat herstellen, die auf dem primären Server verfügbar sind.

Es gibt zwei Methoden zum Herstellen einer Verbindung mit dem Replikat:

  • Direkt mit der Replika-Instanz: Sie können sich mit dem Replikat unter Verwendung seines Hostnamens und eines gültigen Benutzerkontos verbinden, wie Sie es bei einer regulären Azure Database for PostgreSQL flexible Serverinstanz tun würden. Bei einem Server namens myreplica mit dem Admin-Benutzernamen myadmin können Sie eine Verbindung mit dem Replikat herstellen über psql:
psql -h myreplica.postgres.database.azure.com -U myadmin postgres

Geben Sie an der Eingabeaufforderung das Kennwort für das Benutzerkonto ein.

Um den Verbindungsprozess zu vereinfachen, bietet das Azure-Portal zudem sofort einsatzbereite Verbindungszeichenfolgen. Diese finden Sie auf der Seite Verbinden. Sie umfassen sowohl libpq-Variablen als auch Verbindungszeichenfolgen, die auf Bash-Konsolen zugeschnitten sind.

  • Über virtuelle Endpunkte: Es gibt eine alternative Verbindungsmethode mithilfe von virtuellen Endpunkten, wie im Artikel Virtuelle Endpunkte beschrieben. Mithilfe virtueller Endpunkte können Sie den schreibgeschützten Endpunkt so konfigurieren, dass er konsistent auf das Replikat verweist, unabhängig davon, welcher Server derzeit die Replikatrolle enthält.

Überwachen der Replikation

Das Feature für Lesereplikate auf Azure Database for PostgreSQL – Flexibler Server beruht auf Replikationsslots. Der Hauptvorteil von Replikationsslots besteht darin, dass sie die Anzahl der von allen Replikationsservern benötigten Transaktionsprotokolle (WAL-Segmente) automatisch anpassen. Auf diese Weise wird verhindert, dass die Replikate nicht mehr synchron sind, da das Löschen von WAL-Segmenten auf dem Primärsystem vermieden wird, bevor sie an die Replikate gesendet werden. Der Nachteil dieses Ansatzes ist, dass der Speicherplatz auf dem primären Server knapp werden kann, wenn ein Replikationsslot längere Zeit inaktiv bleibt. In solchen Situationen sammeln sich auf dem primären Server WAL-Dateien an, was zu einer inkrementellen Zunahme der Speichernutzung führt. Wenn die Speichernutzung 95 % erreicht oder die verfügbare Kapazität weniger als 5 GiB beträgt, wird der Server automatisch in den schreibgeschützten Modus umgeschaltet, um Fehler im Zusammenhang mit vollen Datenträgern zu vermeiden.
Die Überwachung der Replikationsverzögerung und des Status der Replikationsslots ist daher für Lesereplikate von entscheidender Bedeutung.

Wir empfehlen, Warnungsregeln für die Speichernutzung oder den belegten Speicherplatz in Prozent sowie für Replikationsverzögerungen einzurichten. So werden Sie beim Überschreiten bestimmter Schwellenwerte benachrichtigt und können proaktiv handeln, indem Sie die Speichergröße erhöhen und Lesereplikate mit großer Verzögerung löschen. Sie können beispielsweise eine Warnung einstellen, wenn der Prozentsatz der Speichernutzung 80 % übersteigt und wenn die Verzögerung bei der Replikation mehr als 5 Minuten beträgt. Die Metrik Verwendeter Transaktionsprotokollspeicher zeigt an, ob die Ansammlung von WAL-Dateien der Hauptgrund für die übermäßige Speichernutzung ist.

Überwachen von Metriken

Azure Database for PostgreSQL flexible Server stellt die folgenden Metriken für die Überwachung der Replikation bereit.

Sie können erweiterte Metriken für die Überwachung und Warnung bei der Lesereplikation verwenden.

Aktivieren von erweiterten Metriken

  • Die meisten dieser neuen Metriken sind standardmäßig deaktiviert. Es gibt jedoch einige Ausnahmen, die standardmäßig aktiviert sind. In der Spalte ganz rechts in den folgenden Tabellen ist angegeben, ob die Metriken standardmäßig aktiviert sind.
  • Um die Metriken zu aktivieren, die standardmäßig nicht aktiviert sind, legen Sie den Serverparameter metrics.collector_database_activity auf ON fest. Dieser Parameter ist dynamisch und erfordert keinen Neustart der Instanz.
Logische Replikation
Anzeigename Metrik-ID Einheit BESCHREIBUNG Abmessung Standardmäßig aktiviert
Maximale logische Replikationsverzögerung logical_replication_delay_in_bytes Byte-Einheiten Die maximale Verzögerung in allen logischen Replikationsslots. Nicht zutreffend Ja
Replikation
Anzeigename Metrik-ID Einheit BESCHREIBUNG Abmessung Standardmäßig aktiviert
Maximale physische Replikationsverzögerung physical_replication_delay_in_bytes Byte-Einheiten Die maximale Verzögerung in allen asynchronen physischen Replikationsslots. Nicht zutreffend Ja
Lesereplikationsverzögerung physical_replication_delay_in_seconds Sekunden Die Verzögerung beim Lesen von Replikaten in Sekunden. Nicht zutreffend Ja

Weitere Informationen finden Sie im Anleitungsartikel zu Lesereplikaten.

Die Metrik Maximale Verzögerung physischer Replikationen zeigt die Verzögerung in Byte zwischen dem primären Server und dem Replikat mit der größten Verzögerung. Diese Metrik ist ausschließlich auf dem primären Server verfügbar und nur dann anwendbar, wenn mindestens eines der Lesereplikate mit dem primären Server verbunden ist. Die Verzögerungsinformationen sind auch verfügbar, wenn das Replikat derzeit einen Rückstand gegenüber dem Primärsystem aufholt, während ein Replikat erstellt wird oder die Replikation deaktiviert wird.

Die Metrik Lesereplikatverzögerung zeigt an, wie viel Zeit seit der letzten wiedergegebenen Transaktion vergangen ist. Wenn beispielsweise auf Ihrem primären Server keine Transaktionen ausgeführt werden und die letzte Transaktion vor 5 Sekunden wiedergegeben wurde, zeigt die Lesereplikatverzögerung eine Verzögerung von 5 Sekunden an. Diese Metrik ist nur für Replikate verfügbar und auf diese anwendbar.

Richten Sie eine Benachrichtigung ein, die Sie informiert, wenn die Replikatverzögerung einen für Ihre Workload nicht akzeptablen Wert erreicht.

Um weitere Erkenntnisse zu erhalten, können Sie die Replikationsverzögerung für alle Replikate direkt vom primären Server abfragen.

Hinweis

Wenn ein primärer Server oder ein Lesereplikat neu gestartet wird, spiegelt die Metrik „Replikatverzögerung“ die benötigte Zeit zum Neustarten und anschließenden Aufholen wider.

Replikationsstatus

Informationen zum Überwachen des Status und des Status der Replikation und zum Höherstufen des Vorgangs finden Sie in der Spalte Replikationsstatus im Azure-Portal. Diese Spalte befindet sich auf der Replikationsseite und zeigt verschiedene Zustände an, die Aufschluss über den aktuellen Status der Lesereplikate und deren Verbindung zum Primärreplik geben. Für Benutzende, die sich auf die Azure Resource Manager-API verlassen, wird der Status beim Aufrufen der GetReplica-API in der Eigenschaftensammlung replica als ReplicationState angezeigt.

Die folgenden Werte sind möglich:

Replikationsstatus Beschreibung Reihenfolge höher stufen Lesen der Replikaterstellungsreihenfolge
Neukonfiguration Warten auf den Start der primären Replikatverbindung. Es kann länger dauern, wenn das Replikat oder seine Region aufgrund eines Notfalls nicht verfügbar ist. 1 n/v
Bereitstellung Das Lesereplikat wird bereitgestellt und die Replikation zwischen den beiden Servern muss noch gestartet werden. Bis die Bereitstellung abgeschlossen ist, können Sie keine Verbindung mit dem Lesereplikat herstellen. n/v 1
Wird aktualisiert Die Serverkonfiguration wird nach einer ausgelösten Aktion wie Höherstufen oder Lesereplikaterstellung vorbereitet. 2 2
Aufholen WAL-Dateien werden auf das Replikat angewendet. Die Dauer für diese Phase während der Höherstufung hängt von der ausgewählten Datensynchronisierungsoption ab – geplant oder erzwungen. 3 3
Aktiv Fehlerfreier Zustand, der angibt, dass das Lesereplikat erfolgreich mit der primären Verbindung verbunden wurde. Wenn die Server beendet, aber zuvor erfolgreich verbunden wurden, bleibt der Status „aktiv“. 4 4
Fehlerhaft Fehlerhafter Zustand, der angibt, dass der Höherstufen-Vorgang fehlgeschlagen ist, oder dass das Replikat aus irgendeinem Grund keine Verbindung mit dem primären Replikat herstellen kann. Verwerfen Sie das Replikat, und erstellen Sie das Replikat neu, um dies zu beheben.“ n/v n/v

Erfahren Sie, wie Sie die Replikation überwachen.

Überlegungen

In diesem Abschnitt werden Aspekte des Features für Lesereplikate zusammengefasst. Es gelten die folgenden Überlegungen.

  • Energievorgänge: Energievorgänge, einschließlich Start- und Stoppaktionen, können sowohl auf den primären Server als auch auf die zugehörigen Replikatserver angewendet werden. Um die Systemintegrität zu erhalten, sollte jedoch eine bestimmte Sequenz befolgt werden. Stellen Sie vor dem Beenden der Lesereplikate sicher, dass der primäre Server zuerst beendet wird. Initiieren Sie beim Starten von Vorgängen die Startaktion auf den Replikatservern, bevor Sie den primären Server starten.
  • Wenn der Server Lesereplikate enthält, sollten die Lesereplikate zuerst gelöscht werden, bevor der primäre Server gelöscht wird.
  • Ein direktes Hauptversions-Upgrade in Azure Database for PostgreSQL – Flexibler Server erfordert das Entfernen aller derzeit auf dem Server aktivierten Lesereplikate. Sobald die Replikate gelöscht wurden, kann für den primären Server ein Upgrade auf die gewünschte Hauptversion durchgeführt werden. Nach Abschluss des Upgrades können Sie die Replikate neu erstellen, um den Replikationsprozess fortzusetzen.
  • SSD Premium v2: Ab der aktuellen Version wird die Erstellung von Lesereplikaten nicht unterstützt, wenn der primäre Server SSD Premium v2 für den Speicher verwendet.
  • Zurücksetzen des Admin-Kennworts: Das Zurücksetzen des Admin-Kennworts auf dem Replikationsserver wird derzeit nicht unterstützt. Darüber hinaus wird das Aktualisieren des Admin-Kennworts zusammen mit dem Höherstufen des Replikat-Vorgangs in derselben Anforderung ebenfalls nicht unterstützt. Wenn Sie dies tun möchten, müssen Sie zunächst den Replikationsserver verschieben und dann das Kennwort auf dem neu verschobenen Server separat aktualisieren.

Neue Replikate

Ein Lesereplikat wird als neue Instanz von Azure Database for PostgreSQL – Flexibler Server erstellt. Ein vorhandener Server kann nicht in ein Replikat umgewandelt werden. Sie können kein Replikat eines anderen Lesereplikats erstellen, d. h., kaskadierende Replikation wird nicht unterstützt.

Ressourcenverschiebung

Benutzende können Lesereplikate in einer anderen Ressourcengruppe als der primären erstellen. Das Verschieben von Lesereplikaten in eine andere Ressourcengruppe nach deren Erstellung wird jedoch nicht unterstützt. Auch das Verschieben von Replikaten in ein anderes Abonnement und das Verschieben des primären Replikats, das Lesereplikaten enthält, in eine andere Ressourcengruppe oder ein anderes Abonnement wird nicht unterstützt.

Automatische Speichervergrößerung

Bei der Konfiguration von Lesereplikaten für eine Instanz von Azure Database for PostgreSQL – Flexibler Server müssen Sie unbedingt sicherstellen, dass die Einstellung für die automatische Erweiterung des Speichers auf den Replikaten mit der des Primärservers übereinstimmt. Mit der Funktion zur automatischen Speichererweiterung kann der Speicherplatz der Datenbank automatisch vergrößert werden, um zu verhindern, dass der Speicherplatz knapp wird und es zu Datenbankausfällen kommt. Hier erfahren Sie, wie Sie die Einstellungen für die automatische Speichererweiterung effektiv verwalten können:

  • Sie können die automatische Speichererweiterung auf jedem Replikat aktivieren, unabhängig von der Einstellung auf dem Primärserver.
  • Wenn die automatische Speichererweiterung auf dem Primärserver aktiviert ist, muss sie auch auf den Replikaten aktiviert sein, um ein konsistentes Verhalten bei der Speicherskalierung zu gewährleisten.
  • Um die automatische Speichererweiterung auf dem Primärserver zu aktivieren, müssen Sie sie zunächst auf den Replikaten aktivieren. Diese Reihenfolge der Vorgänge ist für die Integrität der Replikation entscheidend.
  • Wenn Sie hingegen die automatische Speichererweiterung deaktivieren möchten, deaktivieren Sie sie zunächst auf dem Primärserver und dann auf den Replikaten, um Komplikationen bei der Replikation zu vermeiden.

Sichern und Wiederherstellen

Beim Verwalten von Sicherungen und Wiederherstellungen für Ihre Instanz von Azure Database for PostgreSQL – Flexibler Server ist es wichtig, die aktuelle und vorherige Rolle des Servers in verschiedenen Höherstufungszenarien zu berücksichtigen. Hier sind wichtige Punkte, die Sie beachten sollten:

Höherstufen auf primären Server

  1. Es werden keine Backups aus Lesereplikaten übernommen: Sicherungen werden niemals von Lesereplikatservern übernommen, unabhängig von ihrer früheren Rolle.

  2. Beibehaltung früherer Backups: Wenn ein Server einmal ein primärer Server war und Sicherungen während dieses Zeitraums übernommen hat, werden diese Sicherungen beibehalten. Sie werden bis zum benutzerdefinierten Aufbewahrungszeitraum aufbewahrt.

  3. Vorgangseinschränkungen wiederherstellen: Auch wenn frühere Backups für einen Server vorhanden sind, der zu einem Lesereplikat übergegangen ist, sind Wiederherstellungsvorgänge eingeschränkt. Sie können einen Wiederherstellungsvorgang nur initiieren, wenn der Server wieder zur primären Rolle höhergestuft wurde.

Aus Gründen der Übersichtlichkeit sehen Sie hier eine Tabelle mit den folgenden Punkten:

Serverrolle Backup erstellt Wiederherstellen zulässig
Primär Ja Ja
Lesereplikat Nein Nein
Lesereplikat auf primäres Replikat höhergestuft Ja Ja

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

Während der Server ein Lesereplikat ist, werden keine Backups erstellt. Sobald er jedoch zu einem unabhängigen Server höhergestuft wurde, werden sowohl für den höhergestuften Server als auch für den primäre Servern Backups erstellt, und Wiederherstellungen sind auf beiden zulässig.

Netzwerk

Lesereplikate unterstützen alle Netztechnologieoptionen, die von Azure Database for PostgreSQL – Flexibler Server unterstützt werden.

Wichtig

Bidirektionale Kommunikation zwischen dem primären Server und Lesereplikaten ist für die Einrichtung von Azure Database for PostgreSQL –Flexibler Server entscheidend. Es muss eine Bereitstellung zum Senden und Empfangen von Datenverkehr am Zielport 5432 innerhalb des virtuellen Azure-Netzwerksubnetz vorhanden sein.

Die oben genannte Anforderung unterstützt nicht nur den Synchronisierungsprozess, sondern stellt auch für ein ordnungsgemäßes Funktionieren des Mechanismus zum Höherstufen sicher, bei dem Replikate möglicherweise in umgekehrter Reihenfolge kommunizieren müssen – von Replikat zu Primärserver –, insbesondere während dem Höherstufen zum primären Betrieb. Darüber hinaus müssen Verbindungen mit dem Azure-Speicherkonto, in dem Write-Ahead Logging (WAL)-Archive gespeichert sind, zugelassen sein, um die Datenbeständigkeit zu gewährleisten und effiziente Wiederherstellungsprozesse zu ermöglichen.

Weitere Informationen zum Konfigurieren des privaten Zugriffs (Virtual Network-Integration) für Ihre Lesereplikate und zum Verständnis der Auswirkungen für die Replikation in Azure-Regionen und virtuellen Netzwerken innerhalb eines privaten Netzwerkkontexts finden Sie auf der Seite Replikation zwischen Azure-Regionen und virtuellen Netzwerken mit privatem Netzwerk.

Risikominderung bei Replikationsslotproblemen

In seltenen Fällen kann eine große Verzögerung, die durch Replikationsslots verursacht wird, aufgrund der Ansammlung von WAL-Dateien zu einem Anstieg der Speicherauslastung auf dem primären Server führen. Wenn die Speichernutzung 95 % erreicht oder die verfügbare Kapazität unter 5 GiB fällt, schaltet der Server automatisch in den schreibgeschützten Modus, um Fehler durch volle Datenträger zu vermeiden.

Da die Aufrechterhaltung des Zustands und der Funktionalität des primären Servers Priorität hat, kann in solchen Grenzfällen der Replikationsslot entfallen, um sicherzustellen, dass der primäre Server für den Datenverkehr betriebsbereit bleibt. Infolgedessen wechselt die Replikation in den dateibasierten Protokollversandmodus, was zu einer höheren Replikationsverzögerung führen kann.

Es ist wichtig, die Speicherauslastung und die Replikationsverzögerung genau zu überwachen und die notwendigen Maßnahmen zu ergreifen, um potenzielle Probleme zu entschärfen, bevor sie eskalieren.

Serverparameter

Wenn ein Leseabbild erstellt wird, erbt es die Serverparameter vom Primärserver. Damit soll ein konsistenter und zuverlässiger Ausgangspunkt gewährleistet werden. Allerdings werden Änderungen an den Serverparametern auf dem Primärserver, die nach der Erstellung der Lesereplika vorgenommen werden, nicht automatisch repliziert. Dieses Verhalten bietet den Vorteil, dass das Lesereplikat individuell eingestellt werden kann, z. B. um ihre Leistung bei leseintensiven Operationen zu verbessern, ohne dass die Parameter des Primärservers geändert werden müssen. Dies bietet zwar Flexibilität und Anpassungsoptionen, erfordert jedoch auch eine sorgfältige und manuelle Verwaltung, um die Konsistenz zwischen dem primären Server und dessen Replikat aufrechtzuerhalten, wenn die Uniformität von Serverparametern erforderlich ist.

Für die Administration zuständige Personen können die Serverparameter auf dem Lesereplikatserver ändern und andere Werte als auf dem primären Server festlegen. Die einzige Ausnahme sind Parameter, die sich auf die Wiederherstellung des Replikats auswirken können, die auch im Abschnitt „Skalierung“ unten erwähnt werden: max_connections, max_prepared_transactions, max_locks_per_transaction, max_wal_senders, max_worker_processes. Um sicherzustellen, dass die Wiederherstellung des Lesereplikats nahtlos erfolgt und keine Einschränkungen durch den gemeinsam genutzten Speicher auftreten, sollten diese speziellen Parameter immer auf Werte festgelegt werden, die entweder gleich oder größer sind als die auf dem primären Server konfigurierten Werte.

Skalieren

Sie können Computeressourcen (virtuelle Kerne) hoch- und herunterskalieren, die Dienstebene von „Universell“ in „Arbeitsspeicheroptimiert“ (oder umgekehrt) ändern sowie den Speicher hochskalieren, aber es gelten die folgenden Einschränkungen.

Für Computeskalierung:

  • Azure Database for PostgreSQL – Flexibler Server verlangt, dass mehrere Parameter auf den Replikaten größer oder gleich der Werte auf dem Primärserver sind, um sicherzustellen, dass dem Replikat während der Wiederherstellung nicht der gemeinsame Speicher ausgeht. Die betroffenen Parameter sind: max_connections, max_prepared_transactions, max_locks_per_transaction, max_wal_senders, max_worker_processes.

  • Hochskalieren: Skalieren Sie zuerst die Computekapazität eines Replikats und dann den primären Server hoch.

  • Herunterskalieren: Skalieren Sie zuerst die Computekapazität des primären Servers und dann das Replikat herunter.

  • Compute auf dem primären Server muss immer gleich oder geringer sein als Compute auf dem kleinsten Replikat.

Für die Speicherskalierung:

  • Hochskalieren: Skalieren Sie zuerst den Speicher eines Replikats hoch und dann den Speicher des primären Servers.

  • Die Speichergröße auf dem primären Replikat muss immer gleich oder kleiner als die Speichergröße auf dem kleinsten Replikat sein.

Verwandte Inhalte