Questo documento descrive il processo di migrazione del database a Spanner. Descrivi 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 strumenti commerciali e open source di terze parti. Insieme, questi strumenti aiutano ad accelerare le migrazioni e a ridurre i rischi.
Qualsiasi migrazione di Spanner prevede le seguenti fasi principali:
- Valuta la complessità della tua migrazione.
- Esegui la migrazione dello schema.
- Esegui la migrazione della tua applicazione.
- Testa e ottimizza il tuo rendimento.
- Eseguire la migrazione dei dati.
- Convalida la migrazione.
- Configura meccanismi del cutover e failover.
Il seguente diagramma illustra questa procedura:
All'interno di queste fasi, il piano di migrazione può variare notevolmente in base a fattori quali origine e dimensioni del database, requisiti di tempo di inattività, complessità del codice dell'applicazione, schema di 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)
- Esegui la migrazione da PostgreSQL a Spanner (dialetto PostgreSQL)
- Esegui la migrazione da un database Oracle
- Eseguire la migrazione da DynamoDB
Se esegui 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 i seguenti strumenti per assisterti nelle 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 completare questi passaggi manualmente.
- Lo strumento di migrazione di Spanner è uno strumento open source che esegue valutazioni di base e 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 la DVT nei prodotti Google Cloud esistenti.
- Datastream è un servizio Google Cloud che consente di leggere gli eventi CDC (Change Data Capture) e i dati in blocco da un database di origine.
- Dataflow è un servizio Google Cloud che consente di scrivere grandi quantità di dati in Spanner in modo più efficiente utilizzando i modelli. Questi modelli non generano un file di dump; il file di dump deve essere generato dagli strumenti del database di origine o da strumenti di terze parti.
La seguente tabella riassume gli strumenti principali che consigliamo 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 | Convalida della migrazione dei dati | Configura il cutover e il failover |
|---|---|---|---|---|---|---|
| MySQL | Manuale | Strumento di migrazione di Spanner | Manuale | Strumento di migrazione di Spanner | DVT | Manuale |
| PostgreSQL | Manuale | Strumento di migrazione di Spanner | Manuale | Strumento di migrazione di Spanner | DVT | Manuale |
| Altri database | Manuale | Strumento di migrazione di Spanner | Manuale | Manuale | DVT | Manuale |
Valuta la complessità della migrazione
Per valutare l'ambito e la complessità della migrazione e pianificare l'approccio, devi raccogliere dati sul database di origine, tra cui:
- Pattern di query
- Quantità di logica dell'applicazione che dipende da funzionalità del database, come stored procedure e trigger
- 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 il tuo schema per Spanner. Ad esempio, potresti voler modificare le chiavi, rilasciare o aggiungere indici oppure aggiungere o rimuovere colonne di tabelle esistenti. Per ottimizzare lo schema per Spanner, consulta Best practice per la progettazione degli schemi e Strategie consigliate per la migrazione delle chiavi principali.
Lo strumento di migrazione di Spanner, uno strumento open source gestito dalla community e creato da sviluppatori Google, crea automaticamente uno schema Spanner dallo schema del database di origine. Puoi personalizzare lo schema utilizzando l'assistente schema dello strumento di migrazione di Spanner.
Lo strumento di migrazione di Spanner importa schema e dati da una delle seguenti posizioni:
- Un file di dump da una posizione locale o su 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 dello schema:
- Valutazione e consigli sulla compatibilità dei tipi di dati
- Modifica della chiave primaria e consigli
- Modifica dell'indice secondario e suggerimenti
- Interleaving della modifica delle tabelle e dei consigli
- Suggerimenti generali sulla progettazione dello schema Spanner
- Controllo delle versioni dello schema
- Modifica collaborativa dello schema
Per saperne di più sulle migrazioni degli schemi con lo strumento di migrazione di Spanner, consulta il file README.md dello strumento di migrazione di Spanner.
Puoi utilizzare lo strumento di migrazione di Spanner anche per la migrazione dei dati.
Esegui la migrazione dell'applicazione
Una migrazione di database richiede driver e librerie diversi, oltre a una compensazione per le funzionalità non supportate da Spanner. Per ottenere funzionalità simili ed eseguire l'ottimizzazione in base ai punti di forza di Spanner, potrebbe essere necessario modificare il codice, i flussi dell'applicazione e l'architettura.
Ecco alcune delle modifiche necessarie per eseguire la migrazione della tua applicazione a Spanner:
- Spanner non supporta l'esecuzione del codice utente a livello di database, perciò devi spostare nell'applicazione tutte le procedure e i trigger archiviati a livello di database.
- Utilizza le librerie client di Spanner e i mappatori relazionali degli oggetti (ORM). Per maggiori informazioni, consulta la Panoramica di API, librerie client e driver ORM.
- Se devi tradurre le query, traducile manualmente o utilizza altri strumenti di terze parti.
- Prendi nota di DML partizionato, transazioni di sola lettura, timestamp di commit, timestamp di lettura e come possono ottimizzare le prestazioni delle applicazioni.
Potresti anche dover apportare modifiche alla gestione delle transazioni. Non sono disponibili strumenti che ti aiutino a eseguire questa operazione, 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 modifica 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 un DML partizionato.
- Per il livello di isolamento delle transazioni, non è necessaria 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 dello schema e dell'applicazione
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, modifichi lo schema e l'applicazione per migliorare le prestazioni ed esegui ulteriori test.
Ad esempio, nello schema, puoi aggiungere o modificare un indice oppure modificare una chiave primaria. Nella tua applicazione potresti eseguire operazioni di scrittura in batch oppure unire o modificare le query.
Per il traffico di produzione in particolare, l'ottimizzazione delle prestazioni è importante per evitare sorprese. L'ottimizzazione delle prestazioni è più efficace quanto la configurazione è vicina alla velocità effettiva del traffico di produzione in tempo reale e alle dimensioni dei dati.
Per testare e ottimizzare le prestazioni dello schema e dell'applicazione, segui questi passaggi:
- Carica un sottoinsieme dei tuoi dati in un database Spanner. Per ulteriori informazioni, consulta Eseguire la migrazione dei dati.
- Indirizza 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, consulta Rilevamento dei problemi di prestazioni delle query con Query Insights.
In particolare, i seguenti fattori possono contribuire a prestazioni
non ottimali delle query:
- Query non efficaci: per informazioni sulla scrittura di query efficienti, consulta le best practice per SQL.
- Utilizzo elevato della CPU: per saperne di più, consulta Indagare sull'utilizzo elevato della CPU.
- Blocco: per ridurre i colli di bottiglia causati dal blocco delle transazioni, vedi Identificare le transazioni che potrebbero causare latenze elevate.
- Progettazione inefficiente dello schema: se lo schema non è progettato bene, l'ottimizzazione delle query non è molto utile.
- Hotspotting: gli hotspot in Spanner limitano la velocità effettiva di scrittura, in particolare per le applicazioni con QPS elevato. Per identificare hotspot o anti-pattern, controlla le statistiche di Key Visualizer dalla console Google Cloud. Per maggiori informazioni su come evitare gli hotspot, consulta Scegliere una chiave primaria per evitare gli hotspot.
- Se modifichi lo schema o gli indici, ripeti i test di correttezza e di prestazioni fino a quando non ottieni risultati soddisfacenti.
Per ulteriori informazioni sul perfezionamento delle prestazioni del database, contatta l'assistenza di Spanner.
Eseguire la migrazione dei dati
Dopo aver ottimizzato lo schema Spanner e aver eseguito la migrazione dell'applicazione, sposta i dati in un database Spanner di dimensioni di produzione vuoto e quindi passa al database di Spanner.
A seconda del database di origine, potresti essere in grado di eseguire la migrazione del database con tempi di inattività minimi o tempi di inattività prolungati.
Per le migrazioni con tempi di inattività minimi e per quelle con tempi di inattività prolungati, ti consigliamo di utilizzare Dataflow e lo strumento di migrazione di Spanner.
La seguente tabella mostra le differenze tra migrazioni con tempi di inattività minimi e migrazioni con tempi di inattività maggiori, tra cui origini, formati, dimensioni e velocità effettiva supportati.
| Migrazione con tempi di inattività minimi | Migrazione con tempi di inattività | |
|---|---|---|
| Origini supportate | MySQL e PostgreSQL | Qualsiasi database che può essere esportato in formato CSV o Avro. |
| Formati di dati supportati | Comunica direttamente. Consulta Connessione diretta a un database MySQL. | MySQL, PostgreSQL, CSV, Avro |
| Dimensioni del 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 MySQL, PostgreSQL e Oracle Database. Una migrazione con tempi di inattività minimi è costituita da due componenti:
- Uno snapshot coerente di tutti i dati nel database
- Il flusso di modifiche (inserimenti e aggiornamenti) a partire dallo snapshot, definito Change Data Capture (CDC)
Anche se le migrazioni con tempi di inattività minimi aiutano a proteggere i tuoi dati, il processo prevede 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.
- Garantire che la migrazione dei dati CDC a Spanner sia più rapida rispetto al flusso CDC in entrata.
Per gestire una migrazione con tempi di inattività minimi, lo strumento di migrazione di Spanner orchestra per te i seguenti processi:
- Configura un bucket Cloud Storage per archiviare gli eventi CDC nel database di origine durante l'avanzamento della migrazione degli snapshot.
- Configura un job Datastream che sposta il caricamento collettivo dei dati CDC e trasmette in modo continuo di dati CDC incrementali nel bucket Cloud Storage. Puoi configurare il profilo di connessione di origine nello strumento di migrazione di Spanner.
- Imposta il job Dataflow per eseguire la migrazione degli eventi CDC in Spanner.
Quando Dataflow ha copiato la maggior parte dei dati, smette di scrivere nel database di origine e attende che la migrazione dei dati venga completata. Ciò comporta un breve tempo di inattività mentre Spanner raggiunge il database di origine. In seguito, l'applicazione può essere eseguita su Spanner.
Il seguente diagramma illustra questa procedura:
Migrazione con tempo 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 tempi di inattività. Ti consigliamo di utilizzare Dataflow o lo strumento di migrazione di Spanner.
Le migrazioni con tempi di inattività sono consigliate solo per applicazioni o ambienti di test in grado di gestire alcune ore di tempo di inattività. Una migrazione con tempi di inattività di un database in tempo reale può causare la perdita di dati.
Per eseguire una migrazione per il tempo di inattività, segui questi passaggi generali:
- Genera un file di dump dei dati dal database di origine.
- Carica il file di dump in Cloud Storage in formato di dump MySQL, PostgreSQL, Avro o CSV.
- Carica il file di dump in Spanner utilizzando Dataflow o lo strumento di migrazione di Spanner.
La generazione di più file di dump di piccole dimensioni velocizza la scrittura in Spanner poiché Spanner può leggere più file di dump contemporaneamente.
Quando generi un file di dump dal database di origine, tieni presente quanto segue per generare un'istantanea coerente dei dati:
- Per impedire la modifica dei dati durante la generazione del file di dump, prima di eseguire il dump, applica un blocco di lettura al database di origine.
- Genera 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 maggiori informazioni sull'esportazione in Avro, consulta Esportare i dati da un database non Spanner in file Avro.
- Per importare dati Avro, utilizza un job di importazione Dataflow. Per ulteriori informazioni, consulta Importare file Avro da database non Spanner in Spanner.
Se utilizzi CSV, tieni presente quanto segue:
- Per generare un dump CSV dei dati, utilizza la generazione CSV supportata dall'origine. Se i dati contengono nuove righe, utilizza un separatore di riga personalizzato.
- Per importare i dati CSV, utilizza un job di importazione Dataflow. Puoi creare il tuo modello di importazione Dataflow o utilizzare un modello di importazione di Google Cloud. Per maggiori informazioni, consulta Modelli di pipeline di dati Dataflow.
Se usi MySQL o PostgreSQL, puoi utilizzare lo strumento di migrazione di Spanner.
Per informazioni sull'utilizzo di script personalizzati per caricare dati in Spanner, consulta le linee guida sulle prestazioni per il caricamento collettivo.
Convalidare la migrazione dei dati
La convalida dei dati è il processo di confronto dei dati delle tabelle di origine e delle tabelle di destinazione per garantirne 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 come parte della migrazione, ad esempio quanto segue:
- Controlla che siano state create tutte le tabelle e che tutti i mapping dello schema siano corretti .
- Crea una corrispondenza con il numero di righe per ogni tabella.
- Estrai righe casuali per verificare la correttezza.
- Convalida le colonne (
count,sum,avg,min,max,group by). - Confronta eventuali controlli di ridondanza ciclici o funzioni hash a livello di riga.
Per eseguire convalide più specifiche, crea controlli personalizzati durante la migrazione.
Configura meccanismi del cutover e failover
Le migrazioni sono spesso complesse e dispendiose in termini di tempo. Crea elementi di riserva 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.
Attualmente il suggerimento è utilizzare flussi di modifiche per eseguire la replica inversa e scrivere nuovamente nel database di origine attraverso un flusso come Pub/Sub o Cloud Storage.
La replica inversa deve:
- Gestire le modifiche apportate ai tipi di dati o ai contenuti.
- Inverti tutte le trasformazioni eseguite durante la migrazione.
- Esegui il push dei dati nella destinazione appropriata, tenendo conto degli schemi di suddivisione in blocchi sull'origine.