Questo documento descrive il processo di migrazione del database a Spanner. Descriviamo le fasi della migrazione e gli strumenti che consigliamo per ogni fase, a seconda del database di origine e di altri fattori. Gli strumenti consigliati includono i prodotti Google Cloud e gli strumenti commerciali e open source di terze parti. Insieme, questi strumenti consentono di accelerare le migrazioni e ridurre i rischi.
Qualsiasi migrazione di Spanner prevede le seguenti fasi fondamentali:
- Valuta la complessità della migrazione.
- Esegui la migrazione dello schema.
- Esegui la migrazione dell'applicazione.
- Testa e ottimizza le tue prestazioni.
- Eseguire la migrazione dei dati.
- Convalida la migrazione.
- Configurare meccanismi di cutover e failover.
Il seguente diagramma illustra questa procedura:
In queste fasi, il piano di migrazione può variare ampiamente in base a fattori quali origine e dimensioni del database, requisiti di inattività, complessità del codice dell'applicazione, schema dello sharding, funzioni o trasformazioni personalizzate e strategia di failover e replica.
Forniamo guide alla migrazione per Amazon DynamoDB, MySQL, Oracle Database e PostgreSQL. Se stai eseguendo la migrazione da uno di questi database, segui anche la guida pertinente:
- Eseguire la migrazione da MySQL
- Eseguire la migrazione da PostgreSQL a Spanner (dialetto GoogleSQL)
- Eseguire la migrazione da PostgreSQL a Spanner (dialetto PostgreSQL)
- Eseguire la migrazione dal database Oracle
- Eseguire la migrazione da DynamoDB
Se stai eseguendo la migrazione da un altro database, potresti aver bisogno di ulteriori personalizzazioni e strumenti non trattati in questa guida.
Strumenti di migrazione
Ti consigliamo di utilizzare gli strumenti seguenti per assisterti in varie fasi della migrazione, a seconda del database di origine e di altri fattori. Alcuni strumenti supportano solo determinati database di origine. Per alcuni passaggi della procedura non sono disponibili strumenti, quindi puoi completarli manualmente.
- Lo strumento di migrazione Spanner è uno strumento open source che esegue valutazioni di base nonché migrazioni di schemi e dati.
- Data Validation Tool (DVT) è un metodo standardizzato di convalida dei dati creato da Google e supportato dalla community open source. Puoi integrare DVT nei prodotti Google Cloud esistenti.
- Datastream è un servizio Google Cloud che consente di leggere gli eventi Change Data Capture (CDC) e i dati collettivi da un database di origine.
- Dataflow è un servizio Google Cloud che ti consente di scrivere grandi quantità di dati su Spanner in modo più efficiente utilizzando i modelli. Questi modelli non generano un file di dump, che deve essere generato dagli strumenti del database di origine o da strumenti di terze parti.
La tabella seguente riassume gli strumenti principali consigliati per ogni fase della migrazione per alcuni database di origine comuni. Puoi eseguire la migrazione da altri database con personalizzazioni.
| Database di origine | Valutare l'ambito | Eseguire la migrazione dello schema | Eseguire la migrazione dell'app | Eseguire la migrazione dei dati | Convalidare la migrazione dei dati | Configurare cutover e failover |
|---|---|---|---|---|---|---|
| MySQL | Manuale | Strumento di migrazione Spanner | Manuale | Strumento di migrazione Spanner | DVT | Manuale |
| PostgreSQL | Manuale | Strumento di migrazione Spanner | Manuale | Strumento di migrazione Spanner | DVT | Manuale |
| Altri database | Manuale | Strumento di migrazione Spanner | Manuale | Manuale | DVT | Manuale |
Valuta la complessità della migrazione
Per valutare l'ambito e la complessità della migrazione e pianificare l'approccio, è necessario raccogliere dati sul database di origine, tra cui:
- Pattern di query
- quantità di logica dell'applicazione che dipende dalle funzionalità dei database come stored procedure
- Requisiti hardware
- Costo totale di proprietà (TCO)
Esegui la migrazione dello schema
Prima di eseguire la migrazione di uno schema a uno schema Spanner, valuta la compatibilità tra gli schemi e ottimizza lo schema per Spanner. Ad esempio, potresti voler cambiare le chiavi, rilasciare o aggiungere indici oppure aggiungere o rimuovere colonne di tabelle esistenti. Per ottimizzare lo schema per Spanner, consulta le Best practice per la progettazione dello schema e le Strategie di migrazione della chiave primaria consigliate.
Lo strumento di migrazione Spanner, uno strumento open source gestito dalla community, creato dagli sviluppatori di Google, crea automaticamente uno schema Spanner a partire dallo schema del database di origine. Puoi personalizzare lo schema utilizzando l'assistente per lo schema dello strumento di migrazione di Spanner.
Lo strumento di migrazione di Spanner importa schema e dati da una delle seguenti località:
- Un file di dump da una posizione locale o da Cloud Storage (MySQL, PostgreSQL, CSV)
- Direttamente dal database di origine (MySQL, PostgreSQL)
Lo strumento di migrazione di Spanner esegue le seguenti funzioni per valutazioni, suggerimenti e migrazioni degli schemi:
- Valutazione e suggerimenti della compatibilità dei tipi di dati
- Modifica e suggerimenti della chiave primaria
- Modifica dell'indice secondario e suggerimenti
- Interconnessione della modifica delle tabelle e dei suggerimenti
- Suggerimenti generali sulla progettazione dello schema Spanner
- Controllo delle versioni dello schema
- Modifica collaborativa dello schema
Per maggiori informazioni sulle migrazioni dello schema con lo strumento di migrazione di Spanner, consulta il file README.md dello strumento di migrazione di Spanner.
Puoi utilizzare anche lo strumento di migrazione di Spanner per la migrazione dei dati.
Esegui la migrazione dell'applicazione
Una migrazione del database richiede driver e librerie diversi, oltre a una compensazione per le funzionalità non supportate da Spanner. Per ottenere funzionalità simili e ottimizzare in base ai punti di forza di Spanner, potrebbe essere necessario modificare il codice, i flussi di applicazioni e l'architettura.
Ecco alcune delle modifiche necessarie per eseguire la migrazione della tua applicazione a Spanner:
- Spanner non supporta l'esecuzione di codice utente a livello di database, quindi devi spostare nell'applicazione tutte le procedure e i trigger archiviati a livello di database.
- Usa le librerie client di Spanner e i mappatori relazionali di oggetti (ORM). Per ulteriori informazioni, consulta Panoramica di API, librerie client e driver ORM.
- Se hai bisogno di tradurre le query, traducile manualmente o utilizza altri strumenti di terze parti.
- Prendi nota di DML partizionato, transazioni di sola lettura, timestamp di commit e timestamp di lettura e di come possono ottimizzare le prestazioni dell'applicazione.
Potresti anche dover apportare modifiche alla gestione delle transazioni. Non sono disponibili strumenti, quindi devi completare questo passaggio manualmente. Tieni presente quanto segue:
- Il limite di mutazioni per commit è 40.000. Ogni indice secondario in una tabella è una mutazione aggiuntiva per riga. Per modificare i dati utilizzando le mutazioni, consulta Inserire, aggiornare ed eliminare i dati utilizzando le mutazioni. Per modificare una grande quantità di dati, utilizza il DML partizionato.
- Per il livello di isolamento delle transazioni, non è richiesta alcuna gestione perché le transazioni di Spanner sono più isolate.
- Poiché Spanner è linearizzabile, gestisce la coerenza e il blocco per impostazione predefinita.
Testa e ottimizza le prestazioni di schema e applicazioni
L'ottimizzazione delle prestazioni è un processo iterativo in cui valuti metriche come l'utilizzo e la latenza della CPU in base a un sottoinsieme di dati, regoli lo schema e l'applicazione per migliorare le prestazioni e ripeti i test.
Ad esempio, nello schema potresti aggiungere o modificare un indice oppure modificare una chiave primaria. Nella tua applicazione, puoi eseguire scritture in batch oppure unire o modificare le query.
In particolare per il traffico di produzione, l'ottimizzazione delle prestazioni è importante per evitare sorprese. L'ottimizzazione delle prestazioni è più efficace più la configurazione è vicina alla velocità effettiva del traffico di produzione e alle dimensioni dei dati.
Per testare e ottimizzare le prestazioni dello schema e dell'applicazione, segui questi passaggi:
- Caricare un sottoinsieme dei tuoi dati in un database Spanner. Per maggiori informazioni, vedi Eseguire la migrazione dei dati.
- Puntare l'applicazione a Spanner.
- Verifica la correttezza controllando i flussi di base.
- Verifica che le prestazioni soddisfino le tue aspettative eseguendo test di carico sull'applicazione. Per informazioni su come identificare e ottimizzare le query più costose, vedi Rilevare problemi di prestazioni delle query con Query Insights.
In particolare, i seguenti fattori possono contribuire a prestazioni delle query non ottimali:
- Query inefficienti: per informazioni sulla scrittura di query efficienti, consulta le best practice per SQL.
- Utilizzo elevato della CPU: per maggiori informazioni, consulta Esaminare l'utilizzo elevato della CPU.
- Blocco: per ridurre i colli di bottiglia causati dal blocco delle transazioni, consulta Identificare le transazioni che potrebbero causare latenze elevate.
- Progettazione dello schema inefficiente: se lo schema non è progettato bene, l'ottimizzazione delle query non è molto utile.
- Hotspotting: gli hotspot in Spanner limitano la velocità effettiva di scrittura, soprattutto per le applicazioni con QPS elevato. Per identificare hotspot o antipattern, controlla le statistiche di Key Visualizer nella console Google Cloud. Per ulteriori informazioni su come evitare gli hotspot, consulta Scegliere una chiave primaria per evitarli.
- Se modifichi lo schema o gli indici, ripeti i test di correttezza e prestazioni finché non ottieni risultati soddisfacenti.
Per ulteriori informazioni sull'ottimizzazione delle prestazioni del database, contatta l'assistenza di Spanner.
Eseguire la migrazione dei dati
Dopo aver ottimizzato lo schema Spanner ed eseguito la migrazione dell'applicazione, sposti i dati in un database Spanner vuoto di dimensioni di produzione, quindi passi al database Spanner.
A seconda del database di origine, potresti essere in grado di eseguire la migrazione del database con tempi di inattività minimi, oppure potresti richiedere tempi di inattività prolungati.
Per le migrazioni con tempi di inattività minimi e con tempi di inattività prolungati, ti consigliamo di utilizzare Dataflow e lo strumento di migrazione di Spanner.
La tabella seguente mostra le differenze tra le migrazioni con tempi di inattività minimi e quelle con tempi di inattività più lunghi, inclusi origini, formati, dimensioni e velocità effettiva supportati.
| Migrazione con tempi di inattività minimi | Migrazione con tempi di inattività | |
|---|---|---|
| Fonti supportate | MySQL e PostgreSQL | Qualsiasi database che possa essere esportato in formato CSV o Avro. |
| Formati di dati supportati | Mettiti in contatto direttamente con te. Consulta Connettersi direttamente a un database MySQL. | MySQL, PostgreSQL, CSV, Avro |
| Dimensioni dei database supportate | Nessun limite | Nessun limite |
| Velocità effettiva massima | 45 GB all'ora | 200 GB all'ora |
Migrazione con tempi di inattività minimi
Spanner supporta migrazioni con tempi di inattività minimi da database MySQL, PostgreSQL e Oracle. Una migrazione con tempi di inattività minimi è composta da due componenti:
- Uno snapshot coerente di tutti i dati nel database
- Il flusso di modifiche (inserimenti e aggiornamenti) da quello snapshot, indicato come Change Data Capture (CDC)
Sebbene le migrazioni con tempi di inattività minimi aiutino a proteggere i dati, il processo comporta problemi tra cui:
- Archiviazione dei dati CDC durante la migrazione dello snapshot.
- Scrittura dei dati CDC in Spanner durante l'acquisizione del flusso CDC in entrata.
- Assicurarsi che la migrazione dei dati CDC in Spanner sia più rapida del flusso CDC in entrata.
Per gestire una migrazione con tempi di inattività minimi, lo strumento di migrazione di Spanner orchestra i seguenti processi per te:
- Configura un bucket Cloud Storage per archiviare gli eventi CDC nel database di origine durante l'avanzamento della migrazione dello snapshot.
- Configura un job Datastream che sposta il caricamento collettivo dei dati CDC e invia continuamente dati CDC incrementali al bucket Cloud Storage. Puoi configurare il profilo di connessione di origine nello strumento di migrazione di Spanner.
- Configura il job Dataflow per eseguire la migrazione degli eventi CDC in Spanner.
Dopo che Dataflow ha copiato la maggior parte dei dati, smette di scrivere nel database di origine e attende il completamento della migrazione dei dati. Ciò si traduce in un breve tempo di inattività mentre Spanner raggiunge il database di origine. In seguito, l'applicazione può essere sottoposta a migrazione a Spanner.
Il seguente diagramma illustra questa procedura:
Migrazione con tempi di inattività
Per database diversi da MySQL, PostgreSQL o Oracle Database, se il database può essere esportato in formato CSV o Avro, puoi eseguire la migrazione a Spanner con il tempo di inattività. Ti consigliamo di utilizzare Dataflow o lo strumento di migrazione di Spanner.
Le migrazioni con tempi di inattività sono consigliate solo per ambienti di test o applicazioni in grado di gestire alcune ore di inattività. Su un database in tempo reale, una migrazione con tempi di inattività può comportare la perdita di dati.
Per eseguire una migrazione in caso di inattività, segui questi passaggi generali:
- Generare un file di dump dei dati dal database di origine.
- Carica il file di dump in Cloud Storage in formato MySQL, PostgreSQL, Avro o CSV.
- Carica il file di dump in Spanner usando Dataflow o lo strumento di migrazione di Spanner.
La generazione di più piccoli file dump rende più rapida la scrittura in Spanner, poiché Spanner può leggere più file dump in parallelo.
Quando generi un file di dump dal database di origine, tieni presente quanto segue per generare uno snapshot dei dati coerente:
- Per evitare che i dati cambino durante la generazione del file di dump, applica un blocco di lettura al database di origine prima di eseguirlo.
- Generare il file di dump utilizzando una replica di lettura dal database di origine con la replica disabilitata.
Formati consigliati per la migrazione collettiva
Avro è il formato preferito per una migrazione collettiva a Spanner. Se utilizzi Avro, considera quanto segue:
- Per generare un dump Avro dei dati, utilizza uno strumento come DBeam. Per ulteriori informazioni sull'esportazione in Avro, vedi Esportare dati da un database non Spanner in file Avro.
- Per importare dati Avro, utilizza un job di importazione di Dataflow. Per ulteriori informazioni, consulta Importare file Avro da database non Spanner a Spanner.
Se utilizzi un file CSV, considera quanto segue:
- Per generare un dump dei dati in formato CSV, utilizza la generazione di file CSV supportata dall'origine. Se i dati contengono nuove righe, utilizza un separatore di riga personalizzato.
- Per importare dati CSV, utilizza un job di importazione di Dataflow. Puoi creare il tuo modello di importazione Dataflow o utilizzare un modello di importazione di Google Cloud. Per ulteriori informazioni, consulta Modelli di pipeline di dati di Dataflow.
Se utilizzi MySQL o PostgreSQL, puoi usare lo strumento di migrazione di Spanner.
Per informazioni sull'utilizzo di script personalizzati per caricare i dati in Spanner, consulta Linee guida sulle prestazioni per il caricamento collettivo.
Convalidare la migrazione dei dati
La convalida dei dati è il processo di confronto dei dati provenienti dalle tabelle di origine e di destinazione per garantire la corrispondenza.
Data Validation Tool (DVT) è uno strumento open source in grado di connettersi ai datastore ed eseguire controlli tra l'origine e Spanner. Ti consigliamo di utilizzarlo per eseguire convalide di base durante la migrazione, ad esempio:
- Verifica che tutte le tabelle siano state create e che tutte le mappature dello schema siano corrette .
- Corrisponde al numero di righe per ogni tabella.
- Estrai righe casuali per verificarne la correttezza.
- Convalida le colonne (
count,sum,avg,min,max,group by). - Confronta eventuali controlli di ridondanza ciclici o funzioni di hash a livello di riga.
Per eseguire convalide più specifiche, crea controlli personalizzati durante la migrazione.
Configurare meccanismi di cutover e failover
Le migrazioni sono spesso complesse e dispendiose in termini di tempo. Integra i fallback per evitare un impatto significativo in caso di errore durante la migrazione, in modo da poter tornare al database di origine con tempi di inattività minimi.
Il suggerimento attuale è quello di utilizzare flussi di modifiche per eseguire la replica inversa e di riscrivere il database di origine tramite un flusso come Pub/Sub o Cloud Storage.
La replica inversa deve:
- Gestire le modifiche ai tipi di dati o ai contenuti.
- Inverti eventuali trasformazioni eseguite durante la migrazione.
- Esegui il push dei dati nella destinazione appropriata, tenendo conto degli schemi di partizionamento nell'origine.