Esegui la migrazione da MySQL a Spanner

Questo articolo spiega come eseguire la migrazione dell'elaborazione transazionale online (OLTP) da MySQL a Spanner.

Vincoli di migrazione

Spanner utilizza alcuni concetti in modo diverso rispetto ad altre strumenti di gestione di database, quindi potrebbe essere necessario regolare un'architettura di Kubernetes per sfruttarne appieno le funzionalità. Potresti anche dover integrare Spanner con altri servizi Google Cloud per soddisfare le tue esigenze.

Stored procedure e trigger

Spanner non supporta l'esecuzione di codice utente a livello di database, Quindi, nell'ambito della migrazione, la logica di business è implementata da dati archiviati a livello di database e i trigger devono essere spostati nell'applicazione.

Sequenze

Spanner consiglia di utilizzare UUID versione 4 come metodo predefinito per generare coppie chiave-valore primarie. La funzione GENERATE_UUID() (GoogleSQL, PostgreSQL) restituisce i valori UUID versione 4 rappresentati come tipo STRING.

Se devi generare valori interi, Spanner supporta sequenze positive invertite a bit (GoogleSQL, PostgreSQL), che producono valori che distribuiscono uniformemente nello spazio numerico positivo a 64 bit. Puoi utilizza questi numeri per evitare problemi di hotspot.

Per ulteriori informazioni, consulta le strategie per il valore predefinito della chiave principale.

Controlli di accesso

Spanner supporta un controllo dell'accesso granulare a tabella e colonna livello. Il controllo granulare dell'accesso per le viste non è supportato. Per ulteriori informazioni consulta l'articolo Informazioni sul controllo dell'accesso granulare.

Vincoli di convalida dei dati

Spanner supporta un insieme limitato di vincoli di convalida dei dati nel livello del database. Se hai bisogno di vincoli relativi ai dati più complessi, a livello di applicazione.

La tabella seguente illustra i tipi di vincoli comunemente presenti in MySQL e come implementarli con Spanner.

Vincolo Implementazione con Spanner
Non null Vincolo di colonna NOT NULL
Univoco Indice secondario con vincolo UNIQUE
Foreign key (per tabelle normali) Vedi Creare e gestire relazioni di chiave esterna.
Azioni chiave esterna ON DELETE/ON UPDATE Possibile solo per le tabelle con interleaving. o implementati in un'istanza livello di applicazione
Controllo dei valori e convalida tramite vincoli CHECK Consulta la sezione Creazione e gestione dei vincoli di controllo.
Controllo dei valori e convalida tramite trigger Implementata nel livello dell'applicazione

Colonne generate

Spanner supporta le colonne generate in cui il valore della colonna verrà sempre generato da una funzione fornita come parte della definizione della tabella. Come in MySQL, le colonne generate non possono essere impostate espressamente su un valore fornito in un'istruzione DML.

Le colonne generate sono definite come parte della definizione della colonna nel corso di una definizione dei dati CREATE TABLE o ALTER TABLE dell'istruzione DDL. La parola chiave AS è seguita da un numero Funzione SQL e la parola chiave suffisso richiesta STORED. La La parola chiave STORED fa parte della specifica ANSI SQL, e indica che i risultati della funzione verranno archiviati insieme ad altre colonne della tabella.

La funzione SQL, l'espressione di generazione, può includere qualsiasi espressione, funzione e operatore e può essere utilizzata in indici secondari o come chiave esterna.

Scopri di più su come gestire questo tipo di colonna, consulta Creazione e gestione delle colonne generate.

Tipi di dati supportati

MySQL e Spanner supportano diversi set di tipi di dati. La la seguente tabella elenca i tipi di dati MySQL e il loro equivalente Spanner. Per definizioni dettagliate di ogni Spanner tipo di dati, consulta Tipi di dati.

Potresti dover trasformare ulteriormente i dati come descritto nella colonna Note per adattare i dati MySQL al database Spanner. Ad esempio, può archiviare un BLOB di grandi dimensioni come oggetto in un bucket Cloud Storage anziché nel database e quindi archivia il riferimento URI al Cloud Storage nel database come STRING.

