Teilen über

Lesereplikate in Azure Database for PostgreSQL – Flexible Server

  • Artikel

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

Mit der Funktion Lese-Replikat können Sie Daten von einer Azure Database for PostgreSQL flexible Serverinstanz auf ein Nur-Lese-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 Replikate erstellen und verwalten.

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 Lese-Repliken in derselben Region wie die primäre Replik weniger Verzögerung als Geo-Repliken, 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 Arbeitsablauf Replikat erstellen starten, wird eine leere Azure Database for PostgreSQL flexible Serverinstanz 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 flexiblen Azure Database for PostgreSQL-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 auf ihre normale Größe zurückgekommen ist. 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. Der Computetarif „Burstfähig“ für Server 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 im Azure-Portal 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, die von der primären Und alle damit verbundenen Einschränkungen geerbt werden.

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 er identisch oder höher sein als der primäre Server.
  • Leistungsstufe (IOPS): Anpassbar.
  • Datenverschlüsselung: Anpassbar, umfassen 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 er 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 Ihr flexibler Azure Database for PostgreSQL-Server mit von der Kundschaft 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 Administratorkonto 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 Administratorbenutzernamen 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 dem flexiblen Azure Database for PostgreSQL-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 aus der Synchronisation geraten, 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.

Azure Database for PostgreSQL: Flexible Server stellt zwei Metriken zum Überwachen der Replikation bereit. Dies sind die Metriken Maximale Verzögerung physischer Replikationen und Lesereplikatverzögerung. Informationen zum Anzeigen dieser Metriken finden Sie im Abschnitt Monitor a replica (Überwachen eines Replikats) im Artikel Howto read replicas (Gewusst wie: Lesereplikate).

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 Einblicke in die aktuelle Bedingung der Lesereplikate und deren Verknüpfung mit der primären liefern. Für Benutzer, die sich auf die Azure Resource Manager-API verlassen, wird der Status beim Aufrufen der GetReplica API in der replica Eigenschaftensammlung als ReplicationState angezeigt.

Die folgenden Werte sind möglich:

Replikationsstatus Beschreibung Bestellung höher stufen Lesen der Replikaterstellungsreihenfolge
Neukonfiguration Warten auf den Start der primären Replikatverbindung. Es kann länger bleiben, wenn das Replikat oder seine Region aufgrund eines Notfalls nicht verfügbar ist. 1 Nicht zutreffend
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. Nicht zutreffend 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
Beschädigt Fehlerhafter Zustand, der angibt, dass der Höherstufen-Vorgang fehlgeschlagen ist, oder das Replikat kann aus irgendeinem Grund keine Verbindung mit dem primären herstellen. Verwerfen Sie das Replikat, und erstellen Sie das Replikat neu, um dies zu beheben.“ – –

Informationen zur Überwachung der Replikation.

Ü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 Replikate gelesen hat, sollten Lesereplikate zuerst gelöscht werden, bevor der primäre Server gelöscht wird.
  • Ein direktes Hauptversions-Upgrade in Azure Database for PostgreSQL flexible Server erfordert das Entfernen aller derzeit auf dem Server aktivierten Read Replicas. 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.
  • Premium SSD v2: Ab der aktuellen Version wird die Erstellung von Lesereplikaten nicht unterstützt, wenn der primäre Server Premium SSD v2 für den Speicher verwendet.
  • Zurücksetzen des Administratorkennworts: Das Zurücksetzen des Administratorkennworts auf dem Replikationsserver wird derzeit nicht unterstützt. Darüber hinaus wird das Aktualisieren des Administratorkennworts 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

Eine Read Replica wird als neue Azure Database for PostgreSQL flexible Serverinstanz 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

Benutzer 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 Read Replicas für eine flexible Serverinstanz von Azure Database for PostgreSQL müssen Sie unbedingt sicherstellen, dass die Einstellung für das automatische Wachstum des Speichers auf den Replicas mit der des Primärservers übereinstimmt. Das Feature für automatisches Speichern ermöglicht es dem Datenbankspeicher, automatisch zu erhöhen, um zu verhindern, dass kein Speicherplatz mehr vorhanden ist, was zu Datenbankausfällen führen kann. 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 Ihr Azure Database for PostgreSQL – Flexible Serverinstanz ist es wichtig, die aktuelle und vorherige Rolle des Servers in verschiedenen Höherstufungszenarienzu 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ärer Server/verwaltete Instanz Ja Ja
Lesereplikat Nein Nein
Replikar auf Primär 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 Azure Database for PostgreSQL Flexible Server-Einrichtung 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är –, insbesondere während dem Höherstufen zu primären Vorgängen. Darüber hinaus müssen Verbindungen mit dem Azure-Speicherkonto, das Write-Ahead Logging (WAL)-Archive speichert, zulässig sein, die Datenbeständigkeit aufrechtzuerhalten 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 und dem Replikat aufrechtzuerhalten, wenn die Uniformität von Serverparametern erforderlich ist.

Administratoren 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 ist und keine Einschränkungen des gemeinsam genutzten Speichers auftreten, sollten diese bestimmten Parameter immer auf Werte festgelegt werden, die entweder gleichwertig oder größer als die auf dem primären Server konfiguriert sind.

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 flexible server verlangt, dass mehrere Parameter auf den Replikaten größer oder gleich der Einstellung 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 kleiner als die Compute auf dem kleinsten Replikat sein.

Für die Speicherskalierung:

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

  • Die Speichergröße für das primäre Replikat muss immer gleich oder kleiner als die Speichergröße des kleinsten Replikats sein.

Zugehöriger Inhalt