Esegui la migrazione da MySQL a Spanner

Questo articolo illustra come eseguire la migrazione del tuo database Online Transactional Processing (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 di 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 viene implementata per database archiviati a livello di e i trigger devono essere spostati nell'applicazione.

Sequenze

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

Se devi generare valori interi, Spanner supporta sequenze positive con inversione dei bit (GoogleSQL, PostgreSQL), che producono valori distribuiti in modo uniforme 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 il controllo dell'accesso granulare a livello di tabella e colonna. Il controllo granulare degli accessi per le visualizzazioni non è supportato. Per ulteriori informazioni, consulta 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 nei database MySQL e come implementarli con Spanner.

Vincolo Implementazione con Spanner
Non null Vincolo della colonna NOT NULL
Univoco Indice secondario con vincolo UNIQUE
Foreign key (per tabelle normali) Consulta l'articolo Creare e gestire relazioni con le chiavi esterne.
Azioni ON DELETE/ON UPDATE della chiave esterna Possibile solo per le tabelle interlacciate; in caso contrario, implementato nel livello di applicazione
Controlli e convalida dei valori tramite vincoli CHECK Consulta Creare e gestire i vincoli check.
Controlli e convalida dei valori tramite gli attivatori Implementato nel livello di applicazione

Colonne generate

Spanner supporta le colonne generate, in cui il valore della colonna viene sempre generato da una funzione fornita nell'ambito 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 vengono definite nell'ambito della definizione della colonna durante un'istruzione CREATE TABLE o ALTER TABLE Data Definition Language (DDL). La parola chiave AS è seguita da una funzione SQL valida e dalla parola chiave suffisso obbligatoria 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 consultando Creare e gestire le 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 tipo di dato Spanner, consulta Tipi di dati.

Potresti dover trasformare ulteriormente i dati come descritto nella colonna Note per adattarli al database Spanner. Ad esempio, può archiviare un BLOB di grandi dimensioni come oggetto in un bucket Cloud Storage anziché nel database, quindi archivia il riferimento URI al file di 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 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 dichiarazione della colonna. Il tipo di dati NUMERIC di Spanner supporta fino a 38 cifre di precisione e 9 cifre decimali di 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. Sono disponibili funzioni SQL per convertire le date in una stringa formattata.
DATETIME, TIMESTAMP TIMESTAMP Spanner memorizza l'ora indipendentemente dal fuso orario. Se devi memorizzare un fuso orario, devi utilizzare una colonna STRING separata. Sono disponibili funzioni SQL per convertire i timestamp in una stringa formattata utilizzando i fusi orari.
CHAR, VARCHAR STRING Nota: Spanner utilizza sempre stringhe Unicode.
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 come BYTES. Valuta la possibilità di utilizzare offerte Google Cloud alternative come Cloud Storage per archiviare oggetti di dimensioni maggiori
TEXT, TINYTEXT, ENUM STRING I valori TEXT piccoli (inferiori a 10 MiB) possono essere memorizzati come STRING. Valuta la possibilità di utilizzare offerte Google Cloud alternative come Cloud Storage per supportare valori TEXT più elevati.
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 in modo che utilizzi Spanner oltre a 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 uno schema Spanner per archiviare i dati. Per semplificare le modifiche alle applicazioni, che lo schema convertito corrisponda allo schema MySQL esistente il più possibile possibile. Tuttavia, a causa delle differenze nelle funzionalità, potrebbero essere necessarie alcune modifiche.

L'utilizzo delle best practice nella progettazione dello schema può aiutarti ad aumentare la velocità effettiva e a ridurre gli hot spot nel database Spanner.

Chiavi primarie

In Spanner, ogni tabella che deve memorizzare 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 tecnica di generazione della chiave primaria che si adatti bene alla crescita dei dati. Per ulteriori informazioni, consulta le strategie di migrazione delle chiavi principali consigliate.

Tieni presente che, dopo aver designato la chiave primaria, non puoi aggiungere o rimuovere una colonna della chiave primaria né modificare un valore della chiave primaria in un secondo momento senza eliminare e ricreare la tabella. Per ulteriori informazioni su come designare la chiave primaria, consulta la sezione Schema e modello dei dati - principale chiave.

Intercala le tabelle

Spanner dispone di una funzionalità che consente di definire due tabelle come esistenti in una relazione 1-many padre-figlio. Questa funzionalità intercala le righe di dati figlio accanto alla riga padre nello spazio di archiviazione, pre-unire efficacemente la tabella e migliorare l'efficienza del recupero dei dati quando vengono eseguite query su righe padre e figli contemporaneamente.

La chiave primaria della tabella figlio deve iniziare con le colonne di chiave primaria della tabella padre. Dal punto di vista della riga figlio, la chiave primaria della riga padre è indicata come 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 interlacciata nella tabella principale Cantanti 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;

Creare 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 le stesse garanzie di coerenza delle 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.

L'ottimizzatore delle query di Spanner utilizza automaticamente un indice secondario solo quando l'indice stesso memorizza tutte le colonne su cui viene eseguita la query (una query coperta). Per forzare l'utilizzo di un indice quando esegui query sulle colonne della tabella originale, devi utilizzare un'istruzione 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 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 sulle limitazioni alla creazione di indici, consulta Aggiornamenti dello schema.

Passaggio 2: traduci le query SQL

Spanner utilizza il dialetto ANSI 2011 di SQL con estensioni, e dispone di molti funzioni e operatori per aiutarti a 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 puoi utilizzare i dati strutturati nelle query SQL utilizzando ARRAY<> e Tipi di STRUCT<>. Ad esempio, potresti scrivere una query che restituisca tutti gli album di un artista utilizzando un ARRAY di STRUCT (sfruttando i dati precombinati). Per ulteriori informazioni, consulta la sezione Subquery 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 eseguono scansioni complete della tabella su tabelle di grandi dimensioni sono molto costose e devono essere utilizzate con parsimonia. Per ulteriori informazioni sull'ottimizzazione delle query SQL, consulta Best practice per SQL documentazione.

Passaggio 3: esegui la migrazione dell'applicazione per l'utilizzo di Spanner

Spanner fornisce un insieme Librerie client per varie lingue e la possibilità di leggere e scrivere dati utilizzando per 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 un driver JDBC per le 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:

  • in un momento esatto 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. Ciò può offrire vantaggi in termini di prestazioni a scapito di dati potenzialmente obsoleti.

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 ben formattati. In alternativa, puoi utilizzare l'istruzione SQL SELECT ... INTO OUTFILE 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. Il modo più semplice per eseguire queste conversioni dei dati e importarli in Spanner è utilizzare 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 di scrivere un semplice programma Java per impostare la lettura, la trasformazione e la scrittura dei dati. Esistono connettori Beam per Cloud Storage e Spanner, quindi l'unico codice che devi scrivere è la trasformazione degli stessi dati.

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 direttamente la pipeline di importazione di Spanner per importare collettivamente i dati, ma questo approccio richiede che i dati esistano in file Avro che utilizzano lo schema corretto.

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'utilità nativa di Change Data Capture (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) viene considerato la fonte di verità e, dopo ogni scrittura nel database, l'intera riga viene letta, convertita e scritta 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 dati siano stati trasferiti correttamente, puoi cambiare l'origine attendibile nel database Spanner. Questo meccanismo fornisce un percorso di rollback se vengono rilevati problemi durante il passaggio a Spanner.

Verifica la coerenza dei dati

Quando i dati vengono inseriti nel database Spanner, puoi eseguire periodicamente un confronto tra i dati di Spanner e quelli di MySQL per assicurarti che 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. I valori corrispondenti possono quindi essere confrontati per verificare se sono uguali. Puoi eseguire regolarmente questa verifica finché il livello di coerenza non corrisponde ai requisiti della tua attività.

Passaggio 6: passa a Spanner come fonte attendibile della tua applicazione

Quando hai la certezza che la migrazione dei dati sia andata a buon fine, puoi impostare la tua applicazione in modo che utilizzi Spanner come origine di riferimento. 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.

Esportare e importare 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 insieme di file Avro e file manifest JSON contenenti le tabelle esportate. Questi file possono avere vari scopi, tra cui:

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

Per ulteriori informazioni sulla procedura di esportazione e importazione, consulta Esportare i database e Importare i database.

Passaggi successivi