Freigeben über

Lesereplikate in Azure Cosmos DB for PostgreSQL

  • Artikel

GILT FÜR: Azure Cosmos DB for PostgreSQL (unterstützt von der Citus-Datenbankerweiterung auf PostgreSQL)

Mithilfe des Features für Lesereplikate können Sie Daten von einem Cluster auf einen schreibgeschützten Cluster replizieren. Replikate werden mithilfe der physischen Replikationstechnologie von PostgreSQL asynchron aktualisiert. Sie können bis zu fünf Replikate vom primären Server ausführen.

Replikate sind neue Cluster, die Sie ähnlich wie reguläre Cluster verwalten. Für jedes Lesereplikat werden Ihnen die bereitgestellten Computeressourcen in Form von virtuellen Kernen sowie der Speicher in GiB/Monat in Rechnung gestellt. Die Compute- und Speicherkosten für Replikatcluster sind dieselben wie für reguläre Cluster.

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.

In einem häufig 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

Das Feature ist für Szenarien vorgesehen, in denen die Verzögerung bei der Replikation akzeptabel und für das Auslagern von Abfragen vorgesehen ist. Es ist nicht für Szenarien mit synchroner Replikation gedacht, in denen die Replikatdaten auf dem neuesten Stand sein sollen. Zwischen dem primären Server und dem Replikat entsteht eine messbare Verzögerung. Diese Verzögerung kann – abhängig von der Workload und der Latenz zwischen primärem Server und Replikat – Minuten oder sogar Stunden dauern. 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

Wenn Sie den Workflow zum Erstellen von Replikaten starten, wird ein leerer Cluster erstellt. Der neue Cluster wird mit den Daten gefüllt, die im primären Server vorhanden waren. Die Erstellungszeit hängt von der Datenmenge auf dem primären Server und der verstrichenen Zeit seit der letzten wöchentlichen vollständigen Sicherung ab. Dieser Zeitraum kann wenige Minuten bis zu mehrere Stunden umfassen.

Das Feature für Lesereplikate verwendet die physische Replikation von PostgreSQL, nicht die logische Replikation. Der Standardmodus ist Streamingreplikation mithilfe von Replikationsslots. Bei Bedarf wird zum Aufholen der Protokollversand verwendet.

Erfahren Sie, wie Sie ein Lesereplikat im Azure-Portal erstellen.

Herstellen einer Verbindung mit einem Replikat

Wenn Sie ein Replikat erstellen, erbt es keine Firewallregeln vom primären Cluster. Diese Regeln müssen separat für das Replikat eingerichtet werden.

Das Replikat erbt das Administratorkonto (citus) vom primären Cluster. Alle Benutzerkonten werden in 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 sich mit dem Koordinatorknoten des Replikats verbinden, indem Sie wie bei einem regulären Cluster zur Verbindungsherstellung dessen Hostnamen und ein gültiges Benutzerkonto verwenden. Beim Server my replica mit dem Administratorbenutzernamen citus können Sie z. B. mithilfe von psql wie folgt eine Verbindung mit dem Koordinatorknoten herstellen:

psql -h c-myreplica.12345678901234.postgres.cosmos.azure.com -U citus@myreplica -d postgres

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

Höherstufen eines Replikats zu einem unabhängigen Cluster

Sie können ein Replikat zu einem unabhängigen Cluster hochstufen, für den Lese- und Schreibvorgänge ausgeführt werden können. Ein höhergestuftes Replikat erhält keine Aktualisierungen mehr vom ursprünglichen Replikat, und die Höherstufung kann nicht rückgängig gemacht werden. Höhergestufte Replikate können selbst über Replikate verfügen.

Es gibt zwei gängige Szenarien für die Höherstufung eines Replikats:

  1. Notfallwiederherstellung Wenn es beim primären Cluster oder in der gesamten Region zu Problemen kommt, können Sie als Notfallmaßnahme einen weiteren Cluster für Schreibvorgänge einrichten.

  2. Migrieren zu einer anderen Region. Wenn Sie zu einer anderen Region wechseln möchten, erstellen Sie ein Replikat in der neuen Region. Warten Sie ab, bis alle Daten in das neue Replikat übertragen wurden, und verschieben dann das Replikat. Um einen möglichen Datenverlust während der Höherstufung zu vermeiden, sollten Sie den Schreibzugriff für den ursprünglichen Cluster deaktivieren, nachdem alle Daten in das Replikat übertragen wurden.

    Sie können mithilfe der Metrik replication_lag den Fortschritt bei der Datenübertragung in das Replikat anzeigen. Weitere Informationen finden Sie unter Metriken.

Überlegungen

In diesem Abschnitt werden Aspekte des Features für Lesereplikate zusammengefasst.

Neue Replikate

Ein Lesereplikat wird als neuer Cluster erstellt. Ein vorhandener Cluster kann nicht in ein Replikat umgewandelt werden. Es kann kein Replikat eines anderen Lesereplikats erstellt werden.

Replikatkonfiguration

Replikate erben Compute-, Speicher- und Workerknoteneinstellungen von ihren primären Servern. Sie können einige, aber nicht alle Einstellungen für ein Replikat ändern. Beispielsweise können Sie das Computing, Firewallregeln für den öffentlichen Zugriff und private Endpunkte für den privaten Zugriff ändern. Sie können jedoch weder die Speichergröße noch die Anzahl der Workerknoten ändern.

Denken Sie daran, die Replikate so stark zu machen, dass sie mit Änderungen, die vom primären Server eintreffen, Schritt halten können. Sie müssen beispielsweise die Computeleistung in Replikaten hochskalieren, wenn Sie sie auf dem primären Server hochskalieren.

Firewallregeln und Parametereinstellungen werden beim Erstellen des Replikats oder danach nicht vom primären Server geerbt.

Regionsübergreifende Replikation

Lesereplikate können in der Region des primären Clusters oder in jeder anderen von Azure Cosmos DB for PostgreSQL unterstützten Region erstellt werden. Bei der Obergrenze von fünf Replikaten pro Cluster werden alle Regionen einbezogen, es sind also fünf Replikate insgesamt, nicht fünf pro Region.

Nächste Schritte