Trasmettere dati in streaming dai database MySQL

Questa sezione contiene informazioni su:

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

Comportamento

Questa sezione descrive il comportamento delle origini MySQL quando replichi i dati utilizzando Datastream. Quando importi dati dai database MySQL, puoi utilizzare la replica basata su binlog o la replica basata sull'ID transazione globale (GTID). Selezioni il metodo CDC quando crei uno stream.

Replica basata su binlog

Datastream può utilizzare i file log binario per tenere traccia delle modifiche ai dati nei database MySQL. Le informazioni contenute in questi file di log vengono poi replicate nella destinazione per riprodurre le modifiche apportate all'origine.

Le caratteristiche principali della replica basata su binlog in Datastream sono:

  • È possibile selezionare tutti i database o database specifici di una determinata origine MySQL, nonché tutte le tabelle dei database 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.

Replica basata sull'ID transazione globale (GTID)

Datastream supporta anche la replica basata sull'identificatore globale (GTID).

L'ID transazione globale (GTID) è un identificatore univoco creato e associato a ogni transazione eseguita su un'origine MySQL. Questo identificatore è univoco non solo per l'origine in cui è stato creato, ma anche per tutti i server in una determinata topologia di replica, a differenza della replica basata su log binari in cui ogni nodo del cluster di database gestisce i propri file binlog con la propria numerazione. La gestione di file binlog e numerazione separati potrebbe diventare un problema in caso di errore o tempo di inattività pianificato, perché la continuità del binlog viene interrotta e la replica basata sul binlog non riesce.

La replica basata su GTID supporta i failover, i cluster di database autogestiti e continua a funzionare indipendentemente dalle modifiche apportate al cluster di database.

Le caratteristiche principali della replica basata su GTID in Datastream sono:

  • È possibile selezionare tutti i database o database specifici di una determinata origine MySQL, nonché tutte le tabelle dei database 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.
  • Supporto senza interruzioni per i failover.

Passare dalla replica basata su binlog a quella basata su GTID

Se vuoi aggiornare il flusso e passare dalla replica basata su binlog a quella basata su GTID senza dover eseguire un backfill, segui questi passaggi:

  1. Assicurati che tutti i requisiti per la replica basata su GTID siano soddisfatti. Per maggiori informazioni, consulta Configura un database MySQL di origine.
  2. (Facoltativo) Crea ed esegui uno stream basato su GTID di test. Per saperne di più, vedi Creare uno stream.
  3. Crea uno stream basato su GTID. Non avviarlo ancora.
  4. Interrompi il traffico dell'applicazione verso il database di origine.
  5. Metti in pausa lo stream esistente basato su binlog. Per saperne di più, consulta Mettere in pausa lo stream.
  6. Attendi qualche minuto per assicurarti che Datastream abbia recuperato il database. Puoi verificarlo utilizzando le metriche nella scheda Monitoraggio della pagina Dettagli stream del tuo stream. I valori di Aggiornamento dei dati e Throughput devono essere 0.
  7. Avvia lo stream basato su GTID. Per saperne di più, consulta la sezione Avviare lo stream.
  8. Riprendi il traffico verso il database di origine.

Se l'esecuzione di un backfill non è un problema, puoi troncare le tabelle in BigQuery, eliminare il vecchio stream e avviarne uno nuovo con il backfill. Per maggiori informazioni sulla gestione del backfill, vedi Gestire il backfill per gli oggetti di uno stream.

Versioni

Datastream supporta le seguenti versioni del database MySQL:

  • MySQL 5.6
  • MySQL 5.7
  • MySQL 8.0

  • MySQL 8.4 (supportato solo per la replica basata su GTID)

Datastream supporta i seguenti tipi di database MySQL:

Best practice

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

Utilizzare GTID per configurazioni ad alta affidabilità

Se l'origine MySQL di produzione utilizza repliche o qualsiasi altra configurazione di alta affidabilità, utilizza la replica basata su GTID.

La replica basata sulla posizione e sul file binlog può interrompersi durante un failover del database perché quando il database principale non funziona, il nuovo database principale ha una cronologia binlog diversa. In questo caso, Datastream perde la sua posizione e non può riprendere.

