Trasmettere dati in streaming dai database PostgreSQL

Questa sezione contiene informazioni su:

  • Il comportamento di Datastream nella gestione dei dati estratti da un database PostgreSQL di origine
  • Le versioni del database PostgreSQL supportate da Datastream
  • Una panoramica su come configurare un database PostgreSQL di origine in modo che i dati possano essere trasmessi in streaming da questo a una destinazione
  • Limitazioni note per l'utilizzo del database PostgreSQL come origine

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 utilizzare ed elaborare queste modifiche in un formato di facile utilizzo tramite 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 una determinata origine PostgreSQL, nonché tutte le tabelle dello schema o tabelle specifiche.
  • Viene eseguita la replica di tutti i dati storici.
  • Viene eseguita la replica di tutte le modifiche del data manipulation language (DML), come inserimenti, aggiornamenti ed eliminazioni dai database e dalle tabelle specificati.
  • Viene eseguita la replica solo delle modifiche di cui è stato eseguito il commit.
  • Se definisci un REPLICA IDENTITY in una tabella, Datastream tratta le colonne specificate come chiavi primarie.
  • Quando è connesso a un'istanza principale, Datastream invia periodicamente messaggi heartbeat al database di origine. Di conseguenza, gli eventi dei messaggi di decodifica logica (op:"m") vengono inseriti direttamente nel file WAL. Questi messaggi sono necessari a Datastream per garantire la disponibilità dell'origine e calcolare l'aggiornamento. Quando utilizzi una replica di lettura come origine, devi configurare i messaggi heartbeat esternamente. Per ulteriori informazioni, consulta Replica da repliche di lettura. Ti consigliamo di tenerne conto 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 di Change Data Capture senza costi ogni mese. Per ulteriori informazioni, consulta Prezzi di Datastream.

Best practice

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

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

Per le origini PostgreSQL, Datastream utilizza un singolo 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 uno stream per le tabelle ad alto volume e un altro stream per le tabelle a basso volume. In questo modo, le tabelle ad alta frequenza di modifiche vengono isolate e non ritardano la replica per le altre tabelle.

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

Evitare transazioni a lunga esecuzione

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

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 intensivo di I/O al momento del commit, bloccando la replica di tutte le transazioni successive. Consiglio: nel database di origine, configura i parametri statement_timeout e idle_in_transaction_session_timeout per evitare transazioni a lunga esecuzione. Per ulteriori informazioni, consulta la documentazione di PostgreSQL.

Utilizzare il filtro delle tabelle durante la creazione delle pubblicazioni

Se esegui la replica delle modifiche solo da alcune tabelle, assicurati di creare una PUBLICATION che includa solo queste tabelle. Quando una pubblicazione è limitata a tabelle specifiche, PostgreSQL persiste in modo efficiente le modifiche solo per queste tabelle nello slot di replica. Ciò consente di ridurre le dimensioni dello slot di replica e migliorare le prestazioni di decodifica logica.

Gestire 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 riesce, 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 di database e causare un'interruzione della produzione.

Consiglio: configura avvisi efficienti e monitora l'utilizzo del disco WAL sul server PostgreSQL di origine.

Configurare 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.

Consigli (in ordine di preferenza):

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

Replica da repliche di lettura

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

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

  1. Crea pubblicazioni nell'istanza principale: mentre Datastream si connette alla replica di lettura, le pubblicazioni che definiscono i dati di cui eseguire la replica devono essere create nell'istanza principale.
  2. Configura gli heartbeat WAL: Datastream si basa su messaggi heartbeat WAL periodici per il 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 gli 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 il quale 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.
  • Non è possibile eseguire il backfill di una tabella con più di 500 milioni di righe, 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 può ammettere valori nulli.
    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 REPLICA IDENTITY. In caso contrario, nella destinazione viene eseguita la replica solo degli 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, nel qual caso potrebbe verificarsi un danneggiamento dei dati. Le seguenti modifiche allo schema possono causare il danneggiamento dei dati o l'impossibilità di elaborare gli eventi downstream:
    • Eliminare colonne.
    • Aggiungere colonne al centro di una tabella.
    • Modificare il tipo di dati di una colonna.
    • Riordinare le 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.
  • Datastream non supporta le colonne dei tipi di dati range.
  • Datastream non supporta gli array di tipi di dati non supportati, gli array di tipi di dati definiti dall'utente (incluso ENUM) o gli array di tipi di dati DATE, TIMESTAMP o TIMESTAMP WITH TIME ZONE. Queste colonne vengono ignorate.
  • 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à della replica della tabella. Questi eventi vengono ignorati. Gli stream creati dopo questa data non sono soggetti a questa eccezione.
  • Datastream non supporta la replica delle 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 delle righe che includono valori NaN nelle colonne NUMERIC (precision, scale). I valori in queste colonne vengono sostituiti con valori NULL.
  • Datastream non supporta la replica delle colonne del tipo di dati hstore. I valori in queste colonne vengono sostituiti con valori NULL.
  • Datastream non supporta la replica dei record non ASCII da un database di origine con codifica SQL_ASCII. Questi record vengono ignorati.
  • Datastream non supporta la replica delle 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.
  • Quando esegue lo streaming di colonne con tipi di dati a lunghezza variabile che utilizzano la tecnica di archiviazione degli attributi di grandi dimensioni (TOAST), Datastream deve eseguire una query sul database di origine per recuperare i valori mancanti in un determinato momento (in un processo di ricerca attivo chiamato integrazione) se un valore TOAST invariato viene eliminato dal log WAL durante un'operazione UPDATE. Poiché Datastream esegue lo streaming di queste colonne eseguendo una query sul database, le modifiche intermedie potrebbero non essere acquisite in scenari che coinvolgono aggiornamenti rapidi e consecutivi o un'eliminazione rapida dopo un inserimento. Tieni presente che le operazioni DELETE non attivano l'integrazione. Questa limitazione è particolarmente rilevante quando si utilizza la modalità di scrittura solo in 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 nel database. Ti consigliamo di eliminare gli slot di replica prima dell'upgrade, quindi di eseguire l'upgrade del database e poi di ricreare gli slot di replica. Se gli stream non riescono, recupera lo stream 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 si utilizza il flusso di configurazione automatica dello stream. Se modifichi lo stream creato utilizzando il flusso automatico e aggiungi tabelle di sistema, Datastream ignora queste tabelle e non esegue la replica di dati o modifiche da queste.

Passaggi successivi