Verwaltung und Überwachung der logischen Replikation

Diese Seite beschreibt, wie man die logische Replikation in Lakebase überwacht, wie Replikation mit Skalierung bis Null und Verzweigungen interagiert und wie häufige Probleme gelöst werden können. Für die Einrichtung siehe Daten in Lakebase replizieren und Daten aus Lakebase replizieren.

Replikation überwachen

Jede Postgres-Rolle kann die Replikationskataloge auf dieser Seite abfragen, mit zwei Ausnahmen. Die Spalte subconninfo von pg_subscription kann das Verbindungspasswort enthalten und ist eingeschränkt, daher wählen Sie bestimmte Spalten anstelle der Verwendung von SELECT *. In pg_stat_replication sind die meisten Spalten verdeckt, es sei denn, deine Rolle hat pg_read_all_stats, über die Mitglieder von databricks_superuser verfügen.

Bestätigen Sie bei einem Teilnehmer, dass das Abonnement existiert und aktiviert ist:

SELECT subname, subenabled FROM pg_catalog.pg_subscription;

Bei einem Verlag bestätigen Sie, dass die Veröffentlichung existiert:

SELECT pubname FROM pg_catalog.pg_publication;

Überprüfen Sie den Synchronisationsstatus pro Tabelle beim Abonnenten. Wenn bei jeder Tabelle Ready (fully live) angezeigt wird, ist die erste Kopie fertig und die Subscription wird gestreamt:

SELECT
    srrelid::regclass AS table_name,
    CASE srsubstate
        WHEN 'i' THEN 'Initializing'
        WHEN 'd' THEN 'Data copying (in progress)'
        WHEN 's' THEN 'Synchronized (catching up)'
        WHEN 'r' THEN 'Ready (fully live)'
    END AS sync_status
FROM pg_catalog.pg_subscription_rel;

Überprüfen Sie den Abonnementstatus und den Lag:

SELECT subname, received_lsn, latest_end_lsn, last_msg_receipt_time
FROM pg_catalog.pg_stat_subscription;

Vergleichen Sie die Zeilenzahlen des Publishers und des Abonnenten, um sicherzustellen, dass eine Tabelle synchron ist:

SELECT COUNT(*) FROM public.playing_with_lakebase;

Listen Sie bei einem Publisher die Replikationsslots auf und wie weit jeder Slot fortgeschritten ist:

SELECT slot_name, slot_type, active, restart_lsn
FROM pg_catalog.pg_replication_slots;

Bei Lakebase umfassen die Ergebnisse auch die internen physischen Slots wal_proposer_slot und wal_retention_slot. Lakebase verwaltet diese Slots, und sie sind nicht Teil der logischen Replikation.

Logische Replikation und auf null skalieren

Ein Lakebase-Compute mit einem aktiven Abonnenten skaliert nicht auf null, was die Compute-Nutzung erhöhen kann.

Nach aktiven Abonnenten suchen:

SELECT *
FROM pg_catalog.pg_stat_replication
WHERE application_name <> 'walproposer';

Replikationsslots und Speicher

Ein Replikationsslot sorgt dafür, dass der Publisher das Write-Ahead-Log (WAL) aufbehält, bis der Subscriber bestätigt, dass er die Änderungen erhalten hat. Wenn der Abonnent aufhört, Änderungen zu konsumieren, zum Beispiel weil er deaktiviert, getrennt, ausgefallen ist oder zurückfällt, sammelt sich WAL beim Publisher an. Dies ist die häufigste Ursache für ernsthafte Probleme mit der logischen Replikation:

  • Dem Verlag kann der Speicherplatz ausgehen. Retained WAL wächst, bis der Speicher des Publishers voll ist, was dazu führen kann, dass die Datenbank keine Schreibvorgänge mehr akzeptiert und zu einem Ausfall führen kann.
  • Das Entfernen des Slots gibt keinen Speicherplatz sofort frei. Postgres entfernt das zurückgehaltene WAL nur, wenn es WAL-Segmente an einem späteren Kontrollpunkt recycelt. Wenn der Publisher bereits keinen Speicherplatz mehr hat, kann das Recycling möglicherweise nicht abgeschlossen werden.
  • Das Risiko gilt auch für externe Verlage. Wenn Lakebase eine externe Datenbank abonniert, sammelt sich WAL auf dieser externen Quelle, wenn die Subskription keine Änderungen mehr verarbeitet.

Zurückbehaltenes WAL überwachen

Im Publisher prüfen Sie, wie viel WAL jeder logische Slot behält und ob er aktiv ist:

SELECT slot_name, active, wal_status,
       pg_catalog.pg_size_pretty(pg_catalog.pg_wal_lsn_diff(pg_catalog.pg_current_wal_lsn(), restart_lsn)) AS retained_wal
