Diagnostica dei problemi

Lo stream potrebbe generare errori durante l'esecuzione.

  • Alcuni errori, ad esempio una password errata nel database di origine, sono recuperabili, il che significa che possono essere corretti e lo stream riprende automaticamente.
  • Gli errori possono interessare un singolo oggetto, ad esempio un evento contenente tipi di dati non supportati. Altri errori possono influire su più oggetti o sull'intero stream, ad esempio quando Datastream non riesce a connettersi al database di origine.
  • A seconda dell'errore, le informazioni vengono fornite nelle pagine Stream o Dettagli stream dell'interfaccia utente di Datastream. Puoi anche utilizzare le API di Datastream per recuperare informazioni sull'errore.

Per risolvere un problema, vai allo stream per visualizzare l'errore e segui i passaggi descritti nel messaggio.

Questa pagina contiene informazioni su errori di configurazione, connettività, Oracle e MySQL, nonché i passaggi per la risoluzione dei problemi.

Errori di configurazione e connettività

Errore Passaggi per la risoluzione dei problemi
Errore di connessione al database di origine (generico).

Questo può accadere per vari motivi. Per risolvere il problema, svolgi le seguenti azioni:

  1. Assicurati che il database di origine sia attivo e raggiungibile.
  2. Vai al profilo di connessione di origine dalle pagine Stream o Profili di connessione.
  3. Verifica che le informazioni sulla connettività del profilo di connessione siano corrette.
  4. Verifica che il nome utente e la password corrispondano.
  5. Verifica che il nome utente esista nel database e disponga dei privilegi necessari.
  6. Salva le modifiche apportate nella pagina Profili di connessione.

Lo stream riprende automaticamente.
Impossibile connettersi al database di origine (lista consentita IP). Questo può accadere se il metodo di connettività scelto è Lista consentita IP, ma uno o più indirizzi IP in uscita di Datastream non sono stati aggiunti correttamente al database di origine. Assicurati che gli indirizzi IP in uscita visualizzati nel profilo di connessione di Datastream siano configurati sul firewall di rete in modo che il server di database di origine possa accettare connessioni da questi indirizzi IP. Una volta risolto il problema, lo stream riprende automaticamente.
Connessione non riuscita al database di origine (tunnel SSH di forwarding). Ciò può accadere se si verifica un problema con il tunnel SSH di forwarding. Controlla lo stato del tunnel. Se il tunnel è fermo, deve essere avviato. Una volta risolto il problema, lo stream riprende automaticamente.
Datastream non può connettersi a un bastion host tramite un tunnel SSH di forwarding. Verifica che la configurazione del tunnel SSH per il forwarding sia corretta nel profilo di connessione di origine e che la porta sul server del tunnel SSH sia aperta.
Impossibile connettersi al database di origine a causa di certificati errati. Ciò può accadere se si verifica un problema con i certificati forniti durante la definizione del profilo di connessione di origine. Vai alla pagina Profili di connessione e seleziona il profilo di connessione specificato. Verifica che i certificati siano configurati correttamente. Dopo aver apportato le modifiche, salva il profilo di connessione e lo stream riprende automaticamente.
Errore durante l'utilizzo della connettività privata per la connessione al database di origine.
  1. Assicurati di aver completato tutti i prerequisiti descritti nella sezione Prima di iniziare.

  2. Dopo aver creato la configurazione di connettività privata, verifica che la route contenente l'indirizzo IP interno del database sia visualizzata nella scheda Route esportate della pagina Peering di rete VPC.

    Per farlo, vai alla pagina Peering di rete VPC e cerca il peering aggiunto (il nome è peering-[UUID]). La route si trova nella scheda Route esportate. Se questo percorso non esiste, aggiungilo manualmente.

  3. Datastream non controlla la sovrapposizione con i route di peering dinamico. Fornire una subnet che si sovrappone a una route dinamica può causare problemi di connettività. Pertanto, non è consigliabile utilizzare una subnet che fa parte di una route dinamica.
  4. Assicurati che le route personalizzate per gli intervalli di indirizzi IP di Datastream siano pubblicizzate correttamente. Se le route personalizzate non sono presenti, consulta Route annunciate personalizzate.
  5. Se i problemi di connessione al database di origine persistono, consulta Configurare un proxy inverso.
