Trasmettere dati in streaming dai database PostgreSQL

Puoi utilizzare Datastream per replicare i dati storici e le modifiche in corso da un database PostgreSQL nella destinazione per l'analisi in tempo reale e la sincronizzazione del database.

Per prepararti alla replica di PostgreSQL in Datastream, esamina il comportamento della replica, le versioni e i tipi di database supportati, le best practice, i requisiti per le repliche di lettura e le limitazioni note.

Comportamento

Il database PostgreSQL di origine si basa sulla funzionalità di decodifica logica. La decodifica logica espone tutte le modifiche di cui è stato eseguito il commit nel database e consente di utilizzarle ed elaborarle in un formato facile da usare utilizzando un plug-in di output. Datastream utilizza il plug-in pgoutput, che è il plug-in di decodifica logica PostgreSQL standard per PostgreSQL 10 e versioni successive.

  • È possibile selezionare tutti gli schemi o schemi specifici di un'origine PostgreSQL, nonché tutte le tabelle dello schema o tabelle specifiche.
  • Tutti i dati storici vengono replicati.
  • Vengono replicate tutte le modifiche del data manipulation language (DML), come inserimenti, aggiornamenti ed eliminazioni dai database e dalle tabelle specificati.
  • Vengono replicate solo le modifiche di cui è stato eseguito il commit.
  • Se definisci un'IDENTITÀ REPLICA su una tabella, Datastream tratta le colonne specificate come chiavi primarie.
  • Datastream invia periodicamente messaggi heartbeat al database di origine quando è connesso a un'istanza principale. Di conseguenza, gli eventi dei messaggi di decodifica logica (op:"m") vengono inseriti direttamente nel file WAL. Questi messaggi sono richiesti da Datastream per garantire la disponibilità dell'origine e calcolare l'aggiornamento. Quando utilizzi una replica di lettura come origine, devi configurare i messaggi di heartbeat esternamente. Per saperne di più, consulta Replica dalle repliche di lettura. Ti consigliamo di tenerlo presente se altre configurazioni di replica leggono dallo stesso database di origine.

Versioni

Datastream supporta PostgreSQL versione 10 e successive.

Datastream supporta i seguenti tipi di database PostgreSQL:

  • PostgreSQL self-hosted
  • Cloud SQL per PostgreSQL
  • AlloyDB per PostgreSQL
  • AlloyDB Omni
  • Amazon RDS per PostgreSQL
  • Amazon Aurora PostgreSQL

Livello senza costi

Datastream ti consente di eseguire lo streaming da AlloyDB per PostgreSQL a BigQuery utilizzando il Livello senza costi, che fornisce fino a 100 GiB di dati Change Data Capture senza costi ogni mese. Per saperne di più, consulta i prezzi di Datastream.

Best practice

Questa sezione descrive le best practice consigliate per la configurazione dell'origine PostgreSQL da utilizzare con Datastream.

Utilizza più stream per evitare il blocco head-of-line

Per le origini PostgreSQL, Datastream utilizza un unico slot di replica logica per un intero stream. Una transazione di grandi dimensioni o più aggiornamenti su una tabella ad alto volume possono ritardare la replica dei dati per tutte le altre tabelle nello stesso stream.

Per evitare il blocco head-of-line, crea stream separati per diversi set di tabelle. Ad esempio, puoi creare un flusso per le tabelle con volumi elevati e un altro per le tabelle con volumi ridotti. In questo modo, le tabelle con un tasso di abbandono elevato vengono isolate e non ritardano la replica di altre tabelle.

Consiglio: identifica le tabelle con frequenze di scrittura (INSERT/UPDATE/DELETE) eccezionalmente elevate e inseriscile nel proprio stream Datastream dedicato con uno slot di replica separato.

Evita transazioni a lunga esecuzione

Le transazioni a lunga esecuzione possono causare l'accumulo di log WAL. Poiché il WAL è sequenziale, PostgreSQL non può rimuovere i vecchi file WAL necessari allo slot di replica finché la transazione lunga non viene completata. In questo modo, l'utilizzo del disco WAL aumenta.

Inoltre, questo può rallentare la decodifica logica. Il rallentamento è causato da transazioni di grandi dimensioni che riversano le modifiche sul disco, il che richiede un riassemblaggio lento e ad alta intensità di I/O al momento del commit, bloccando la replica di tutte le transazioni successive. Suggerimento: nel database di origine, configura i parametri statement_timeout e idle_in_transaction_session_timeout per evitare transazioni con tempi di esecuzione lunghi. Per saperne di più, consulta la documentazione di PostgreSQL.

Utilizza il filtro delle tabelle durante la creazione delle pubblicazioni