FROM pg_catalog.pg_replication_slots
WHERE slot_type = 'logical';

Führen Sie diese Abfrage regelmäßig aus, solange die Replikation aktiv ist. Untersuchen Sie, wann retained_wal weiter wächst oder activefalse ist. Ein extended von wal_status bedeutet, dass der Slot mehr WAL behält, als der Publisher normalerweise behält. Ein wal_status von unreserved oder lost bedeutet, dass der Slot max_slot_wal_keep_size überschritten hat und das benötigte WAL verliert oder bereits verloren hat, weshalb das Abonnement neu erstellt werden muss.

Von WAL-Ansammlungen wiederherstellen

  1. Finde den Slot, der WAL zurückhält, mit der Abfrage unter Monitor retained WAL.

  2. Wenn der Subscriber sich erholen kann, beheben Sie die Ursache, wie ein Netzwerkproblem, ein deaktiviertes Abonnement oder ein fehlgeschlagener Apply-Vorgang, damit der Subscriber aufholt und der Slot vorrückt.

  3. Wenn du das Abonnement nicht mehr brauchst, kündige es für den Abonnenten. Wenn der Subscriber nicht erreichbar ist, legen Sie den Slot direkt auf dem Publisher ab. Ein Slot muss inaktiv sein, bevor du ihn ablegen kannst:

    SELECT pg_catalog.pg_drop_replication_slot('<slot_name>');

  4. Warte darauf, dass der Publisher das zurückbehaltene WAL recycelt. Bei einem selbstverwalteten Publisher, der fast keinen Speicherplatz mehr hat, sollte man zuerst Speicher hinzufügen, damit das Recycling abgeschlossen werden kann.

Automatische Entfernung inaktiver Slots auf Lakebase

Wenn Lakebase der Publisher ist, entfernt es automatisch einen Replikationsslot, der etwa 40 Stunden inaktiv war, um zu verhindern, dass der Slot WAL unbegrenzt behält. Ein Slot wird inaktiv, wenn sein Abonnent aufhört, Änderungen zu verarbeiten, und der Slot nicht weiter fortgeschrieben wird. Dies kann passieren, wenn ein Abonnent deaktiviert oder nicht verfügbar ist oder wenn ein Teilnehmer mit langer Replikationsverzögerung konfiguriert ist.

Um zu verhindern, dass ein Slot entfernt wird, stelle sicher, dass der Abonnent verbunden bleibt und weiterhin Änderungen verarbeitet. Wenn der Abonnent eine konfigurierbare Replikationsverzögerung oder -frequenz verwendet, halte sie unter 40 Stunden, damit der Slot weiter voranschreitet. Wenn ein Slot entfernt wird und du ihn trotzdem brauchst, erstelle die Subscription beim Abonnenten erneut.

Externe Publisher entfernen inaktive Slots nicht automatisch. Legen Sie bei einem selbstverwalteten Publisher max_slot_wal_keep_size fest, um die WAL zu begrenzen, die ein Slot beibehalten kann. Wenn ein Slot das Limit überschreitet, macht Postgres ihn ungültig und Sie müssen das Abonnement neu erstellen.

Branch-Restore entfernt Replikationsslots

Das Wiederherstellen eines Zweigs löscht alle Replikationsslots auf diesem Zweig. Erstellen Sie Publikationen und Abonnements nach einer Branchwiederherstellung wieder.

Untergeordnete Zweige erben keine Subscriptions

Abonnements, die auf einem übergeordneten Branch definiert sind, werden nicht auf dessen untergeordnete Branches dupliziert. Lakebase entfernt sie aus einem untergeordneten Branch, bevor der Compute dieses Branches startet, sodass nicht zwei Computes dasselbe Abonnement replizieren. Dies gilt, wenn du einen Child-Branch erstellst, zurücksetzt oder wiederherstellst. Erstelle das Abonnement im untergeordneten Branch erneut, falls du dort eine Replikation brauchst.

Das Entfernen einer Datenbank entfernt deren Abonnements

Bevor eine Datenbank als Reaktion auf einen DROP DATABASE Befehl oder eine Operation verworfen wird, löscht Lakebase alle in dieser Datenbank definierten logischen Replikationsabonnements.

Replikationsrollen

Eine dedizierte Replikationsrolle muss das Attribut REPLICATION besitzen. Rollen, die in der Lakebase-App, der Azure Databricks CLI oder der REST API erstellt werden, besitzen dieses Attribut, unabhängig davon, ob sie Mitglieder von databricks_superuser sind oder nicht. Mit SQL erstellte Rollen erhalten das Attribut REPLICATION nicht automatisch. Um eines mit SQL zu erstellen, fügen Sie zum Beispiel CREATE ROLE replication_user WITH LOGIN REPLICATION PASSWORD '<password>';das Attribut hinzu. Um es zu einer bestehenden Rolle hinzuzufügen, führe ALTER ROLE <role_name> REPLICATION; aus. Beide Aussagen erfordern eine Rolle, die die Attribute CREATEROLE und REPLICATION besitzt, wie zum Beispiel die Rolle des Projektverantwortlichen.