Tipo di dati MySQL Equivalente Spanner Note
INTEGER, INT, MEDIUMINT BIGINT e SMALLINT INT64
TINYINT, BOOL, BOOLEAN BOOL, INT64 I valori TINYINT(1) vengono utilizzati per rappresentare i valori booleani di 'true' (diverso da zero) o "false" (0).
FLOAT, DOUBLE FLOAT64
DECIMAL, NUMERIC NUMERIC, STRING In MySQL,i tipi di dati NUMERIC e DECIMAL supportano fino a un totale di 65 cifre di precisione e scala, come definito nella colonna dichiarazione. Il tipo di dati NUMERIC di Spanner supporta fino a 38 cifre di precisione e 9 cifre decimali della scala.
Se hai bisogno di una maggiore precisione, consulta Archiviazione di dati numerici di precisione arbitraria per meccanismi alternativi.
BIT BYTES
DATE DATE Sia Spanner che MySQL utilizzano "yyyy-mm-dd" per le date, quindi non è necessaria alcuna trasformazione. Le funzioni SQL sono fornite per convertire le date in una stringa formattata.
DATETIME, TIMESTAMP TIMESTAMP Spanner archivia l'ora indipendentemente dal fuso orario. Per per archiviare un fuso orario, devi utilizzare una colonna STRING separata. Le funzioni SQL vengono fornite per convertire i timestamp in una stringa formattata utilizzando fusi orari.
CHAR, VARCHAR STRING Nota: Spanner utilizza stringhe Unicode ovunque.
VARCHAR supporta una lunghezza massima di 65.535 byte, mentre Spanner supporta fino a 2.621.440 caratteri.
BINARY, VARBINARY, BLOB, TINYBLOB BYTES Gli oggetti di piccole dimensioni (meno di 10 MiB) possono essere archiviati BYTES. Valuta la possibilità di utilizzare offerte Google Cloud alternative come come Cloud Storage, per archiviare oggetti più grandi
TEXT, TINYTEXT, ENUM STRING Valori di TEXT piccoli (meno di 10 MiB) possono essere memorizzati come STRING. Valutare l'utilizzo di offerte Google Cloud alternative come Cloud Storage per supportare TEXT di dimensioni e i relativi valori.
ENUM STRING La convalida dei valori ENUM deve essere eseguita nell'applicazione
SET ARRAY<STRING> La convalida dei valori dell'elemento SET deve essere eseguita nell'applicazione
LONGBLOB, MEDIUMBLOB BYTES o STRING contenente l'URI dell'oggetto. Gli oggetti di piccole dimensioni (meno di 10 MiB) possono essere archiviati come BYTES. Valuta l'utilizzo di offerte Google Cloud alternative come per archiviare oggetti più grandi.
LONGTEXT, MEDIUMTEXT STRING (contenente dati o URI dell'oggetto esterno) Gli oggetti di piccole dimensioni (meno di 2.621.440 caratteri) possono essere archiviati STRING. Valutare l'utilizzo di offerte Google Cloud alternative ad esempio Cloud Storage per archiviare oggetti più grandi
JSON JSON Le stringhe JSON di piccole dimensioni (meno di 2.621.440 caratteri) possono essere memorizzate come JSON. Valutare l'utilizzo di offerte Google Cloud alternative ad esempio Cloud Storage, per archiviare oggetti più grandi.
GEOMETRY, POINT, LINESTRING, POLYGON, MULTIPOINT, MULTIPOLYGON e GEOMETRYCOLLECTION Spanner non supporta i tipi di dati geospaziali. Devi memorizzare questi dati utilizzando tipi di dati standard e implementare eventuali funzionalità di ricerca/filtro a livello di applicazione.

Processo di migrazione

Una tempistica generale del processo di migrazione sarebbe:

  1. Converti lo schema e il modello dei dati.
  2. Traduci le query SQL.
  3. Esegui la migrazione dell'applicazione per utilizzare Spanner, oltre a e MySQL.
  4. Esporta in blocco i dati da MySQL e importa i tuoi dati in Spanner usando Dataflow.
  5. Mantieni la coerenza tra entrambi i database durante la migrazione.
  6. Esegui la migrazione dell'applicazione da MySQL.

Passaggio 1: converti il database e lo schema

Converti lo schema esistente in Spanner schema per archiviare i dati. Per semplificare le modifiche alle applicazioni, che lo schema convertito corrisponda allo schema MySQL esistente il più possibile. Tuttavia, a causa delle differenze nelle funzionalità, alcune modifiche potrebbero essere necessaria.

Utilizzo best practice per la progettazione dello schema può contribuire ad aumentare la velocità effettiva e a ridurre gli hotspot nel il database Spanner.

Chiavi primarie

In Spanner, ogni tabella che deve archiviare più di una riga deve Avere una chiave primaria composta da una o più colonne della tabella. La tabella la chiave primaria identifica in modo univoco ogni riga di una tabella e Spanner utilizza la chiave primaria per ordinare le righe della tabella. Poiché Spanner è molto distribuito, è importante scegliere una generazione di chiave primaria tecnica che si adatti bene alla crescita dei dati. Per ulteriori informazioni, vedi Le strategie di migrazione della chiave principale che consigliamo.

Tieni presente che una volta designata la chiave primaria, non puoi più aggiungere o rimuovere una colonna di chiave primaria o modifica il valore di una chiave primaria in un secondo momento senza eliminare per ricreare la tabella. Per ulteriori informazioni su come designare la chiave primaria, consulta la sezione Schema e modello dei dati - principale chiave.

Interfoliare le tabelle

Spanner ha una funzionalità in cui puoi definire due tabelle con un 1-molti, relazione genitore-figlio. Questa funzionalità alterna le righe di dati figlio accanto alla riga padre nello spazio di archiviazione, in modo efficace prima del join con la tabella e migliorare l'efficienza del recupero dati quando viene eseguita una query sull'elemento principale e su quelli secondari.

La chiave primaria della tabella figlio deve iniziare con le colonne di chiave primaria del nella tabella padre. Dal punto di vista della riga secondaria, la chiave primaria della riga padre è o chiave esterna. Puoi definire fino a 6 livelli di relazioni.

Puoi definisci le azioni all'eliminazione delle tabelle figlio per determinare cosa succede quando viene eliminata la riga padre: vengono eliminate tutte le righe secondarie oppure l'eliminazione delle righe padre è bloccata sono presenti righe secondarie.

Ecco un esempio di creazione di una tabella Album con interfoliazione nella sezione Cantanti principali definita in precedenza:

CREATE TABLE Albums (
  SingerId     INT64 NOT NULL,
  AlbumId      INT64 NOT NULL,
  AlbumTitle   STRING(MAX),
) PRIMARY KEY (SingerId, AlbumId)
INTERLEAVE IN PARENT (Singers)
ON DELETE CASCADE;

Crea indici secondari

Puoi anche creare indici secondari per indicizzare i dati all'interno della tabella al di fuori della chiave primaria. Spanner implementa gli indici secondari come le tabelle, pertanto i valori delle colonne da utilizzare come chiavi indice avranno gli stessi vincoli come chiavi primarie delle tabelle. Ciò significa anche che gli indici hanno lo stesso di coerenza come le tabelle Spanner.

Le ricerche di valori mediante indici secondari sono effettivamente identiche a quelle di una query con un join tabella. Puoi migliorare le prestazioni delle query utilizzando gli indici archiviando copie dei valori delle colonne della tabella originale nell'indice secondario utilizzando STORING, rendendola una indice di copertura.

Lo strumento di ottimizzazione delle query di Spanner utilizza solo automaticamente un quando l'indice stesso archivia tutte le colonne sottoposte a query (una query). Per forzare l'utilizzo di un indice quando si eseguono query sulle colonne dell'originale devi utilizzare una classe Direttiva FORCE INDEX nell'istruzione SQL, ad esempio:

SELECT *
FROM MyTable@{FORCE_INDEX=MyTableIndex}
WHERE IndexedColumn=@value

Gli indici possono essere utilizzati per applicare valori univoci all'interno di una colonna della tabella, definendo a Indice UNIQUE in quella colonna. L'indice non impedirà l'aggiunta di valori duplicati.

Ecco un esempio di istruzione DDL che crea un indice secondario per gli album tabella:

CREATE INDEX AlbumsByAlbumTitle ON Albums(AlbumTitle);

Se crei indici aggiuntivi dopo aver caricato i dati, la compilazione l'indice potrebbe richiedere del tempo. Ti consigliamo di limitare la frequenza con cui si aggiungono a una media di tre al giorno. Per ulteriori indicazioni sulla creazione indici secondari, consulta Indici secondari. Per ulteriori informazioni sui limiti della creazione degli indici, consulta Aggiornamenti dello schema.

Passaggio 2: traduci le query SQL

Spanner utilizza Dialetto ANSI 2011 di SQL con estensioni, e ha molti funzioni e operatori per tradurre e aggregare i dati. Qualsiasi query SQL che utilizza specifiche dialetto, funzioni e tipi dovranno essere convertiti per essere compatibili con Spanner.

Anche se Spanner non supporta i dati strutturati come colonna definizioni, puoi usare i dati strutturati nelle query SQL utilizzando ARRAY<> e Tipi di STRUCT<>. Ad esempio, potresti scrivere una query che restituisca tutti gli album per un artista che utilizza ARRAY di STRUCT (sfruttando i vantaggi dei dati). Per ulteriori informazioni, consulta Sottoquery della documentazione.

Le query SQL possono essere profilate utilizzando la pagina Spanner Studio in nella console Google Cloud per eseguire la query. In generale, le query che eseguire scansioni complete delle tabelle su tabelle di grandi dimensioni sono molto costose e dovrebbero con parsimonia. Per ulteriori informazioni sull'ottimizzazione delle query SQL, consulta Best practice per SQL documentazione.

Passaggio 3: esegui la migrazione dell'applicazione per utilizzare Spanner

Spanner fornisce un insieme Librerie client per varie lingue e la possibilità di leggere e scrivere dati utilizzando per le chiamate API specifiche di Spanner, oltre all'uso Query SQL e DML (Data Modification Language) istruzioni. L'utilizzo delle chiamate API potrebbe essere più veloce per alcune query, ad esempio la riga diretta legge per chiave, perché l'istruzione SQL non deve essere tradotta.

Spanner fornisce Driver JDBC per applicazioni Java.

Nell'ambito del processo di migrazione, le funzionalità non sono disponibili Come indicato sopra, Spanner deve essere implementato un'applicazione. Ad esempio, un trigger per verificare i valori dei dati e aggiornare un attivatore deve essere implementata nell'applicazione utilizzando un sistema di lettura/scrittura transazione per leggere la riga esistente, verifica il vincolo, quindi scrivi ha aggiornato le righe in entrambe le tabelle.

Offerte Spanner transazioni di lettura/scrittura e di sola lettura, che garantiscono la coerenza esterna dei tuoi dati. Inoltre, legge le transazioni possono avere Limiti di timestamp applicata, in cui leggi una versione coerente dei dati:

  • a un'ora esatta nel passato (fino a un'ora fa).
  • in futuro (in cui la lettura si bloccherà fino all'arrivo di quel momento).
  • con una quantità accettabile di inattività limitata, che restituirà un costante fino a un certo periodo di tempo senza dover controllare in un secondo momento siano disponibili su un'altra replica. Questo può migliorare le prestazioni a scapito di dati potenzialmente inattivi.

Passaggio 4: trasferisci i dati da MySQL a Spanner

Per trasferire i tuoi dati da MySQL a Spanner, devi esporta il database MySQL in un formato file portatile, ad esempio un file XML, quindi importa i dati in Spanner utilizzando e Dataflow.

Trasferimento di dati da MySQL a Spanner

Esportazione collettiva da MySQL

Lo strumento mysqldump incluso in MySQL è in grado di esportare l'intero database in file XML corretti. In alternativa, puoi utilizzare SELECT ... INTO OUTFILE Istruzione SQL per creare file CSV per ogni tabella. Tuttavia, questo presenta lo svantaggio che è possibile esportare una sola tabella alla volta, il che significa che devi mettere in pausa l'applicazione o disattivare il database in modo che il database rimanga in uno stato coerente per l'esportazione.

Dopo aver esportato questi file di dati, ti consigliamo di caricarli in una Cloud Storage in modo che siano accessibili per l'importazione.

Importazione collettiva in Spanner

Poiché è probabile che gli schemi del database siano diversi tra MySQL e Spanner, potresti dover includere alcune conversioni dei dati nel processo di importazione. La il modo più semplice per eseguire queste conversioni e importarli Spanner utilizza Dataflow. Dataflow è la piattaforma Google Cloud di estrazione, trasformazione, e il servizio di caricamento (ETL). Fornisce una piattaforma per eseguire pipeline di dati scritte utilizzando il SDK Apache Beam leggere ed elaborare grandi quantità di dati in parallelo su machine learning.

L'SDK Apache Beam richiede la scrittura di un semplice programma Java per impostare le trasformare e scrivere i dati. Esistono connettori Beam per Cloud Storage e Spanner, quindi l'unico codice che devi scrivere sono i dati e si trasformeranno automaticamente.

Esempio di una pipeline semplice che legge dai file CSV e scrive Spanner, consulta repository di codice di esempio.

Se usi tabelle con interleaving padre-figlio in Spanner di importazione, tieni presente che durante il processo di importazione la riga padre venga creata prima la riga secondaria. La Codice pipeline di importazione di Spanner gestisce questo aspetto importando prima tutti i dati per le tabelle a livello principale, poi tutti le tabelle figlio di livello 1, tutte le tabelle figlio di livello 2 e così via.

Puoi utilizzare la pipeline di importazione di Spanner direttamente eseguire l'importazione collettiva dei dati, ma questo approccio richiede che i dati siano presenti nei file Avro utilizzando il formato .

Passaggio 5: mantieni la coerenza tra i due database

Molte applicazioni hanno requisiti di disponibilità che rendono impossibile mantenere l'applicazione offline per il tempo necessario a esportare e importare i dati. Di conseguenza, mentre trasferisci i dati in Spanner, continua a modificare il database esistente. Quindi è necessario per duplicare gli aggiornamenti al database Spanner mentre dell'applicazione è in esecuzione.

Esistono vari metodi per mantenere sincronizzati i due database, tra cui: Change Data Capture (CDC) e implementazione di aggiornamenti simultanei nell'applicazione.

Change Data Capture (CDC)

MySQL non dispone di un database Change Data Capture (CDC) (CDC). Tuttavia, esistono vari progetti open source che possono MySQL binlog e li converti in un flusso CDC. Ad esempio: Daemon di Maxwell può fornire un flusso CDC per il tuo database.

Puoi scrivere un'applicazione che si abbona a questo flusso e applica le stesse (dopo la conversione dei dati, ovviamente) in Spanner per configurare un database.

Aggiornamenti simultanei a entrambi i database dall'applicazione

Un metodo alternativo è modificare l'applicazione per eseguire scritture su entrambi o Microsoft SQL Server. Un database (inizialmente MySQL) verrebbe considerato l'origine e, dopo la scrittura di ogni database, l'intera riga viene letta, convertita e vengono scritte nel database Spanner. In questo modo, l'applicazione sovrascrive costantemente le righe di Spanner con i dati più recenti.

Quando hai la certezza che tutti i tuoi dati siano stati trasferiti correttamente, può trasferire la fonte attendibile al database Spanner. Questo meccanismo di rollback fornisce un percorso di rollback se vengono rilevati problemi quando si passa Spanner.

Verifica la coerenza dei dati

Man mano che i flussi di dati vengono inseriti nel database Spanner, puoi eseguire periodicamente Eseguire un confronto tra i dati Spanner e MySQL per assicurarci che i dati siano coerenti. Per convalidare la coerenza eseguire query su entrambe le origini dati e confrontare i risultati.

Puoi usare Dataflow per eseguire un confronto dettagliato tra di dati utilizzando Unisci alla trasformazione. Questa trasformazione prende 2 set di dati con chiave e associa i valori in base alla chiave. La i valori corrispondenti possono quindi essere confrontati per trovare l'uguaglianza. Puoi eseguire regolarmente questo verifica finché il livello di coerenza non soddisfa i requisiti della tua attività.

Passaggio 6: passa a Spanner come fonte attendibile dell'applicazione

Quando hai la certezza di eseguire la migrazione dei dati, puoi cambiare l'applicazione all'utilizzo di Spanner come fonte attendibile. Se continui a scrivere le modifiche al database MySQL, questo mantiene il database MySQL aggiornato e fornisce un percorso di rollback in caso di problemi.

Infine, puoi disabilitare e rimuovere il codice di aggiornamento del database MySQL e arrestare il database MySQL, ora obsoleto.

Esporta e importa i database Spanner

Facoltativamente, puoi esportare le tabelle da Spanner in un nel bucket Cloud Storage utilizzando un modello Dataflow eseguire l'esportazione. La cartella risultante contiene un set di file Avro e JSON file manifest contenenti le tabelle esportate. Questi file possono essere utilizzati tra cui:

  • Backup del database per conformità o emergenza al criterio di conservazione dei dati e il ripristino di emergenza.
  • Importare il file Avro in altre offerte Google Cloud come in BigQuery.

Per ulteriori informazioni sul processo di esportazione e importazione, vedi Esportazione dei database e Importazione dei database.

Passaggi successivi