Il GTID assegna un ID univoco a ogni transazione nell'intera topologia di replica (primaria e repliche). Dopo un failover, Datastream può riprendere dall'ultimo GTID registrato sul nuovo database primario, senza dover conoscere il file binlog o la posizione.

Consiglio:per qualsiasi origine MySQL di produzione con una replica o una configurazione a disponibilità elevata, l'utilizzo del metodo CDC GTID è obbligatorio per una replica dei dati resiliente e affidabile.

Dimensiona correttamente la replica di lettura

Se configuri Datastream per la replica da una replica di lettura, puoi riscontrare un doppio ritardo, che è una combinazione del ritardo di replica MySQL (dalla replica primaria) e del ritardo di replica Datastream (dalla replica alla destinazione). Le repliche di lettura vengono spesso sottoposte a provisioning con meno risorse (CPU, RAM, IOPS) rispetto alle primarie per risparmiare sui costi, il che può causare un ritardo rispetto alle primarie durante i periodi di scrittura elevata.

Consiglio:quando utilizzi una replica di lettura come origine per Datastream, esegui il provisioning con risorse paragonabili a quelle dell'istanza principale, in modo che la replica possa stare al passo con la velocità effettiva di scrittura dell'istanza principale.

Aumentare il throughput per il metodo CDC binlog

Se utilizzi la replica basata su binlog e riscontri una latenza elevata a causa di volumi di scrittura di origine di grandi dimensioni che generano file binlog più velocemente di quanto una singola attività possa elaborare, aumenta la velocità effettiva modificando il parametro maxConcurrentCdcTasks. Questo parametro controlla il numero di attività CDC eseguite in parallelo da uno stream. Aumentando il valore di questo parametro, Datastream può elaborare più file binlog contemporaneamente.

Consiglio:per determinare il valore appropriato per l'aggiornamento dei dati, monitora la velocità di generazione dei binlog del server MySQL durante le ore di punta. Puoi farlo osservando la velocità con cui vengono creati e ruotati i nuovi file binlog nella directory dei dati MySQL oppure utilizzando gli strumenti di monitoraggio MySQL per monitorare la crescita dei log binari. Se, ad esempio, l'origine genera 10 file binlog al minuto durante i periodi di picco, l'impostazione di maxConcurrentCdcTasks su un valore come 10-15 consente a Datastream di elaborare questi file in parallelo, evitando un backlog.

Puoi aumentare maxConcurrentCdcTasks fino al valore massimo supportato di 50, a condizione che il carico sul database di origine rimanga sotto controllo. Per saperne di più, consulta Controlli della concorrenza dello stream.

Dimensionare correttamente il parametro max_allowed_packet

L'impostazione max_allowed_packet predefinita in MySQL (ad esempio 16 MB-64 MB) potrebbe essere troppo piccola. Se una singola riga con campi di tipo BLOB, JSON o TEXT di grandi dimensioni o una singola transazione di grandi dimensioni supera questa dimensione, MySQL termina la connessione Datastream, causando l'interruzione dello stream con errori come Packet for query is too large o Got a packet bigger than 'max_allowed_packet' bytes.

Consiglio:imposta il parametro max_allowed_packet sul server MySQL sul valore massimo consentito di 1 GB. In questo modo, il server può gestire qualsiasi riga o transazione di grandi dimensioni che Datastream deve leggere dal binlog.

Limitazioni note