Überprüfen Sie die Privilegien einer Rolle:

SELECT rolname, rolreplication
FROM pg_catalog.pg_roles
WHERE rolname = '<role_name>';

Decoder-Plugins

Lakebase unterstützt zwei Plugins für die logische Dekodierungsausgabe:

  • pgoutput: das integrierte Postgres-Plugin für logische Replikation und der Standard. Nutze es für die Standard-Postgres-zu-Postgres-Replikation.
  • wal2json: gibt WAL-Änderungen als JSON aus, für Systeme, die Änderungsdaten in JSON verbrauchen.

Publisher-Einstellungen

Auf Lakebase sind max_wal_senders und max_replication_slots beide auf 10 gesetzt:

max_wal_senders = 10
max_replication_slots = 10

max_wal_senders begrenzt die gleichzeitigen WAL-Senderprozesse, die Änderungen an Abonnenten streamen, und max_replication_slots begrenzt die Replikationsslots, die den Fortschritt der Abonnenten verfolgen. Plan für jeden Abonnenten jeweils ein Exemplar. Um verschiedene Werte anzufordern, wenden Sie sich an Databricks.

Einen dedizierten Replikationsslot erstellen

Einige Datendienste erfordern einen Replikationsslot, den man im Voraus erstellt. Erstellen Sie einen Replikationsslot mit der Standardfunktion von Postgres und benennen Sie das Decoder-Plugin:

SELECT pg_catalog.pg_create_logical_replication_slot('my_replication_slot', 'pgoutput');

Entfernen Sie ein Abonnement oder eine Publikation

Entfernen Sie eine Subscription beim Abonnenten, wenn Sie sie nicht mehr benötigen. Wenn der Publisher erreichbar ist, trennt das Beenden des Abonnements die Verbindung zum Publisher und entfernt den Replikationsslot des Publishers. Replizierte Daten bleiben in der Abonnentendatenbank.

DROP SUBSCRIPTION my_subscription;

Wenn der Publisher nicht erreichbar ist, wird DROP SUBSCRIPTION nicht abgeschlossen, weil er keine Verbindung herstellen kann, um den entfernten Slot zu entfernen. Hebe zuerst die Zuordnung des Slots auf, dann lösche das Abonnement:

ALTER SUBSCRIPTION my_subscription DISABLE;
ALTER SUBSCRIPTION my_subscription SET (slot_name = NONE);
DROP SUBSCRIPTION my_subscription;

In diesem Fall bleibt der Replikationsslot beim Publisher und hält weiterhin WAL vor. Entfernen Sie es im Publisher, um das WAL freizugeben:

SELECT pg_catalog.pg_drop_replication_slot('<slot_name>');

Ziehen Sie eine Publikation auf den Verlag:

DROP PUBLICATION my_publication;

Troubleshooting

Symptom Ursache und Auflösung
Das Abonnement verbindet sich nicht. Bestätigen Sie, dass der Publisher erreichbar ist und dass die Verbindungszeichenfolge, die Rolle und das Passwort korrekt sind. Wenn Lakebase der Subscriber ist, bestätigen Sie, dass der Publisher-Endpoint auf der Allowlist der Netzwerkrichtlinie des Kontos steht. Siehe Daten in Lakebase replizieren.
CREATE SUBSCRIPTION schlägt mit restricted by Account Network Policies fehl. Ihr Konto erzwingt eine Netzwerkrichtlinie, und der Publisher-Host befindet sich nicht in den zulässigen Internetzielen. Fügen Sie den Host zur Netzwerkrichtlinie des Kontos hinzu. Siehe Daten in Lakebase replizieren.
Der Speicher wächst und gibt keinen Speicher frei. Ein Replikationsslot behält WAL, weil sein Abonnent keine Änderungen konsumiert. Wenn das Problem nicht behoben wird, kann dem Herausgeber der Speicherplatz ausgehen. Überprüfen Sie die zurückgehaltene WAL, verbinden Sie dann den Abonnenten wieder oder löschen Sie den Slot. Speicher wird erst freigegeben, nachdem der Publisher WAL recycelt hat. Siehe Replikationsslots und Speicher.
Die Zeilen kommen beim Abonnenten nicht an. Bestätigen Sie, dass die Zieltabellen mit passenden Namen und Spalten existieren und dass die Veröffentlichung die erwarteten Tabellen enthält.

Nächste Schritte

  • Zuletzt aktualisiert um