Il tipo di connettività STATIC_SERVICE_IP_CONNECTIVITY non è consentito se i vincoli dei criteri dell'organizzazione/datastream.disablePublicConnectivity sono attivi.

Hai selezionato la lista consentita di IP pubblici o il tunnel SSH di inoltro come metodo di connettività di rete per il profilo di connessione che stai creando. Tuttavia, il criterio dell'organizzazione Blocca metodi di connettività pubblica per Datastream è attivo. Pertanto, non puoi selezionare metodi di connettività pubblica per il tuo profilo di connessione.

Per risolvere il problema, seleziona il metodo di connettività di rete peering VPC privato o disattiva il criterio dell'organizzazione.

Per disattivare i criteri dell'organizzazione:

  1. Vai alla pagina Criteri dell'organizzazione nella Google Cloud Console.
  2. Seleziona il criterio dell'organizzazione Datastream - Metodi di blocco della connettività pubblica.

  3. Fai clic su MODIFICA.

  4. Nella sezione Applica a della pagina, seleziona Personalizza.

  5. Nella sezione Applicazione, seleziona Off.

  6. Fai clic su SALVA.
  7. Torna al profilo di connessione Oracle che stai creando e fai clic su CREA.
Quando configuro il database di origine per il mio stream, non riesco a trovare le tabelle e gli schemi che voglio trasferire nell'elenco degli oggetti da includere.

Questo può accadere se il database contiene migliaia di tabelle e schemi. Alcuni potrebbero non essere inclusi nell'elenco degli oggetti da estrarre durante la configurazione dell'origine per lo stream nella console Google Cloud. Anziché selezionare Schemmi e tabelle specifici nella sezione Seleziona gli oggetti da includere, seleziona Personalizzato. Nel campo Criteri di corrispondenza degli oggetti, inserisci gli schemi e le tabelle che vuoi che Datastream estragga.
Ho aggiunto più tabelle al mio stream utilizzando il menu Oggetti da includere. Tuttavia, quando esamino la scheda Objects (Oggetti) in Stream details (Dettagli stream), noto che alcune tabelle mancano. Assicurati che esista almeno un aggiornamento CDC per ciascuna di queste tabelle in modo che Datastream possa riconoscere le modifiche e includere automaticamente le tabelle nello stream.
Impossibile caricare l'elenco di oggetti quando si utilizza il menu Oggetti da includere nella console Google Cloud. Questo può accadere se il database contiene più di 5000 schemi e tabelle. Utilizza un metodo diverso per specificare gli oggetti da includere o utilizza l'API Datastream. Per ulteriori informazioni, consulta Configurare i database di origine.
Eventi eliminati durante lo streaming e non replicati nella destinazione.

Datastream potrebbe eliminare gli eventi non supportati durante lo streaming. Per risolvere il problema, puoi eseguire le seguenti azioni:

  • Attiva manualmente un backfill dell'intera tabella. Questo funziona se gli eventi eliminati sono solo eventi UPSERT. Se gli eventi eliminati includono eventi DELETE, devi troncare la tabella in BigQuery prima di eseguire il backfill.

    Per informazioni su come eseguire un backfill, consulta Avvia backfill.

  • Contatta l'Assistenza Google e chiedi di eseguire un backfill parziale. Questo è possibile solo se puoi identificare gli eventi eliminati con una clausola WHERE SQL e se nessuno degli eventi è un evento DELETE.
  • Ignora il problema se il numero di eventi eliminati è basso o se gli eventi eliminati non sono significativi.

Errori Oracle

Errore Passaggi per la risoluzione dei problemi
Il logging supplementare non è configurato correttamente nel database di origine.

Può verificarsi un errore durante il recupero dei dati in corso di Change Data Capture (CDC) se la configurazione del logging supplementare non è corretta nel database di origine. Verifica che il logging supplementare sia configurato correttamente. In particolare, verifica che il logging supplementare sia attivo per le tabelle di database in streaming dall'origine alla destinazione. Lo stream riprende automaticamente.
Impossibile riprendere la replica perché la posizione del log è andata persa. Questo errore può verificarsi quando il processo di replica viene messo in pausa per molto tempo, con conseguente perdita della posizione del log. Gli stream non devono essere messi in pausa per periodi di tempo che si avvicinano al periodo di conservazione dei log. Ricrea lo stream.
I file di log sono mancanti, parzialmente o del tutto.

