Lesereplikate in Azure Database for PostgreSQL: flexibler Server

Mit der Funktion „Lesereplikat“ können Sie Daten von einem Azure Database for PostgreSQL – Flexible Server auf ein schreibgeschütztes Replikat replizieren. Replikate werden asynchron mithilfe der systemeigenen physischen Replikationstechnologie des PostgreSQL-Moduls 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 einen regulären Azure Database for PostgreSQL Flexible Server verwalten. Für jedes Lesereplikat zahlen Sie pro Monat für die in vCores bereitgestellte Rechenleistung und den Speicher in GB.

Erfahren Sie, wie Sie ein Lesereplikat erstellen.

Einsatzmöglichkeiten von Lesereplikaten

Die Read Replica-Funktion trägt dazu bei, die Leistung und Skalierbarkeit von leseintensiven Workloads zu verbessern. Sie können Lesearbeitslasten in die Replikate isolieren, während Sie Arbeitslasten in die Primäre schreiben. Sie können auch Lesereplikate in einer anderen Region bereitstellen und sie zu einem Server mit Lese- und Schreibzugriff hochstufen, falls eine Notfallwiederherstellung erforderlich wird.

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 optimiert, um nahezu Echtzeitupdates von der Primären für die meisten Workloads bereitzustellen, sodass sie eine hervorragende Lösung für leseintensive Szenarien sind. 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 weisen Lesereplikate in derselben Region wie die primäre Instanz eine geringere Verzögerung auf als Georeplikate, da bei letzteren aufgrund der geografischen Entfernung häufig eine höhere Latenz auftritt. 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.

Erstellen eines Replikats

Sie können einen primären Server für Azure Database for PostgreSQL Flexible Server in jeder Region bereitstellen, in der der Dienst unterstützt wird. Sie können Replikate des primären Servers innerhalb derselben Region oder in verschiedenen globalen Azure Regionen erstellen, in denen Azure Database for PostgreSQL verfügbar ist. Sie können Replikate auch in einigen Azure Regionen in souveränen Clouds erstellen. Eine Liste der souveränen Cloudregionen, in denen Sie Replikate erstellen können, finden Sie im Artikel zur Georeplikation .

Wenn Sie den Workflow zum Erstellen eines Replikats starten, wird ein leerer flexibler Server für Azure Database for PostgreSQL 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 verwendet der Prozess einen Snapshot-Ansatz. Daher ist die Erstellungszeit unabhängig von der Größe der Daten. Geo-Replikate werden mithilfe des Basis-Backups der primären Instanz erstellt, das anschließend über das Netzwerk übertragen wird. Daher kann die Erstellungszeit je nach Primärgröße zwischen Minuten und mehreren Stunden liegen.

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

Um einen erfolgreichen Erstellungsvorgang zu erzielen, vermeiden Sie Replikate in Zeiten hoher Transaktionslast. Vermeiden Sie beispielsweise das Erstellen von Replikaten beim Migrieren von anderen Quellen zu einem Azure Database for PostgreSQL flexiblen Server oder bei Schweren Massenlastvorgängen. Wenn Sie Daten migrieren oder große Datenmengen laden, beenden Sie diese Aufgabe zuerst. Nach Abschluss dieser Aufgabe können Sie mit der Einrichtung der Replikate beginnen. Überprüfen Sie nach Abschluss des Migrations- oder Massenladevorgangs, ob die Größe des Transaktionsprotokolls zu ihrer normalen Größe zurückgegeben wurde. In der Regel sollte die Größe des Transaktionsprotokolls nahe bei dem Wert liegen, der in dem Parameter max_wal_size für Ihren Server definiert ist. Sie können den Speicherbedarf des Transaktionsprotokolls nachverfolgen, indem Sie die Metrik "Transaktionsprotokollspeicher verwendet " verwenden, die Einblicke in die Vom Transaktionsprotokoll verwendete Speichermenge liefert. Durch die Überwachung dieser Metrik können Sie sicherstellen, dass sich die Größe des Transaktionsprotokolls innerhalb des erwarteten Bereichs befindet und der Replikaterstellungsprozess gestartet werden kann.

Erfahren Sie, wie Sie ein Lesereplikat erstellen.

Konfigurationsverwaltung

Wenn Sie Lesereplikate für einen Azure Database for PostgreSQL flexiblen Server einrichten, müssen Sie wissen, welche Serverkonfigurationen Sie anpassen können, welche Konfigurationen das Replikat vom primären Server erbt, und alle damit verbundenen Einschränkungen.