Se stai replicando le modifiche solo da alcune tabelle, assicurati di creare una PUBLICATION che includa solo queste tabelle. Quando una pubblicazione ha come ambito tabelle specifiche, PostgreSQL conserva in modo efficiente le modifiche solo per queste tabelle nello slot di replica. In questo modo, le dimensioni dello slot di replica vengono ridotte e le prestazioni di decodifica logica migliorano.

Gestisci in modo proattivo gli slot di replica

Datastream utilizza uno slot di replica logica nell'istanza principale di PostgreSQL, che garantisce che i file WAL vengano conservati finché Datastream non conferma che sono stati elaborati. Se uno stream non va a buon fine, viene messo in pausa o eliminato senza eliminare lo slot di replica, PostgreSQL continua a conservare i file WAL a tempo indeterminato. Questo può riempire il disco del server del database e causare un'interruzione della produzione.

Suggerimento: configura un sistema di avvisi efficiente e monitora l'utilizzo del disco WAL sul tuo server PostgreSQL di origine.

Configura correttamente l'identità della replica

L'impostazione REPLICA IDENTITY indica a PostgreSQL quali dati scrivere nel WAL per gli eventi UPDATE e DELETE, consentendo a Datastream di identificare le righe modificate.

Se utilizzi BigQuery come destinazione, evita di impostare REPLICA IDENTITY su FULL. Datastream utilizza le colonne registrate come chiave logica per le operazioni MERGE di BigQuery. Se REPLICA IDENTITY è impostato su FULL e una tabella ha più di 16 colonne, viene superato il limite di 16 colonne di BigQuery per le chiavi primarie nelle operazioni MERGE e lo stream viene interrotto.

Suggerimenti (in ordine di preferenza):

  1. Ottimale:utilizza una chiave primaria. L'impostazione predefinita di REPLICA IDENTITY DEFAULT utilizza automaticamente ed efficacemente la chiave primaria esistente.
  2. Buono: se non esiste una chiave primaria, crea un indice UNIQUE NOT NULL e imposta REPLICA IDENTITY USING INDEX INDEX_NAME.
  3. Opzione meno consigliata: utilizza l'impostazione REPLICA IDENTITY FULL solo per le tabelle senza identificatore univoco. Tieni presente l'impatto sulle prestazioni, il limite di 16 colonne e la limitazione sui tipi di dati supportati per le chiavi primarie se esegui la replica in BigQuery.

Replica dalle repliche di lettura

Datastream supporta la replica da istanze di replica di lettura PostgreSQL per PostgreSQL versione 16 e successive.

Per eseguire la replica da una replica di lettura, devi eseguire i seguenti passaggi di configurazione sull'istanza principale:

  1. Crea pubblicazioni nell'istanza principale: mentre Datastream si connette alla replica di lettura, le pubblicazioni che definiscono i dati da replicare devono essere create nell'istanza principale.
  2. Configura gli heartbeat WAL: Datastream si basa su messaggi di heartbeat WAL periodici per il suo meccanismo di checkpoint. Quando si connette a un'istanza principale, Datastream gestisce la generazione di questi heartbeat. Tuttavia, per una replica di lettura, questi heartbeat devono essere generati esternamente.

Un modo per configurare heartbeat periodici è creare un'attività cron in PostgreSQL utilizzando l'estensione pg_cron:

SELECT cron.schedule_in_database(
    'datastream-heartbeat',             -- Job name
    '* * * * *',                        -- Every minute
   $$SELECT pg_logical_emit_message(true, 'datastream', 'cdc heartbeat')$$,
    'DATABASE_NAME',              -- Change this to your database name
    'USERNAME',                   -- Username to run as
    true                                -- Enabled
);

Sostituisci quanto segue:

  • DATABASE_NAME: il nome del database per cui vuoi generare gli heartbeat.
  • USERNAME: il nome dell'utente con cui eseguire l'attività. In genere postgres.

Limitazioni note