I file di log potrebbero essere stati eliminati. Oracle esegue la purga dei file di log appena possibile, a meno che non specifichi un periodo di rotazione minimo per mantenerli. Nel server Oracle, imposta per quanto tempo devono essere conservati i file di log. Ad esempio, utilizza CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 4 DAYS; per conservare i file di log per almeno 4 giorni.

Per un deployment RDS, utilizza exec rdsadmin.rdsadmin_util.set_configuration('archivelog retention hours',96);
L'elenco di esclusione comprende l'elenco di inclusione. L'elenco di inclusione è totalmente contenuto nell'elenco di esclusione, quindi l'elenco di oggetti che Datastream estrae dall'origine è vuoto. Modifica la selezione degli oggetti e riprova.
La modalità di logging per il database Oracle non è impostata su ARCHIVELOG. Cambia la modalità di logging e riprova.
Datastream restituisce un messaggio di errore ORA-00942: table or view does not exist, ma tutto è configurato correttamente. Questo può essere il risultato della memorizzazione nella cache sul server Oracle. La ricreazione dell'utente del database dovrebbe risolvere il problema della memorizzazione nella cache.
Le modifiche a un'origine Oracle non vengono applicate alla destinazione quando lo stream è già in esecuzione. Poiché Datastream legge i file di log di ripetizione archiviati, le modifiche apportate all'origine non vengono applicate alla destinazione finché il log non viene archiviato. Per visualizzare le modifiche nella destinazione, modifica il criterio di archiviazione dei log o forza manualmente un trasferimento dei log. Per ulteriori informazioni, vedi Utilizzare i file di log di ripetizione del database Oracle.
Si è verificato un errore interno imprevisto. Per maggiori dettagli, contatta l'Assistenza Google.

Errori MySQL

Errore Passaggi per la risoluzione dei problemi
Binlog non è configurato correttamente nel database di origine.

Questo può accadere per gli stream MySQL continui se la configurazione del binlog non è corretta nel database di origine. Per risolvere il problema, svolgi le seguenti azioni:

  1. Verifica che il file binlog sia configurato correttamente.
  2. Verifica che il formato del log binario del database MySQL sia impostato su ROW.
  3. Riavvia lo stream.
Impossibile riprendere la replica perché la posizione del log binario è andata persa. Questo errore può verificarsi quando il processo di replica viene messo in pausa per molto tempo, il che comporta la perdita della posizione del file binlog. Gli stream non devono essere messi in pausa per periodi di tempo che si avvicinano al periodo di conservazione dei log bin. Ricrea lo stream.
Impossibile eseguire lo stream a causa di versioni del database di origine e di destinazione incompatibili.

Ciò può accadere quando il database di origine non è conforme alla matrice di supporto delle versioni. Per risolvere il problema, svolgi le seguenti azioni:

  1. Assicurati che il database di origine rispetti la matrice.
  2. Ricrea lo stream con il database di origine aggiornato.
I binlog di origine MySQL di AWS RDS sono mancanti, parzialmente o del tutto. I file binlog potrebbero essere stati eliminati. AWS RDS esegue la pulizia dei file di log binari non appena possibile, a meno che non specifichi un periodo di rotazione minimo per mantenerli. Nell'istanza MySQL AWS RDS di origine, imposta il periodo di conservazione dei log binari in ore. Ad esempio, utilizza mysql.rds_set_configuration('binlog retention hours', 168); per conservare i file binlog per almeno 7 giorni.
L'elenco di esclusione comprende l'elenco di inclusione. L'elenco di inclusione è totalmente contenuto nell'elenco di esclusione, quindi l'elenco di oggetti che Datastream estrae dall'origine è vuoto. Modifica la selezione degli oggetti e riprova.
Datastream non può replicare un database MySQL. Assicurati che Datastream disponga delle autorizzazioni per replicare il database.
Quando crei un profilo di connessione per un'origine MySQL, nel menu Tipo di crittografia non sono accettati più certificati SSL codificati in PEM. Datastream non supporta le catene di certificati SSL nei profili di connessione MySQL. Sono supportati solo certificati singoli x509 con codifica PEM.
Latenza elevata durante lo streaming da un'origine MySQL.

