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
  • Le limitazioni note per l'utilizzo del database MySQL come origine
  • Una panoramica su come configurare un database MySQL di origine in modo che i dati possano essere trasmessi in streaming da questo a una destinazione

Comportamento

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

Replica basata su binlog

Datastream può utilizzare i file di log binario per tenere traccia delle modifiche ai dati nei database MySQL. Le informazioni contenute in questi file di log vengono quindi 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 da una determinata origine MySQL, nonché tutte le tabelle dei database o tabelle specifiche.
  • Vengono replicati tutti i dati storici.
  • 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'identificatore di transazione globale (GTID)

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

L'identificatore di transazione globale (GTID) è un identificatore univoco creato e associato a ogni transazione di cui è stato eseguito il commit 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 binario in cui ogni nodo nel cluster di database mantiene 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 tempi di inattività pianificati, perché la continuità del binlog viene interrotta e la replica basata su 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 da una determinata origine MySQL, nonché tutte le tabelle dei database o tabelle specifiche.
  • Vengono replicati tutti i dati storici.
  • 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 alla replica basata su GTID

Se vuoi aggiornare lo stream e passare dalla replica basata su binlog alla replica 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 saperne di più, consulta Configurare un database MySQL di origine.
  2. (Facoltativo) Crea ed esegui uno stream basato su GTID di test. Per saperne di più, consulta Creare uno stream.
  3. Crea uno stream basato su GTID. Non avviarlo ancora.
  4. Interrompi il traffico delle applicazioni 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 i dati del database. Puoi verificarlo utilizzando le metriche nella scheda Monitoraggio della pagina Dettagli dello stream per il tuo stream. I valori di Aggiornamento dei dati e Velocità effettiva devono essere 0.
  7. Avvia lo stream basato su GTID. Per saperne di più, consulta 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 backfill. Per saperne di più sulla gestione del backfill, consulta 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 la configurazione dell'origine MySQL da utilizzare con Datastream.

Utilizzare GTID per le configurazioni ad alta affidabilità

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

La replica basata su file binlog e posizione può interrompersi durante un failover del database perché, quando l'istanza principale non funziona, la nuova istanza principale ha una cronologia binlog diversa. In questo caso, Datastream perde la sua posizione e non può riprendere.

GTID assegna un ID univoco a ogni transazione nell'intera topologia di replica (istanza principale e repliche). Dopo un failover, Datastream può riprendere dall'ultimo GTID registrato nella nuova istanza principale, senza dover conoscere il file binlog o la posizione.

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

Dimensionare correttamente la replica di lettura

Se configuri Datastream per la replica da una replica di lettura, puoi riscontrare un doppio ritardo, ovvero una combinazione del ritardo di replica di MySQL (dall' istanza principale alla replica) e del ritardo di replica di Datastream (dalla replica alla destinazione). Le repliche di lettura vengono spesso sottoposte a provisioning con meno risorse (CPU, RAM, IOPS) rispetto alle istanze principali per ridurre i costi, il che può causare un ritardo rispetto all'istanza principale durante i periodi di scrittura elevata.

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

Aumentare la velocità effettiva 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 elevati che generano file binlog più velocemente di quanto una singola attività possa elaborare, aumenta la velocità effettiva regolando il parametro maxConcurrentCdcTasks. Questo parametro controlla il numero di attività CDC che uno stream esegue in parallelo. L'aumento del valore di questo parametro consente a Datastream di elaborare più file binlog contemporaneamente.

Consiglio: per determinare il valore appropriato per l'aggiornamento dei dati, monitora la frequenza di generazione del binlog del server MySQL durante le ore di punta. Puoi farlo osservando la frequenza con cui vengono creati e ruotati 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 le ore di punta, 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 di concorrenza dello stream.

Dimensionare correttamente il parametro max_allowed_packet

L'impostazione predefinita max_allowed_packet 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'errore 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 1G. 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 riesce.
  • Non è possibile eseguire il backfill delle tabelle con una chiave primaria definita come INVISIBLE.
  • Non è possibile eseguire il backfill di una tabella con più di 500 milioni di righe, a meno che non siano soddisfatte le seguenti condizioni:
    1. La tabella ha un indice univoco.
    2. Nessuna delle colonne dell'indice può ammettere valori nulli.
    3. L'indice non è decrescente.
    4. Tutte le colonne dell'indice sono incluse nello stream.
  • Datastream recupera periodicamente lo schema più recente dall'origine durante l'elaborazione degli eventi. Se uno schema cambia, Datastream rileva la modifica dello schema 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 dello schema potrebbero causare il danneggiamento dei dati o l'impossibilità di elaborare gli eventi downstream:
    • Eliminazione di colonne
    • Aggiunta di colonne al centro di una tabella
    • Modificare il tipo di dati di una colonna
    • Riordinamento delle colonne
    • Eliminare tabelle (pertinente se la stessa tabella viene poi ricreata con l'aggiunta di nuovi dati)
    • Troncamento delle tabelle
  • Datastream non supporta la replica delle visualizzazioni.
  • Datastream non supporta le colonne di tipi di dati spaziali, ad esempio GEOMETRY, POINT, LINESTRING, POLYGON. I valori in queste colonne vengono sostituiti con 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 le catene di certificati SSL nei profili di connessione MySQL di origine. Sono supportati solo i 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 trigger di 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 mitigare 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 su log binario si interrompe durante i failover, pertanto ti consigliamo di utilizzare la replica basata su GTID per i casi d'uso ad 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 Configurare un database MySQL autogestito.
  • Limitazioni di MariaDB:
    • La replica basata su GTID non è supportata per MariaDB. Devi configurare gli stream MariaDB in modo che utilizzino la replica basata su binlog.
    • Per le versioni di MariaDB da 11.4 a 12.2, devi abilitare la variabile di sistema binlog_legacy_event_pos nel database di origine per garantire la compatibilità con Datastream.

Limitazioni aggiuntive per la replica basata su GTID

  • Il recupero degli stream 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