Gestire e monitorare la replica logica

Questa pagina descrive come monitorare la replica logica in Lakebase, come la replica interagisce con la scalabilità fino a zero e i branch, e come risolvere problemi comuni. Per la configurazione, vedi Replica i dati in Lakebase e Replica i dati da Lakebase.

Monitoraggio della replica

Qualsiasi ruolo Postgres può interrogare i cataloghi di replica presenti in questa pagina, con due eccezioni. La subconninfo colonna di pg_subscription può contenere la password di connessione ed è limitata, quindi seleziona colonne specifiche invece di usare SELECT *. In pg_stat_replication, la maggior parte delle colonne è nascosta a meno che il tuo ruolo non abbia pg_read_all_stats, permesso di cui dispongono i membri di databricks_superuser.

In un sottoscrittore, conferma che l'abbonamento esiste ed è abilitato:

SELECT subname, subenabled FROM pg_catalog.pg_subscription;

In un editore, conferma che la pubblicazione esiste:

SELECT pubname FROM pg_catalog.pg_publication;

Controlla lo stato della sincronizzazione per tabella sul sottoscrittore. Quando ogni tabella riporta Ready (fully live), la copia iniziale è completa e la sottoscrizione è in streaming:

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;

Controlla lo stato dell'abbonamento e il lag:

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

Confronta il conteggio delle righe tra il pubblicatore e il sottoscrittore per confermare che una tabella sia sincronizzata:

SELECT COUNT(*) FROM public.playing_with_lakebase;

Su un editore, elenca gli slot di replicazione e quanto ciascuno è avanzato:

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

Su Lakebase, i risultati includono anche gli slot fisici interni wal_proposer_slot e wal_retention_slot. Lakebase gestisce questi slot, che non fanno parte della replicazione logica.

Replicazione logica e scalabilità fino a zero

Una risorsa di calcolo Lakebase con un sottoscrittore attivo non viene ridimensionata a zero, il che può aumentare l'utilizzo delle risorse di calcolo.

Controlla la presenza di abbonati attivi:

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

Slot di replicazione e memoria

Uno slot di replica fa sì che il publisher conservi il write-ahead log (WAL) finché il subscriber non conferma di aver ricevuto le modifiche. Se il sottoscrittore smette di consumare modifiche, ad esempio perché è disabilitato, disconnesso, in guasto o in ritardo, il WAL si accumula sul publisher. Questa è la causa più comune di gravi problemi di replicazione logica:

• L'editore può rimanere senza spazio di archiviazione. Il WAL conservato cresce fino a quando lo spazio di archiviazione del publisher non è pieno, il che può impedire al database di accettare scritture e causare un'interruzione.
• Eliminare lo slot non libera immediatamente spazio di archiviazione. Postgres rimuove il WAL conservato solo quando ricicla i segmenti WAL in un checkpoint successivo. Se il server di pubblicazione ha già esaurito lo spazio di archiviazione, quel riciclo potrebbe non essere completato.
• Il rischio vale anche per editori esterni. Quando Lakebase si sottoscrive a un database esterno, WAL si accumula sulla sorgente esterna se l'abbonamento smette di consumare modifiche.

Monitora il WAL conservato

Sul publisher, controlla quanto WAL mantiene ogni slot logico e se è attivo:

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';

Esegui questa query regolarmente mentre la replicazione è attiva. Verifica se retained_wal continua a crescere o active è false. Un valore di wal_status di extended significa che lo slot trattiene più WAL di quanto il publisher normalmente conservi. Un unreserved di lost o max_slot_wal_keep_size significa che lo slot ha superato wal_status e sta perdendo, o ha perso, il WAL di cui ha bisogno, quindi l'abbonamento deve essere ricreato.

Recupero dall'accumulo WAL

1. Trova lo slot che sta mantenendo WAL con la query in Monitor retained WAL.

2. Se il sottoscrittore può recuperare, correggi la causa, come un problema di rete, una sottoscrizione disattivata o un processo di applicazione non riuscito, così il sottoscrittore recupera e lo slot avanza.

3. Se non hai più bisogno dell'abbonamento, rimuovilo dall'abbonato. Se il subscriber non è raggiungibile, lascia l'alloggiamento direttamente al publisher. Uno slot deve essere inattivo prima di poterlo rimuovere:

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

4. Aspetta che il publisher ricicli il WAL conservato. Su un publisher autogestito che sta per esaurire lo storage, aggiungi prima lo storage così il riciclo può completarsi.

Rimozione automatica degli slot inattivi su Lakebase

Quando Lakebase è il publisher, rimuove automaticamente uno slot di replica inattivo per circa 40 ore, per evitare che lo slot mantenga WAL indefinitamente. Uno slot diventa inattivo quando il suo sottoscrittore smette di consumare i cambiamenti e lo slot smette di avanzare. Questo può accadere quando un sottoscrittore viene disattivato o diventa non disponibile, oppure quando un sottoscrittore è configurato con un lungo ritardo di replica.

Per evitare che uno slot venga rimosso, assicurati che il suo sottoscrittore rimanga connesso e continui a consumare modifiche. Se il sottoscrittore utilizza un ritardo o una frequenza di replica configurabile, mantenere il valore impostato al di sotto delle 40 ore così lo slot continua ad avanzare. Se uno slot viene rimosso e ne hai ancora bisogno, ricrea l'abbonamento sul sottoscrittore.

Gli editori esterni non rimuovono automaticamente gli slot inattivi. Su un publisher autogestito, imposta max_slot_wal_keep_size per limitare il WAL che uno slot può mantenere. Se uno slot supera il limite, Postgres lo invalida e devi ricreare la sottoscrizione.