Aumenta la capacità di Datastream di leggere dal database di origine:
Convalida della configurazione CDC di MySQL non riuscita. Il database di origine non è stato configurato per il metodo CDC selezionato. Seleziona un altro metodo o completa la configurazione per il metodo CDC. Per maggiori dettagli, vedi Configurare un database MySQL di origine.
Si è verificato un errore interno imprevisto. Per maggiori dettagli, contatta l'Assistenza Google.

Errori PostgreSQL

Errore Passaggi per la risoluzione dei problemi
La decodifica logica non è configurata correttamente nel database di origine.

Verifica che la decodifica logica sia configurata correttamente. Consulta Configurare un database PostgreSQL di origine.
L'area di replica non esiste. Se lo slot di replica non esiste nel database, può verificarsi un errore durante il recupero dei dati in corso del CDC (Change Data Capture). Verifica che lo slot di replica sia configurato correttamente. Consulta Configurare un database PostgreSQL di origine.
Lo slot di replica è configurato con un plug-in errato. Questo errore può verificarsi se lo slot di replica è configurato con un plug-in diverso da pgoutput. Verifica che lo slot di replica sia configurato correttamente. Per ulteriori informazioni, consulta Database PostgreSQL di origine.
Lo slot di replica è attivo in un processo diverso. Questo errore può verificarsi quando lo slot di replica è in uso da un altro processo. Gli slot di replica possono essere utilizzati da un solo processo alla volta. Assicurati di non utilizzare lo stesso slot di replica in nessun altro processo, ad eccezione di Datastream.
La pubblicazione non è configurata correttamente. Questo errore può verificarsi quando la pubblicazione non è configurata per esporre le tabelle incluse nella configurazione dello stream. Verifica che la pubblicazione sia configurata correttamente. Consulta Configurare le informazioni sul database di origine per lo stream.
La pubblicazione non esiste. Questo errore può verificarsi se la pubblicazione non esiste nel database. Verifica che la pubblicazione sia configurata correttamente. Consulta Configurare un database PostgreSQL di origine.
Impossibile riprendere la replica perché i file WAL sono stati persi. Questo errore può verificarsi quando il processo di replica viene messo in pausa per molto tempo, causando la perdita dei file WAL. Gli stream non devono essere messi in pausa per periodi di tempo che si avvicinano al periodo di conservazione dei file WAL. Ricrea lo stream.
L'elenco di esclusione comprende l'elenco di inclusione. L'elenco di inclusione è totalmente contenuto nell'elenco di esclusione, quindi l'elenco di oggetti che Datastream estrae dall'origine è vuoto. Modifica la selezione degli oggetti e riprova.
Datastream non può replicare uno schema PostgreSQL. Assicurati che Datastream disponga delle autorizzazioni per replicare lo schema.
Le transazioni di grandi dimensioni nel database di origine causano problemi di replica e sincronizzazione dei dati. Se inserisci, aggiorni o elimini un numero significativo di record nel database di origine, lo slot di replica potrebbe essere sovraccaricato dagli eventi corrispondenti. Datastream ha bisogno di tempo per leggere ed elaborare questi eventi. Poiché gli slot di replica PostgreSQL sono a thread singolo, l'elaborazione di altre modifiche nello slot di replica, incluse le modifiche ai dati in altre tabelle, viene ritardata fino a quando Datastream non recupera tutte le modifiche nello slot di replica.
Le transazioni di grandi dimensioni sul database di origine causano una bassa velocità effettiva del CDC. Datastream non supporta il CDC multithread in PostgreSQL. Per superare questa limitazione e aumentare il throughput del CDC, puoi suddividere l'origine in più stream, ciascuno con il proprio slot di pubblicazione e replica. Ad esempio, potresti voler creare uno stream per la tabella più grande del database e un altro per tutte le altre tabelle oppure uno stream per le tabelle con la massima priorità e un altro per le restanti. I casi d'uso possono variare, quindi devi considerare quello più adatto al tuo specifico scenario di CDC. Per informazioni sulla creazione di una pubblicazione, consulta Configurare un database PostgreSQL di origine.
Eventi non supportati eliminati con codice motivo: BIGQUERY_TOO_MANY_PRIMARY_KEYS. Quando l'identità della replica PostgreSQL per una tabella è impostata su FULL, Datastream tratta tutte le colonne di questa tabella come chiavi primarie. Se la tabella contiene più di 16 colonne, viene violata la limitazione della CDC di BigQuery e si verifica l'errore. Per risolvere il problema, svolgi i seguenti passaggi:
  1. Modifica l'identità della replica in DEFAULT: 
    ALTER TABLE TABLE_NAME REPLICA IDENTITY DEFAULT
     Sostituisci TABLE_NAME con il nome della tabella per cui vuoi modificare l'identità della replica.
  2. Rimuovi la tabella dall'elenco di oggetti da includere dello stream. Per ulteriori informazioni, consulta Modificare le informazioni di configurazione del database di origine.
  3. Elimina la tabella da BigQuery. Per ulteriori informazioni, consulta Eliminare le tabelle.
  4. In Datastream, aggiungi di nuovo la tabella allo stream modificando la configurazione dell'origine.