Geerbte Konfigurationen

Wenn Sie ein Lesereplikat erstellen, erbt es bestimmte Serverkonfigurationen vom primären Server. Sie können diese Konfigurationen während der Erstellung des Replikats oder nach dem Einrichten des Replikats ändern. Das Lesereplikat erbt jedoch keine bestimmten Einstellungen, z. B. geo-backup, vom primären Server.

Konfigurationen während der Replikaterstellung

• Tarif, Speichergröße: Beim Vorgang Heraufstufen zum primären Server müssen Tarif und Speichergröße mit dem primären Server übereinstimmen. Beim Vorgang Hochstufen zu einem unabhängigen Server und Entfernen aus der Replikation können Tarif und Speichergröße dem primären Server entsprechen oder diese überschreiten.
• Leistungsstufe (IOPS): Anpassbar.
• Datenverschlüsselung: Anpassbar, einschließlich des Wechsels von dienstverwalteten Schlüsseln zu vom Kunden verwalteten Schlüsseln.

Konfigurationen nach der Erstellung

• Firewallregeln: Sie können Regeln hinzufügen, löschen oder ändern.
• Tarif, Speichergröße: Beim Vorgang Heraufstufen zum primären Server müssen Tarif und Speichergröße mit denen des primären Servers übereinstimmen. Für den Vorgang zu einem unabhängigen Server heraufstufen und aus der Replikation entfernen können die Dienstebene und die Speichergröße der des primären Servers entsprechen oder diese überschreiten.
• Leistungsstufe (IOPS): Anpassbar.
• Authentication-Methode: Anpassbare Optionen umfassen den Wechsel von der PostgreSQL-Authentifizierung zu Microsoft Entra.
• Parameter: Die meisten Parameter sind anpassbar. Diejenigen Parameter, die die Größe des gemeinsamen Speichers beeinflussen, sollten jedoch mit dem primären Server übereinstimmen, insbesondere für potenzielle Szenarien einer Hochstufung zum primären Server. Für den Vorgang Heraufstufen zu einem unabhängigen Server und Entfernen aus der Replikation sollten diese Parameter den Parametern auf dem Primärserver entsprechen oder diese überschreiten.
• Wartungszeitplan: Anpassbar.

Nicht unterstützte Features für Lesereplikate

Primärserver unterstützen bestimmte Funktionen, die Sie auf Lesereplikaten nicht einrichten können. Zu diesen Funktionen gehören:

• Sicherungen, einschließlich Geosicherungen.
• Hohe Verfügbarkeit (HA).

Wenn Ihr Azure Database for PostgreSQL Flexible Server als Quellserver mit kundenseitig verwalteten Schlüsseln verschlüsselt ist, finden Sie in der Dokumentation weitere Hinweise.

Kaskadierende Lesereplikate erstellen

Durch den Einsatz von kaskadierten Lese-Replikaten kann die Verteilung von Lesezugriffen gefördert werden, wodurch die Belastung des Hauptservers reduziert wird. Durch die Bereitstellung von Lesereplikaten in verschiedenen Regionen (regionsübergreifende Lesereplikate) kann der Lesezugriff näher an die Benutzer in verschiedenen geografischen Gebieten verteilt werden. Sie können einer Azure Database for PostgreSQL-Serverinstanz kaskadierende Lesereplikate hinzufügen. Mit dieser Funktion können Sie neue Lesereplikate auf Basis eines vorhandenen Lesereplikats erstellen, wobei das vorhandene Lesereplikat als Quelle für die nächste Ebene dient.

Das Lesereplikat der ersten Ebene repliziert asynchron Daten vom primären Server. Anschließend können Sie ein Replikat auf zweiter Ebene erstellen, indem Sie das Replikat der ersten Ebene als Quelle verwenden, um eine zweistufige Replikationshierarchie zu bilden. Diese Architektur erhöht die Skalierbarkeit und unterstützt bis zu 30 Lesereplikatserver, wobei der primäre Server bis zu fünf Lesereplikate unterstützt und jedes dieser Replikate fünf zusätzliche Replikate unterstützt. Um einem Azure Database for PostgreSQL – Flexibler Server ein kaskadierendes Lesereplikat hinzuzufügen, wählen Sie das vorhandene Lesereplikat aus, das vom primären Server erstellt wurde, wechseln Sie zur Registerkarte Replikation, und wählen Sie Replikat erstellen aus.

Zum Beispiel kann Ihr primärer Server bis zu fünf Lesereplikate (Ebene 1) haben. Eine davon, beispielsweise read-replica-1, fungiert als Quelle für eine andere Replik read-replica-2, die Teil von (Ebene 2) wird.