Le limitazioni note per l'utilizzo del database MySQL come origine includono:

  • Gli stream sono limitati a 10.000 tabelle.
  • Le tabelle replicate devono utilizzare il motore di archiviazione InnoDB. Le tabelle che utilizzano il motore di archiviazione MyISAM non sono supportate e la convalida dello stream non va a buon fine.
  • Le tabelle con una chiave primaria definita come INVISIBLE non possono essere riempite.
  • Una tabella con più di 500 milioni di righe non può essere compilata a posteriori, a meno che non siano soddisfatte le seguenti condizioni:
    1. La tabella ha un indice univoco.
    2. Nessuna delle colonne dell'indice è annullabile.
    3. L'indice non è decrescente.
    4. Tutte le colonne dell'indice sono incluse nel flusso.
  • Datastream recupera periodicamente lo schema più recente dall'origine durante l'elaborazione degli eventi. Se uno schema cambia, Datastream rileva la modifica e attiva un recupero dello schema. Tuttavia, alcuni eventi potrebbero essere elaborati in modo errato o eliminati tra i recuperi dello schema, il che può causare discrepanze nei dati.
  • 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 di 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)
    • Troncare le tabelle
  • Datastream non supporta la replica delle viste.
  • Datastream non supporta le colonne di tipi di dati spaziali, ad esempio GEOMETRY, POINT, LINESTRING, POLYGON. I valori in queste colonne vengono sostituiti con i valori NULL.
  • Datastream non supporta il valore zero (0000-00-00 00:00:00) nelle colonne dei tipi di dati DATETIME, DATE o TIMESTAMP. Il valore zero viene sostituito con il valore NULL.
  • Datastream non supporta la replica delle righe che includono i seguenti valori nelle colonne JSON: DECIMAL, NEWDECIMAL, TIME, TIME2 DATETIME, DATETIME2, DATE, TIMESTAMP o TIMESTAMP2. Gli eventi contenenti questi valori vengono eliminati.
  • Datastream non supporta la compressione delle transazioni del log binario.
  • Datastream non supporta i file di log binari più grandi di 4 GiB. Poiché MySQL scrive ogni transazione in un singolo file di log binario, mantieni le singole transazioni al di sotto di 4 GiB in modo che i file di log binario non superino questo limite.
  • Datastream non supporta le catene di certificati SSL nei profili di connessione MySQL di origine. Sono supportati solo certificati singoli con codifica PEM x509.
  • Datastream non supporta le operazioni a cascata: ON UPDATE CASCADE e ON DELETE CASCADE. Questi eventi non vengono scritti nel log binario e, di conseguenza, non vengono propagati alla destinazione. Come soluzione alternativa, puoi sostituire le operazioni a cascata con i trigger del database.
  • Datastream non supporta le operazioni DROP PARTITION. Queste operazioni sono solo operazioni sui metadati e non vengono replicate. Gli altri eventi non sono interessati e lo stream viene eseguito correttamente.
  • Potresti riscontrare problemi di connettività durante la replica delle tabelle FEDERATED. In questo caso, rimuovi tutte le tabelle FEDERATED dalla configurazione del database di origine e aumenta i valori dei parametri connect_timeout, net_read_timeout e max_allowed_packet per ridurre i problemi di timeout durante il backfill.
  • Le istanze Cloud SQL Enterprise Plus devono utilizzare la replica basata su GTID perché sono soggette a manutenzione con tempi di inattività quasi azzerati. La replica basata sui log binari si interrompe in caso di failover, pertanto ti consigliamo di utilizzare la replica basata su GTID per i casi d'uso di alta affidabilità.
  • Per le versioni di MySQL 8.0 e successive, la variabile binlog_row_value_options deve essere impostata su un valore vuoto. Questo è il valore predefinito per la maggior parte delle versioni, ma per alcune, ad esempio le origini MySQL su Oracle Cloud Infrastructure (OCI), devi impostarlo in modo esplicito. Per saperne di più, consulta Configura un database MySQL autogestito.
  • Limitazioni di MariaDB:
    • La replica basata su GTID non è supportata per MariaDB. Devi configurare i flussi MariaDB per utilizzare la replica basata su binlog.
    • Per MariaDB 11.4-12.2, devi abilitare la variabile di sistema binlog_legacy_event_pos nel database di origine per garantire la compatibilità con Datastream.
    • Datastream non supporta il tipo di dati UUID (introdotto in MariaDB 10.7). Devi escludere le colonne del tipo di dati UUID dalla configurazione del flusso.

Limitazioni aggiuntive per la replica basata su GTID

  • Il recupero dei flussi che utilizzano la replica basata su GTID è disponibile solo quando si utilizza l'API Datastream.
  • La creazione di tabelle da altre tabelle utilizzando le istruzioni CREATE TABLE ... SELECT non è supportata.
  • Datastream non supporta i GTID con tag.
  • Per le limitazioni di MySQL che si applicano alla replica basata su GTID, consulta la documentazione di MySQL.

Passaggi successivi