Si è verificato un errore interno imprevisto. Per maggiori dettagli, contatta l'Assistenza Google.

Errori di SQL Server

Errore Passaggi per la risoluzione dei problemi
La tecnologia CDC è disabilitata per il database DATABASE_NAME.

La tecnologia Change Data Capture (CDC) deve essere abilitata per il database. Datastream ha bisogno di accesso in lettura diretto ai log delle transazioni per replicare le modifiche in tempo reale al database di origine e per ottenere informazioni complete sui log. Abilita la copia dei dati dal canale per il database e riprova.

Per informazioni su come attivare la tecnologia CDC per un database, consulta Configurare un database SQL Server di origine.
Tabelle con la CDC disabilitata.

La funzionalità Change Data Capture (CDC) deve essere abilitata per tutte le tabelle incluse nello stream. Datastream ha bisogno di accesso in lettura diretto ai log delle transazioni per replicare le modifiche in tempo reale alle tabelle di origine e per ottenere informazioni complete sui log. Abilita la CDC per le tabelle incluse nello stream e riprova.

Per informazioni su come attivare la funzionalità CDC per le tabelle di origine, consulta Configurare un database SQL Server di origine.
Autorizzazioni mancanti. Datastream non dispone delle autorizzazioni necessarie per leggere dall'origine. Concedi i privilegi appropriati all'account utente utilizzato per la connessione al tuo database e riprova.
La versione SQL Server EDITION_NAME non è supportata. Datastream non supporta questa versione di SQL Server. Per ulteriori informazioni sulle versioni supportate di SQL Server, consulta la Panoramica di SQL Server come origine.
La versione SQL Server VERSION_NAME dell'edizione Standard non è supportata. Datastream non supporta questa versione dell'edizione Standard di SQL Server. Per ulteriori informazioni sulle versioni supportate di SQL Server, consulta la Panoramica di SQL Server come origine.
Configurazione CDC di SQL Server: non riuscita. Il metodo CDC selezionato non è conforme alla configurazione del database. Modifica il metodo CDC e riprova.

Errori BigQuery

Errore Passaggi per la risoluzione dei problemi
BIGQUERY_UNSUPPORTED_PRIMARY_KEY_CHANGE, details: Failed to write to BigQuery due to an unsupported primary key change: adding primary keys to existing tables is not supported. Se la chiave primaria cambia nell'origine, devi eliminare la tabella in BigQuery e avviare di nuovo il backfill. Si tratta di una limitazione di BigQuery, perché non è possibile garantire l'unione corretta dei nuovi eventi con le righe esistenti se la chiave primaria è diversa. Per ulteriori informazioni, consulta Configurare una destinazione BigQuery.
La tabella BigQuery di destinazione ha molti più record rispetto alla tabella di origine. Ciò può accadere quando la tabella di origine non ha una chiave primaria. In questo caso, Datastream elabora la tabella in modalità di scrittura solo di accodamento e ogni evento per una determinata riga viene visualizzato come riga separata in BigQuery.
I dati vengono duplicati quando viene eseguito il backfill nella modalità di scrittura Solo accodamento.