Wichtige Überlegungen

• Sie können bis zu fünf Lesereplikate pro Quell-Lesereplikat erstellen, wobei zwei Replikationsebenen unterstützt werden.
• Der Switchover-Vorgang unterstützt Zwischenlesereplikate (Quelle) und kaskadierendes Lesereplikat.
• Der Vorgang zum Heraufstufen auf primär unterstützt keine zwischengeschalteten Lesereplikate mit kaskadierenden Lesereplikaten.
• Virtuelle Endpunkte werden für kaskadierende Replikate nicht unterstützt.
• Kaskadierende Lesereplikate werden für Zwischenreplikate mit PostgreSQL Version 14 und höher unterstützt.

Herstellen einer Verbindung mit einem Replikat

Wenn Sie ein Replikat erstellen, erbt es nicht die Firewallregeln oder den virtuellen Netzwerkdienstendpunkt des primären Servers. Sie können diese Regeln während der Replikaterstellung festlegen und sie später ändern.

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.

Sie können zwei Methoden verwenden, um eine Verbindung mit dem Replikat herzustellen:

• Direkt zum Replikat: Sie können eine Verbindung mit dem Replikat herstellen, indem Sie seinen Hostnamen und ein gültiges Benutzerkonto verwenden, genau wie auf einem regulären Azure Database for PostgreSQL flexiblen Server. 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 Verbindungsvorgang zu vereinfachen, bietet das Azure-Portal einsatzbereite Verbindungszeichenfolgen. Sie finden diese Verbindungszeichenfolgen auf der Seite "Verbinden" . Sie enthalten sowohl Variablen als auch libpq Verbindungszeichenfolgen, die auf Bash-Konsolen zugeschnitten sind.

• Über virtuelle Endpunkte: Eine alternative Verbindungsmethode verwendet virtuelle Endpunkte. Weitere Informationen finden Sie unter "Virtuelle Endpunkte". Mithilfe von virtuellen Endpunkten können Sie den schreibgeschützten Endpunkt so konfigurieren, dass er immer auf das Replikat verweist, unabhängig davon, welcher Server derzeit die Replikatrolle enthält.

Überwachen der Replikation

Die Lesereplikatfunktion in Azure Database for PostgreSQL basiert auf dem Mechanismus der Replikationsslots. Der Hauptvorteil von Replikationsslots besteht darin, dass sie die Anzahl der von allen Replikationsservern benötigten Transaktionsprotokolle (WAL-Segmente) automatisch anpassen. Mit dieser Anpassung wird verhindert, dass Replikate nicht mehr synchronisiert werden, da dadurch das Löschen von WAL-Segmenten auf der primären Seite vermieden wird, bevor die Replikate sie erhalten. Der Nachteil dieses Ansatzes ist das Risiko, dass der Speicherplatz auf der primären Seite ausläuft, wenn der Replikationsplatz für längere Zeit inaktiv bleibt. In solchen Situationen sammelt die primäre WAL-Dateien, was zu einem inkrementellen Wachstum der Speichernutzung führt. Wenn die Speicherauslastung 95% erreicht oder wenn die verfügbare Kapazität kleiner als 5 GiB ist, wechselt der Server automatisch in den schreibgeschützten Modus, um Fehler zu vermeiden, die mit der Datenträgerlast verbunden sind.
Die Überwachung der Replikationsverzögerung und des Status der Replikationsslots ist daher für Lesereplikate von entscheidender Bedeutung.

Legen Sie Warnungsregeln für den verwendeten Speicher- oder Speicherprozentsatz fest, und für Replikationsverzögerungen, wenn sie bestimmte Schwellenwerte überschreiten, sodass Sie proaktiv handeln, die Speichergröße erhöhen und Verzögerungen beim Lesen von Replikaten löschen können. 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 Kennzahl „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 Dienst 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 diese Metriken zu aktivieren, die standardmäßig nicht aktiviert sind, legen Sie den Parameter metrics.collector_database_activity auf ON. Dieser Parameter ist dynamisch und erfordert keinen Neustart der Instanz.

Logische Replikation

Replikation

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 gilt nur für den Primärserver und ist nur verfügbar, wenn mindestens eines der Lesereplikate mit dem Primärserver 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 keine Transaktionen auf Ihrem primären Server ausgeführt werden und die letzte Transaktion vor 5 Sekunden wiedergegeben wurde, zeigt die Lesereplikatverzögerung 5 Sekunden Verzögerung 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.

