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.
- È possibile 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.
- Quando è connesso a un'istanza primaria, Datastream invia periodicamente messaggi heartbeat al database di origine. Di conseguenza, gli eventi di 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 per calcolare la freschezza. Quando utilizzi una replica di lettura come origine, devi configurare i messaggi heartbeat esternamente. Per ulteriori informazioni, consulta Replica dalle 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, fornendo fino a 100 GiB di dati Change Data Capture (CDC) senza costi ogni mese. Per saperne di più, consulta la pagina Prezzi di Datastream.
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 stream per le tabelle con volumi bassi. In questo modo, le tabelle con churn 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.
Evitare transazioni a lunga esecuzione
Le transazioni a lunga esecuzione possono causare l'accumulo di log write-ahead (WAL). Poiché WAL è sequenziale, PostgreSQL non può rimuovere i vecchi file WAL necessari allo slot di replica finché la transazione a lunga esecuzione 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 a elevato utilizzo 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 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, 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.
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 BigQuery MERGE. 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 il flusso viene interrotto.
Consigli (in ordine di preferenza):
- Ottimale:utilizza una chiave primaria. L'impostazione predefinita di
REPLICA IDENTITY DEFAULTutilizza automaticamente ed efficientemente la chiave primaria esistente. - Buono:se non esiste una chiave primaria, crea un indice
UNIQUE NOT NULLe impostaREPLICA IDENTITY USING INDEX INDEX_NAME. - Meno consigliato:utilizza l'impostazione
REPLICA IDENTITY FULLsolo 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.
Replica dalle repliche di lettura
Datastream supporta la replica dalle 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:
- Crea pubblicazioni sull'istanza principale: mentre Datastream si connette alla replica di lettura, le pubblicazioni che definiscono i dati da replicare devono essere create sull'istanza principale.
- Configura i heartbeat WAL: Datastream si basa su messaggi heartbeat WAL periodici per il meccanismo di checkpoint. Quando ti connetti 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 i 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 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.
- Una tabella con più di 500 milioni di righe non può essere riempita a meno che non siano soddisfatte le seguenti condizioni:
- La tabella ha un indice B-tree univoco.
- 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. - Nessuna delle colonne dell'indice può ammettere valori nulli.
- Tutte le colonne dell'indice sono in ordine crescente oppure tutte le colonne dell'indice sono in ordine decrescente.
- 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
FULLoNOTHING. Deve essere impostato suDEFAULT. - 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.
- 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 array di tipi di dati non supportati, array di tipi di dati definiti dall'utente (incluso
ENUM) o array di tipi di datiDATE,TIMESTAMPoTIMESTAMP 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à di replica della tabella. Questi eventi vengono eliminati. Gli stream creati dopo questa data non sono soggetti a questa eccezione.
- Datastream non supporta la replica di righe che includono valori
JSONoJSONBcon più di 2950 oggetti nidificati. Gli eventi contenenti questi valoriJSONoJSONBnon vengono replicati nel database di destinazione. - Datastream non supporta la replica di righe che includono valori
NaNnelle colonneNUMERIC (precision, scale). I valori di queste colonne vengono sostituiti con i valoriNULL. - 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.
- Datastream non supporta la replica delle tabelle di sistema PostgreSQL quando utilizzi il flusso di configurazione automatica dello stream. Se modifichi lo stream che hai creato utilizzando il flusso automatico e aggiungi tabelle di sistema, Datastream le ignora automaticamente e non replica dati o modifiche.
Passaggi successivi
- Scopri come configurare un'origine PostgreSQL per l'utilizzo con Datastream.