Quando selezioni la modalità di scrittura Solo accodamento per lo stream, i dati vengono aggiunti in BigQuery come stream di eventi INSERT, UPDATE-INSERT, UPDATE-DELETE e DELETE, senza alcun consolidamento. Ciò potrebbe causare la scrittura di righe duplicate in BigQuery quando esegui il backfill o quando si verifica un problema e lo scrittore BigQuery riprova le operazioni di scrittura. Per risolvere il problema, ti consigliamo di eseguire regolarmente una query di deduplica simile alla seguente:

SELECT * FROM (SELECT *, row_number() OVER (PARTITION BY datastream_metadata.uuid) AS num FROM TABLE_NAME) WHERE num=1
Datastream è configurato per la modalità di scrittura dell'unione, ma le modifiche non vengono unite in BigQuery.

Verifica che nella tabella di origine sia presente una chiave primaria. BigQuery ne ha bisogno per unire le modifiche alla tabella di destinazione.

Se non è presente una chiave primaria, valuta la possibilità di aggiungerne una nella tabella di origine o di destinazione. Per aggiungere una chiave primaria nella tabella BigQuery di destinazione:

  1. Metti in pausa lo stream.
  2. Tronca la tabella in BigQuery.
  3. Aggiungi la chiave primaria alla definizione della tabella.
  4. Riprendi lo stream.
  5. Attiva il backfill per la tabella.
Impossibile aggiungere una chiave primaria, rimuovere una chiave primaria o modificare la definizione della chiave primaria per una tabella già replicata in BigQuery.

Per impostazione predefinita, Datastream non supporta l'aggiunta di una chiave primaria a una tabella già replicata in BigQuery senza una chiave primaria o la rimozione di una chiave primaria da una tabella replicata in BigQuery con una chiave primaria. Tuttavia, puoi modificare la definizione della chiave primaria per una tabella di origine replicata in BigQuery che ha già una chiave primaria:

  1. Controlla la metrica della latenza totale per lo stream e attendi almeno il tempo della latenza corrente per assicurarti che tutti gli eventi in transito vengano scritti nella destinazione. In questo modo, tutti gli eventi con la chiave primaria originale possono essere trasmessi in streaming correttamente.
  2. Metti in pausa lo stream.
  3. Copia il comando CREATE TABLE DDL (Data Definition Language) per la tabella in BigQuery: 
        SELECT ddl FROM PROJECT_ID.DATASET.INFORMATION_SCHEMA.TABLES
      WHERE table_name='TABLE_NAME';

    Sostituisci quanto segue:

    • PROJECT_ID: l'identificatore del tuo progetto Google Cloud.
    • DATASET_ID: l'identificatore del set di dati in BigQuery.
    • TABLE_NAME: il nome della tabella per cui vuoi copiare il comando DDL.
  4. Elimina la tabella in BigQuery.
  5. Modifica il comando DDL CREATE TABLE con le nuove chiavi principali. Includi le chiavi di partizione e cluster e max_staleness OPTION: 
        CREATE TABLE `[PROJECT_ID].[DATASET_ID].[TABLE_NAME]`
    (
      product_id INT64 NOT NULL,
      product_name STRING,
      datastream_metadata STRUCT,
      PRIMARY KEY (product_id) NOT ENFORCED
    )
    CLUSTER BY dept_no
    OPTIONS(
      max_staleness=INTERVAL '0-0 0 0:MINS:0' YEAR TO SECOND
    );
    ;

    Sostituisci quanto segue:

    • PROJECT_ID: l'identificatore del tuo progetto Google Cloud.
    • DATASET_ID: l'identificatore del set di dati in BigQuery.
    • TABLE_NAME: il nome della tabella per cui hai copiato il comando DDL.
    • MINS: il numero di minuti da impostare per l'opzione max_staleness, ad esempio 15.
  6. Esegui la query modificata per ricreare la tabella in BigQuery.
  7. Riprendi lo stream.
  8. Avvia il backfill della tabella.

Passaggi successivi