Replikationsstatus

Um den Fortschritt und Status der Replikation sowie die Förderung des Vorgangs zu überwachen, konsultieren Sie die 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. Bei Benutzern, die auf die Azure Resource Manager-API vertrauen, wird der Status beim Aufrufen der GetReplica-API im Eigenschaftenbehälter replica als ReplicationState angezeigt.

Die folgenden Werte sind möglich:

Erfahren Sie, wie Sie die Replikation überwachen.

Überlegungen

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

• Energievorgänge: Sie können Energievorgänge, einschließlich Start - und Stoppaktionen , sowohl auf die primären als auch auf den Replikatservern anwenden. Um jedoch die Systemintegrität beizubehalten, folgen Sie einer bestimmten Sequenz. 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 ein Server Replikate gelesen hat, löschen Sie die Lesereplikate zuerst, bevor Sie den primären Server löschen.
• Für ein In-Place-Hauptversionsupgrade für einen Azure Database for PostgreSQL – Flexible Server müssen alle Lesereplikate und kaskadierenden Lesereplikate entfernt werden, die auf dem Server aktiviert sind. Nachdem die Replikate gelöscht wurden, können Sie den primären Server auf die gewünschte Hauptversion aktualisieren. Nach Abschluss des Upgrades können Sie die Replikate neu erstellen, um den Replikationsprozess fortzusetzen.
  • Zurücksetzen des Administratorkennworts: Das Zurücksetzen des Administratorkennworts auf dem Replikatserver wird derzeit nicht unterstützt. Darüber hinaus wird das Aktualisieren des Administratorkennworts zusammen mit dem Bewerben des Replikatvorgangs in derselben Anforderung nicht unterstützt. Wenn Sie diese Aktionen ausführen möchten, stufen Sie zuerst den Replikatserver herauf, und aktualisieren Sie dann das Kennwort auf dem neu heraufgestuften Server separat.

Neue Replikate

Sie erstellen ein Lesereplikat als neuen flexiblen Server in Azure Database for PostgreSQL. Sie können keinen vorhandenen Server in ein Replikat umwandeln.

Ressourcenverschiebung

Sie können Lesereplikate in einer anderen Ressourcengruppe als der primären Ressourcengruppe erstellen. Das Verschieben von Lesereplikaten in eine andere Ressourcengruppe nach deren Erstellung wird jedoch nicht unterstützt. Darüber hinaus wird das Verschieben von Replikaten in ein anderes Abonnement nicht unterstützt. Das Verschieben der primären Instanz, die über Lesereplikate verfügt, in eine andere Ressourcengruppe oder ein anderes Abonnement wird nicht unterstützt.

Automatische Speichervergrößerung

Wenn Sie Lesereplikate für einen Azure Database for PostgreSQL flexiblen Server konfigurieren, stellen Sie sicher, dass die Einstellung für die automatische Vergrößerung des Speichers für die Replikate mit dem des primären Servers ü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.

Sicherung und Wiederherstellung

Wenn Sie Sicherungen und Wiederherstellungen für Ihren Azure Database for PostgreSQL flexiblen Server verwalten, sollten Sie die aktuelle und vorherige Rolle des Servers in verschiedenen Heraufstufungsszenarien berücksichtigen. Beachten Sie diese wichtigsten Punkte:

Höherstufen auf primären Server

• Keine Sicherungen aus lesereplikaten: Das System übernimmt niemals Sicherungen von Lesereplikatservern, unabhängig von ihrer früheren Rolle.
• Erhaltung früherer Sicherungen: Wenn ein Server einmal ein primärer Server war und das System während dieses Zeitraums Sicherungen übernommen hat, behält es diese Sicherungen bis zum benutzerdefinierten Aufbewahrungszeitraum bei.
• Wiederherstellungsvorgangseinschränkungen: Auch wenn frühere Sicherungen für einen Server vorhanden sind, der zu einem Lesereplikat wechselt, sind Wiederherstellungsvorgänge eingeschränkt. Sie können einen Wiederherstellungsvorgang nur initiieren, wenn der Server wieder zur primären Rolle heraufgestuft wird.

Aus Gründen der Übersichtlichkeit veranschaulicht die folgende Tabelle die folgenden Punkte:

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

Solange der Server als Lesereplikat fungiert, erstellt das System keine Sicherungen. Sobald Sie sie jedoch auf einen unabhängigen Server heraufstufen, übernimmt das System Sicherungen sowohl für den höhergestuften Server als auch für den primären Server. Sie können Sicherungen auf beiden Servern wiederherstellen.

