Google utilizza la tecnologia AI per tradurre i contenuti nella tua lingua preferita. Le traduzioni generate dall'AI potrebbero contenere errori.

Best practice generali per l'utilizzo di Datastream

Per mantenere una replica affidabile e ridurre al minimo i tempi di inattività in Datastream, puoi applicare le best practice operative ai tuoi stream e ai database di origine. Queste pratiche ti aiutano a cambiare il database di origine di uno stream, configurare gli avvisi sulle metriche, risolvere i problemi di latenza e pianificare i limiti delle tabelle per stream.

Cambiare il database di origine di uno stream

In alcuni casi, potrebbe essere necessario modificare il database di origine di uno stream. Ad esempio, potrebbe essere necessario modificare lo stream per eseguire la replica da una replica anziché dall'istanza del database primario.

Crea un profilo di connessione per l'istanza di replica.
Crea uno stream utilizzando il profilo di connessione per la replica che hai creato e il profilo di connessione esistente per la destinazione.
Avvia lo stream con il backfill storico disattivato. Quando lo stream viene avviato, recupera solo i dati dai log binari.
(Facoltativo) Dopo l'esecuzione dello stream, modificalo per attivare il backfill automatico. Una volta avviato lo stream, modificalo per attivare il backfill automatico.
Metti in pausa lo stream che legge dall'istanza principale.
(Facoltativo) Elimina lo stream che trasmetteva i dati dall'istanza principale. Elimina lo stream che trasmetteva dati dall'istanza principale.
(Facoltativo) Elimina il profilo di connessione per l'istanza principale. Elimina il profilo di connessione per l'istanza principale.

Avvisi e monitoraggio in Datastream

La dashboard di Datastream contiene una grande quantità di informazioni. Queste informazioni possono essere utili per il debug. Ulteriori informazioni sono disponibili nei log, che sono disponibili in Cloud Logging.

Avvisi di Datastream

Non è configurato alcun avviso predefinito per Datastream. Ad esempio, puoi creare una criterio di avviso per la metrica Aggiornamento dei dati facendo clic sul link Crea policy di avviso nella scheda Panoramica. Per le metriche rimanenti, segui questi passaggi:

Nella Google Cloud console, vai alla pagina Avvisi:

Vai ad Avvisi
Fai clic su Crea policy.
Fai clic sul menu a discesa Seleziona una metrica.
Nel campo del filtro, inserisci Datastream.
(Facoltativo) Potrebbe essere necessario disattivare il filtro Attivo per visualizzare tutte le metriche disponibili.
Cerca la metrica che vuoi monitorare in Stream Datastream.
Fai clic su Applica.
(Facoltativo) Inserisci i dettagli richiesti nelle sezioni Aggiungi filtri e Trasforma dati. Fai clic su Avanti.
Inserisci le informazioni richieste nella sezione Configura trigger di avviso. Fai clic su Avanti.
Configura le notifiche nella sezione Configura le notifiche e finalizza l'avviso.
Esamina l'avviso e fai clic su Crea policy quando è tutto pronto.

Per informazioni dettagliate su come completare ciascuno di questi passaggi, consulta Creare una policy di avviso.

Ti consigliamo di creare avvisi per le seguenti metriche di Datastream:

Aggiornamento dei dati
Conteggio eventi non supportati dallo stream
Latenze totali dello stream

Un avviso su una di queste metriche può indicare un problema con lo stream o con il database di origine.

Informazioni sulla latenza

Datastream fornisce le seguenti metriche per aiutarti a comprendere la latenza della replica:

Aggiornamento dei dati: la differenza tra il momento in cui i dati sono stati sottoposti a commit nell'origine e il momento in cui sono stati letti da Datastream. Se questa metrica è elevata, indica che Datastream legge i dati più lentamente di quanto vengono generati nell'origine. Ciò indica che potrebbe esserci un problema con l'origine o con la connessione di rete all'origine.
Latenza di sistema: il tempo impiegato da Datastream per elaborare un evento, dal momento in cui l'evento viene letto dall'origine fino a quando viene scritto nella destinazione.
Latenza totale: il ritardo della replica end-to-end, che rappresenta il tempo totale da quando i dati vengono sottoposti a commit nell'origine fino a quando vengono scritti nella destinazione.

Se l'aggiornamento dei dati è elevato, le cause comuni includono:

Sovraccarico dell'origine: il database di origine genera log (file binlog, file di log di ripristino, file WAL) più velocemente di quanto Datastream possa leggerli.
- Azione per MySQL/Oracle: aumenta il maxConcurrentCdcTasks parametro per leggere più log in parallelo.
- Azione per PostgreSQL: isola le tabelle con un'elevata frequenza di modifica nei propri stream dedicati.
- Azione per SQL Server: aumenta il parametro maxConcurrentCdcTasks per leggere più tabelle di modifica in parallelo.
Esaurimento delle risorse di origine: il server del database di origine stesso riscontra problemi come un elevato utilizzo della CPU, una memoria insufficiente o colli di bottiglia di I/O del disco.
- Azione: assicurati che l'istanza di origine sia integra. Controlla l'utilizzo di CPU/RAM. Per PostgreSQL, valuta la possibilità di aumentare il valore del parametro logical_decoding_work_mem; per Oracle, assicurati che sia allocata una system global area (SGA) sufficiente.
Problemi di capacità di rete: tempo di ping elevato o larghezza di banda satura tra la sorgente e Google Cloud.
- Azione: monitora la larghezza di banda e la latenza di VPN o Cloud Interconnect.
Singola transazione di grandi dimensioni: un job batch di grandi dimensioni, ad esempio un'istruzione UPDATE su milioni di righe, può causare un picco temporaneo di latenza.
- Azione: questo è il comportamento previsto. Attendi che Datastream elabori l'evento di grandi dimensioni. In futuro, valuta la possibilità di suddividere i job batch di grandi dimensioni in blocchi più piccoli.

Se la latenza di sistema è elevata, potrebbe indicare un problema all'interno di Datastream o della destinazione.

Azione: controlla Cloud Logging per individuare errori persistenti a livello di riga (ad esempio, invalid input for type json. Se lo stream è in un loop di tentativi a causa di errori di tipo di dati o di vincoli, potrebbe essere necessaria la correzione manuale dei dati nell'origine. Se non sono presenti errori evidenti, contatta l'Assistenza Google per ricevere aiuto.

Quante tabelle può gestire un singolo stream?

Ti consigliamo di includere fino a 10.000 tabelle in un singolo stream. Non esiste un limite alla dimensione delle tabelle. Se devi creare uno stream con più tabelle, lo stream potrebbe entrare in uno stato di errore. Per evitare questo problema, valuta la possibilità di suddividere l'origine in più stream.