Le limitazioni note per l'utilizzo di Datastream con un database PostgreSQL come origine includono:

  • Gli stream sono limitati a 10.000 tabelle.
  • PostgreSQL rifiuta rigorosamente i byte NULL (0x00) nelle colonne di stringhe UTF-8. Datastream non rimuove i byte NULL. Se una stringa di origine contiene 0x00 byte nulli, il batch di inserimento non riesce e la replica viene interrotta. Ti consigliamo di pulire o sostituire i caratteri CHAR(0) nel database di origine prima della replica.
  • Non puoi configurare gli stream PostgreSQL in modo che inizino dalla posizione più recente.
  • Una tabella con più di 500 milioni di righe non può essere sottoposta a backfill, a meno che non siano soddisfatte le seguenti condizioni:
    1. La tabella ha un indice B-tree univoco.
    2. L'indice non include colonne dei seguenti tipi: DOUBLE, FLOAT, MONEY, REAL, JSON, JSONB, BYTEA, TXID, XML, tipi di dati compositi o tipi di dati geometrici.
    3. Nessuna delle colonne dell'indice è nullable.
    4. Tutte le colonne dell'indice sono in ordine crescente o tutte le colonne dell'indice sono in ordine decrescente.
    5. Tutte le colonne dell'indice sono incluse nello stream.
  • Le tabelle senza chiavi primarie devono avere un'IDENTITÀ REPLICA. In caso contrario, nella destinazione vengono replicati solo gli eventi INSERT.
  • Le tabelle con chiavi primarie non possono avere REPLICA IDENTITY impostato su FULL o NOTHING. Deve essere impostato su DEFAULT.
  • Non tutte le modifiche allo schema di origine possono essere rilevate automaticamente. In questo caso, potrebbe verificarsi un danneggiamento dei dati. Le seguenti modifiche allo schema potrebbero causare il danneggiamento dei dati o la mancata elaborazione degli eventi a valle:
    • Eliminazione delle colonne.
    • Aggiungere colonne al centro di una tabella.
    • Modifica del tipo di dati di una colonna.
    • Riordinamento delle colonne.
    • Eliminare tabelle (pertinente se la stessa tabella viene poi ricreata con l'aggiunta di nuovi dati).
  • Datastream non supporta le colonne dei tipi di dati geometric, come BOX, CIRCLE, LINE, LSEG, PATH, POINT e POLYGON. Queste colonne vengono replicate come NULL.
  • Datastream non supporta le colonne dei tipi di dati range.
  • Datastream non supporta array di tipi di dati non supportati (come i tipi spaziali), array di LTREE, array di tipi di dati definiti dall'utente (incluso ENUM) o array di DATE, TIMESTAMP o TIMESTAMP WITH TIME ZONE (TIMESTAMPTZ). Datastream ignora queste colonne durante la replica.
  • Per gli stream creati prima del 17 febbraio 2026: Datastream non supporta la replica degli eventi UPDATE per le righe che includono valori TOAST nelle colonne che fanno parte dell'identità di replica della tabella. Questi eventi vengono ignorati. Gli stream creati dopo questa data non sono soggetti a questa eccezione.
  • Datastream non supporta la replica di righe che includono valori JSON o JSONB con più di 2950 oggetti nidificati. Gli eventi contenenti questi valori JSON o JSONB non vengono replicati nel database di destinazione.
  • Datastream non supporta la replica di righe che includono valori NaN nelle colonne NUMERIC (precision, scale). I valori in queste colonne vengono sostituiti con i valori NULL.
  • Datastream non supporta la replica di colonne con tipo di dati hstore. I valori di queste colonne vengono sostituiti con i valori NULL.
  • Datastream non supporta la replica di record non ASCII da un database di origine con codifica SQL_ASCII. Questi record vengono ignorati.
  • Datastream non supporta la replica di tabelle con policy di sicurezza a livello di riga (RLS) definite. Per informazioni su come aggirare questa limitazione, consulta Comportamento e limitazioni dell'origine PostgreSQL.
  • Per le colonne di flussi di dati con tipi di dati di lunghezza variabile che utilizzano la tecnica TOAST (The Oversized-Attribute Storage Technique): se un valore TOAST invariato viene rimosso dal log WAL durante un'operazione UPDATE, Datastream esegue una ricerca attiva nel database di origine nel tentativo di recuperare il valore mancante. Pertanto, le modifiche intermedie potrebbero non essere acquisite in scenari che prevedono aggiornamenti rapidi e consecutivi o un'eliminazione rapida dopo un inserimento. Tieni presente che le operazioni DELETE non attivano questa operazione di ricerca attiva. Questa limitazione per le colonne di lunghezza variabile che utilizzano TOAST è particolarmente rilevante quando si utilizza la modalità di scrittura di sola aggiunta, che prevede l'acquisizione di tutte le modifiche intermedie.
  • Datastream non acquisisce le modifiche apportate alle colonne generate.
  • Datastream potrebbe smettere di funzionare o non acquisire nuovi eventi quando viene eseguito un upgrade della versione principale di PostgreSQL sul database. Ti suggeriamo di eliminare gli slot di replica prima dell'upgrade, quindi di eseguire l'upgrade del database e ricreare gli slot di replica. Se gli stream non vanno a buon fine, recuperali specificando il nuovo nome dello slot di replica ed esegui un backfill se è richiesta la coerenza dei dati.
  • Datastream non supporta la replica delle tabelle di sistema PostgreSQL quando utilizzi il flusso di configurazione degli stream automatizzati. Se modifichi lo stream creato utilizzando il flusso automatico e aggiungi tabelle di sistema, Datastream ignora queste tabelle e non replica i dati o le modifiche da queste.

Passaggi successivi