Vernetzung

Lesereplikate unterstützen alle Netzwerkoptionen, die von Azure Database for PostgreSQL Flexible Server unterstützt werden.

Diese Anforderung erleichtert nicht nur den Synchronisierungsprozess, sondern gewährleistet auch ein ordnungsgemäßes Funktionieren des Fördermechanismus. Replikate müssen möglicherweise in der umgekehrten Richtung kommunizieren – vom Replikat zum Primärserver –, insbesondere bei Vorgängen zur Heraufstufung zum Primärserver. Darüber hinaus müssen Sie Verbindungen mit dem Azure Speicherkonto zulassen, das Write-Ahead Logging (WAL)-Archive speichert, um die Haltbarkeit der Daten aufrechtzuerhalten und effiziente Wiederherstellungsprozesse zu ermöglichen.

Weitere Informationen zum Konfigurieren des privaten Zugriffs (Integration in ein virtuelles Netzwerk) für Ihre Lesereplikate sowie zu den Auswirkungen auf die Replikation über Azure-Regionen und virtuelle Netzwerke hinweg im Kontext privater Netzwerke finden Sie im Artikel Replikation über Azure-Regionen und virtuelle Netzwerke hinweg mit privaten Netzwerken.

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.

Die Aufrechterhaltung der Integrität und Funktionalität des primären Servers ist eine Priorität. In solchen Grenzfällen kann der Server den Replikationsslot löschen, um sicherzustellen, dass der Primärserver für Lese- und Schreibzugriffe betriebsbereit bleibt. Infolgedessen wechselt die Replikation in den dateibasierten Protokollversandmodus, was zu einer höheren Replikationsverzögerung führen kann.

Überwachen Sie die Speichernutzung und Replikationsverzögerung genau, und ergreifen Sie erforderliche Maßnahmen, um potenzielle Probleme zu beheben, bevor sie eskalieren.

Parameters

Wenn Sie ein Lesereplikat erstellen, erbt es die Parameter vom primären Server. Diese Vererbung stellt einen konsistenten und zuverlässigen Ausgangspunkt sicher. Alle Änderungen an den Parametern auf dem primären Server, die Sie nach dem Erstellen des Lesereplikats vornehmen, werden jedoch 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. Dieses Verhalten bietet zwar Flexibilität und Anpassungsoptionen, erfordert jedoch auch eine sorgfältige und manuelle Verwaltung, um die Konsistenz zwischen der primären und dem Replikat aufrechtzuerhalten, wenn die Einheitlichkeit von Parametern erforderlich ist.

Administratoren können Parameter auf dem Lesereplikatserver ändern und unterschiedliche 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 für gemeinsam genutzten Arbeitsspeicher auftreten, legen Sie diese bestimmten Parameter immer auf Werte fest, die entweder gleichwertig oder größer als die auf dem primären Server konfiguriert sind. Stellen Sie vor dem Verringern der Parameterwerte auf einem Lesereplikatserver sicher, dass die Replikationsverzögerung minimal ist oder das Replikat vollständig mit dem primären Server in Verbindung steht, um potenzielle Replikations- oder Wiederherstellungsprobleme zu vermeiden.

Scale

Sie können die Berechnung nach oben und unten (vCores) skalieren, die Dienstebene von "General Purpose" in "Memory Optimized" (oder umgekehrt) ändern und den Speicher nach oben skalieren. Die folgenden Vorbehalte gelten jedoch.

Für Computeskalierung:

• Der Azure Database for PostgreSQL-Dienst erfordert, dass mehrere Parameter auf den Replikaten größer oder gleich der Einstellung auf dem primären sind, um sicherzustellen, dass dem Replikat während der Wiederherstellung nicht der gemeinsame Speicher ausgeht. Die betroffenen Parameter sind: max_connections, , max_prepared_transactionsmax_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.

• Die Berechnung auf der Primären muss immer gleich oder kleiner als die Berechnung für das kleinste 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 der primären Datei muss immer gleich oder kleiner als die Speichergröße des kleinsten Replikats sein.

Verwandte Inhalte

• Geo-Replikation in Azure Database for PostgreSQL.
• Lesereplikate in Azure Database for PostgreSQL höherstufen.
• Virtuelle Endpunkte für Lesereplikas in der Azure-Datenbank für PostgreSQL.
• Erstellen eines Lesereplikats
• Replikation über Azure-Regionen und virtuelle Netzwerke mit privaten Netzwerkverbindungen.