Trasmettere dati in streaming dai database MySQL

Datastream ti consente di replicare i dati storici e le modifiche in corso da un database MySQL di origine alla destinazione per l'analisi in tempo reale e la sincronizzazione del database.

Prima di configurare un'origine MySQL, esamina il comportamento di replica, le versioni e i tipi di database supportati, le best practice e le limitazioni note in Datastream.

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 su 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 un registro 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 nell'origine.

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

  • È possibile selezionare tutti i database o database specifici di un'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'ID transazione 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 da cui è stato generato, 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 gestisce i propri file binlog con la propria numerazione. La gestione di file binlog e numerazioni 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 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 di un'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 perfetto per i failover.

Passa 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 saperne di più, consulta Configura un database MySQL di origine.
  2. Facoltativamente, crea ed esegui un flusso di test basato su GTID. Per saperne di più, consulta Crea un flusso.
  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 basato su binlog esistente. Per saperne di più, consulta Metti in pausa lo stream.
  6. Attendi qualche minuto per assicurarti che Datastream abbia aggiornato il database. Puoi verificarlo utilizzando le metriche nella scheda Monitoraggio, nella 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 Avvia 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 saperne di più sulla gestione del backfill, consulta Gestisci 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.

Utilizza il 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.

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

Suggerimento: per qualsiasi origine MySQL di produzione con una replica o una configurazione ad alta affidabilità, 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, potresti riscontrare un doppio ritardo, che è una combinazione del ritardo di replica di MySQL (da primario a replica) e del ritardo di replica di Datastream (da replica a destinazione). Per risparmiare sui costi, le repliche di lettura vengono spesso sottoposte a provisioning con meno risorse (CPU, RAM, IOPS) rispetto alle istanze primarie, il che può causare un ritardo rispetto all'istanza primaria durante i periodi di scrittura elevata.

Suggerimento: 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 tenere il passo con il throughput di scrittura dell'istanza principale.

Aumenta 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 elevati che generano file binlog più velocemente di quanto un singolo task possa elaborarli, aumenta il throughput ottimizzando il parametro maxConcurrentCdcTasks. Questo parametro controlla il numero di attività CDC eseguite in parallelo da uno stream. L'aumento del valore di questo parametro consente a Datastream di elaborare più file binlog contemporaneamente.

Suggerimento: per determinare il valore appropriato per l'aggiornamento dei dati, monitora la frequenza di generazione dei binlog del server MySQL durante le ore di punta. Puoi farlo osservando la frequenza con cui vengono creati e ruotati i nuovi file binlog nella directory di dati MySQL o utilizzando gli strumenti di monitoraggio di MySQL per monitorare la crescita dei log binari. Ad esempio, se la tua 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 di concorrenza degli stream.

Dimensiona correttamente il parametro max_allowed_packet

L'impostazione predefinita di 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.

Suggerimento: 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 non superano la convalida dello stream.
  • Non è possibile eseguire il backfill delle tabelle con una chiave primaria definita come INVISIBLE.
  • Una tabella con più di 500 milioni di righe non può essere sottoposta a backfill, a meno che non siano soddisfatte le seguenti condizioni:
    1. La tabella ha un indice univoco.
    2. Nessuna delle colonne dell'indice è nullable.
    3. L'indice non è decrescente.
    4. Tutte le colonne dell'indice sono incluse nello stream.
  • Datastream recupera periodicamente lo schema più recente dall'origine man mano che gli eventi vengono elaborati. Se uno schema cambia, Datastream rileva la modifica e attiva un recupero dello schema. Tuttavia, alcuni eventi potrebbero essere elaborati in modo errato o essere 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. In questo caso, potrebbe verificarsi un danneggiamento dei dati. Le seguenti modifiche allo schema potrebbero causare il danneggiamento dei dati o la mancata elaborazione degli eventi a valle:
    • Eliminazione di 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)
    • Troncamento delle tabelle
  • Datastream non supporta la replica delle viste.
  • Datastream non supporta 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 di 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 ignorati.
  • Datastream non supporta la compressione delle transazioni dei log binari.
  • Datastream non supporta file di log binari di dimensioni superiori a 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 singoli certificati x509 con codifica PEM.
  • 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 di eliminazione a cascata con trigger di database.
  • Datastream non supporta le operazioni DROP PARTITION. Queste operazioni riguardano solo i 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 in caso di failover, pertanto consigliamo di utilizzare la replica basata su GTID per i casi d'uso ad alta affidabilità.
  • Per MySQL 8.0 e versioni successive, la variabile binlog_row_value_options deve essere impostata su un valore vuoto. Questa è l'impostazione predefinita per la maggior parte delle versioni, ma per alcune, ad esempio le origini MySQL su Oracle Cloud Infrastructure (OCI), devi impostarla esplicitamente. 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 in modo che utilizzino la replica basata su binlog.
    • Per le versioni di MariaDB dalla 11.4 alla 12.2, devi attivare 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 utilizzi 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