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 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 eseguite al database e consente di utilizzarle ed elaborarle in un formato intuitivo 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.

  • Puoi selezionare tutti gli schemi o schemi specifici di una determinata 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 in una tabella, Datastream considera le colonne specificate come chiavi primarie.
  • Datastream invia periodicamente messaggi heartbeat al database di origine. Di conseguenza, gli eventi di messaggio di decodifica logica (op:"m") vengono inseriti direttamente nel file WAL. Questi messaggi sono richiesti da Datastream per garantire la disponibilità dell'origine e per calcolare l'aggiornamento. 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

Best practice

Questa sezione descrive le best practice consigliate per configurare l'origine PostgreSQL da utilizzare con Datastream.

Utilizza 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 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 per le altre tabelle.

Consiglio:identifica le tabelle con tassi di scrittura eccezionalmente elevati (INSERT/UPDATE/DELETE) 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 WAL (Write-Ahead Log). Poiché WAL è sequenziale, PostgreSQL non può scaricare il WAL finché la transazione lunga non viene completata, anche se vengono utilizzate altre transazioni. Ciò può aumentare le dimensioni dello slot di replica e rallentare la decodifica logica, perché le modifiche apportate a transazioni di lunga durata che si sovrappongono alla transazione corrente devono essere decodificate ripetutamente.

Consiglio:nel database di origine, configura i parametri statement_timeout e idle_in_transaction_session_timeout per evitare transazioni di lunga durata. Per saperne di più, consulta la documentazione di PostgreSQL.

Utilizzare il filtro delle tabelle durante la creazione di pubblicazioni

Se replichi le modifiche solo da alcune tabelle, assicurati di creare un PUBLICATION che includa solo queste tabelle. Quando una pubblicazione è limitata a tabelle specifiche, PostgreSQL conserva 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 primaria PostgreSQL, il 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 indefinitamente. In questo modo, il disco del server di database può riempirsi e causare un'interruzione della produzione.

Suggerimento:configura avvisi efficienti e monitora l'utilizzo del disco WAL sul 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, questo supera il limite di 16 colonne di BigQuery per le chiavi primarie nelle operazioni MERGE e interrompe lo stream.

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 indice UNIQUE NOT NULL e imposta REPLICA IDENTITY USING INDEX INDEX_NAME.
  3. Meno consigliato:utilizza l'impostazione REPLICA IDENTITY FULL solo per tabelle senza identificatore univoco. Tieni presente l'impatto sulle prestazioni e il limite di 16 colonne e la limitazione dei tipi di dati supportati per le chiavi primarie se esegui la replica in BigQuery.

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.
  • Una tabella con più di 500 milioni di righe non può essere compilata a ritroso 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 decrescente.
    5. Tutte le colonne dell'indice sono incluse nel flusso.
  • Le tabelle senza chiavi primarie devono avere un'IDENTITÀ DI 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.
  • Datastream non può eseguire la replica da un'istanza di replica di lettura perché PostgreSQL non supporta la decodifica logica nelle repliche di lettura.
  • 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 potrebbero causare il danneggiamento dei dati o l'impossibilità di elaborare gli eventi a valle:
    • Eliminazione delle colonne.
    • Aggiunta di colonne al centro di una tabella.
    • Modifica del tipo di dati di una colonna.
    • Riordinare le colonne.
    • Eliminazione di 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 array di tipi di dati non supportati, array di tipi di dati definiti dall'utente (incluso ENUM) o array di tipi di dati DATE, TIMESTAMP o TIMESTAMP WITH TIME ZONE. Queste colonne vengono ignorate.
  • 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 eliminati.
  • 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 di queste colonne vengono sostituiti con i valori NULL.
  • Datastream non supporta la replica delle colonne del 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.
  • 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 infine di ricreare gli slot di replica. Se i flussi non vanno a buon fine, recuperali specificando il nuovo nome dello slot di replica ed esegui un backfill se è necessaria la coerenza dei dati.

Passaggi successivi