Il ripristino del branch rimuove gli slot di replicazione

Ripristinare un branch elimina tutti gli slot di replicazione su quel branch. Ricrea pubblicazioni e sottoscrizioni dopo il ripristino di un ramo.

I rami secondari non ereditano gli abbonamenti

Gli abbonamenti definiti su un ramo genitore non vengono duplicati sui suoi rami figli. Lakebase li elimina da un branch figlio prima che inizi il calcolo di quel branch, quindi due calcoli non replicano la stessa sottoscrizione. Questo vale quando crei, resetti o ripristini un branch figlio. Ricrea la sottoscrizione sul ramo figlio se lì è necessaria la replica.

Eliminare un database del sottoscrittore lascia lo slot sul publisher

Quando elimini un database che ha sottoscrizioni usando l'app Lakebase, la CLI di Databricks o l'API REST, Lakebase elimina prima quelle sottoscrizioni, ma non rimuove gli slot di replica sul publisher. Ogni slot rimane sul publisher e continua a mantenere WAL, che può riempire lo spazio di archiviazione del publisher. Durante una migrazione, il publisher è spesso il tuo database di produzione.

Un comando SQL DROP DATABASE si comporta come in un Postgres standard: fallisce con database "<name>" is being used by logical replication subscription quando il database ha sottoscrizioni.

Per evitare di lasciare uno slot inutilizzato, elimina ogni abbonamento prima di eliminare il database. Quando l'editore è raggiungibile, DROP SUBSCRIPTION rimuove anche lo slot sull'editore. Vedi Rimuovi un abbonamento o una pubblicazione.

Se hai già cancellato il database, rimuovi lo slot rimasto sul publisher. Di default, lo slot di un abbonamento ha lo stesso nome dell'abbonamento. Se hai impostato slot_name quando hai creato l'abbonamento, usa quel nome invece. Per registrare i nomi degli slot prima di cancellare un database, esegui SELECT subname, subslotname FROM pg_catalog.pg_subscription; in quel database. Conferma che lo slot esiste ed è inattivo:

SELECT slot_name, database, plugin, active
FROM pg_catalog.pg_replication_slots
WHERE slot_type = 'logical' AND slot_name = '<slot_name>';

Elimina solo lo slot che apparteneva all'abbonamento cancellato. Altri slot inattivi possono appartenere agli abbonati o a strumenti di change data capture temporaneamente disconnessi, ed eliminarli interrompe la replica. Rimuovi lo slot:

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

Ruoli di replicazione

Un ruolo dedicato alla replica deve avere l'attributo REPLICATION . I ruoli creati nell'app Lakebase, nell'Azure Databricks CLI o nell'API REST possiedono questo attributo, indipendentemente dal fatto che siano membri di databricks_superuser. I ruoli creati con SQL non ricevono automaticamente l'attributo REPLICATION . Per crearne uno con SQL, includere l'attributo, ad esempio CREATE ROLE replication_user WITH LOGIN REPLICATION PASSWORD '<password>';. Per aggiungerlo a un ruolo esistente, esegui ALTER ROLE <role_name> REPLICATION;. Entrambe le affermazioni richiedono un ruolo che abbia gli attributi CREATEROLE e REPLICATION, come quello del proprietario del progetto.

Controlla i privilegi di un ruolo:

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

Plugin del decoder

Lakebase supporta due plugin di output di decodifica logica:

• pgoutput: il plugin di replicazione logica integrato di Postgres, ed è quello predefinito. Usalo per la replica standard da Postgres a Postgres.
• wal2json: emette le modifiche WAL come JSON, per i sistemi che consumano dati di cambiamento in JSON.

Impostazioni di Publisher

Su Lakebase, max_wal_senders e max_replication_slots sono entrambi impostati a 10:

max_wal_senders = 10
max_replication_slots = 10

max_wal_senders limita i processi sender WAL concorrenti che trasmettono le modifiche ai sottoscrittori e max_replication_slots limita gli slot di replica che tracciano i progressi dei sottoscrittori. Pianifica uno per ogni abbonato. Per richiedere valori diversi, contatta Databricks.

Crea uno slot di replica dedicato

Alcuni servizi dati richiedono uno slot di replica che devi creare in anticipo. Crea-ne uno con la funzione standard Postgres, dando il nome al plugin di decodifica:

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

Rimuovere un abbonamento o una pubblicazione

Rimuovi una sottoscrizione dall'abbonato quando non ne hai più bisogno. Quando l'editore è raggiungibile, l'interruzione dell'abbonamento disconnette dall'editore e rimuove lo slot di replica sull'editore. I dati replicati rimangono nel database del sottoscrittore.

DROP SUBSCRIPTION my_subscription;

Se il publisher è irraggiungibile, DROP SUBSCRIPTION non si completa perché non può connettersi per rimuovere lo slot remoto. Disassocia prima lo slot, poi elimina l'abbonamento:

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

In questo caso lo slot di replica rimane sul server di pubblicazione e continua a mantenere WAL. Rimuovilo dal publisher per rilasciare il WAL:

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

Trascina una pubblicazione sull'editore:

DROP PUBLICATION my_publication;

Troubleshooting

Passaggi successivi

• Migra in Lakebase: Replica un database Postgres esistente in Lakebase. Vedi come replicare i dati in Lakebase.
• Streaming da Lakebase: Pubblica le modifiche a un abbonato esterno a Postgres. Vedi come replicare i dati da Lakebase.
• Comprendi la funzione: Rivedi cos'è la replicazione logica e quando usarla. Vedi Replicazione logica.