Questo documento descrive la procedura di migrazione del database a Spanner. Descriviamo le fasi della migrazione e gli strumenti consigliati per ogni fase, a seconda del database di origine e di altri fattori. Gli strumenti consigliati includono Google Cloud prodotti e strumenti commerciali e open source di terze parti. Insieme, questi strumenti ti aiutano ad accelerare le migrazioni e a ridurre i rischi.
Qualsiasi migrazione di Spanner prevede le seguenti fasi principali:
- Valuta la complessità della migrazione.
- Esegui la migrazione dello schema.
- Carica i dati di esempio.
- Esegui la migrazione dell'applicazione.
- Testa e ottimizza le prestazioni.
- Esegui la migrazione dei dati.
- Convalida la migrazione.
- Configura i meccanismi di passaggio e failover.
All'interno di queste fasi, il piano di migrazione può variare notevolmente a seconda di fattori come la dimensione e l'origine del database, i requisiti di tempo di inattività, la complessità del codice dell'applicazione, lo schema di sharding, le funzioni o trasformazioni personalizzate e la strategia di failover e replica.
Strumenti di migrazione
Ti consigliamo di utilizzare i seguenti strumenti per ricevere assistenza 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 è disponibile alcuno strumento, pertanto dovrai completarli manualmente.
Lo strumento di migrazione Spanner (SMT) è uno strumento open source che può eseguire valutazioni di base, conversione dello schema e migrazioni dei dati.
Database Migration Assessment (DMA) offre una valutazione di base per la migrazione di PostgreSQL a Spanner.
Datastream è un Google Cloud servizio che ti consente di leggere eventi CDC (Change Data Capture) e dati collettivi da un database di origine e di scrivere in una destinazione specificata.
Dataflow è un Google Cloud servizio che ti aiuta a scrivere una grande quantità di dati in Spanner in modo più efficiente utilizzando i modelli.
Migrazione collettiva dei dati è un modello Dataflow che consente di eseguire la migrazione di grandi set di dati MySQL direttamente in Spanner.
La migrazione con tempi di inattività minimi utilizza Datastream e Dataflow per eseguire la migrazione di:
- Dati esistenti nel database di origine.
- Stream di modifiche apportate al database di origine durante la migrazione.
Lo strumento di convalida dei dati (DVT) è un metodo standardizzato per la convalida dei dati creato da Google e supportato dalla community open source. Puoi integrare la DVT nei prodotti Google Cloud esistenti.
Strumenti di migrazione per i database di origine MySQL
Se il database di origine è MySQL, puoi eseguire alcune delle fasi iniziali della migrazione utilizzando i file dump di MySQL. Per completare una migrazione in produzione, devi collegarti direttamente al database MySQL di origine in esecuzione.
La tabella seguente consiglia gli strumenti di migrazione in base alla fase di migrazione e se utilizzi un file dump o colleghi direttamente il database di origine:
| Fase di migrazione | File dump | Connessione diretta al database di origine |
|---|---|---|
| Valutazione | Utilizza SMT con mysqldump. |
Utilizza SMT con mysqldump. |
| Conversione dello schema | Utilizza SMT con mysqldump. |
Utilizza SMT per configurare e convertire lo schema. |
| Caricamento di dati di esempio |
|
Esegui una migrazione collettiva. |
| Migrazione dei dati | Non applicabile | Esegui una migrazione collettiva, quindi una migrazione con tempi di inattività minimi. |
| Convalida dei dati | Non applicabile | Utilizza DVT. |
| Configurazione del failover | Non applicabile | Utilizza SMT per la replica inversa. |
Strumenti di migrazione per i database di origine PostgreSQL
Se il database di origine utilizza PostgreSQL, puoi eseguire alcune delle fasi di migrazione utilizzando un file dump PostgreSQL. Per completare la migrazione, devi collegarti direttamente al database PostgreSQL di origine in esecuzione.
La tabella seguente consiglia gli strumenti di migrazione in base alla fase di migrazione e se stai lavorando con un file dump o ti connetti direttamente dal database di origine:
| Fase di migrazione | File dump | Connessione diretta al database di origine |
|---|---|---|
| Valutazione | Utilizza SMT con pg_dump. |
Utilizza DMA. |
| Conversione dello schema | Utilizza SMT con pg_dump. |
Utilizza SMT per configurare e convertire lo schema. |
| Carico di dati di esempio |
|
Esegui una migrazione con tempi di inattività minimi. |
| Migrazione dei dati | Non applicabile | Esegui una migrazione con tempi di inattività minimi. |
| Convalida dei dati | Non applicabile | Utilizza DVT. |
| Failover | Non applicabile | Non applicabile |
Valutare la complessità della migrazione
Per valutare l'ambito e la complessità della migrazione e pianificare il tuo approccio, devi raccogliere dati sul database di origine, tra cui:
- Pattern di query
- Quantità di logica di applicazione che dipende dalle funzionalità del database, come procedure e trigger memorizzati
- 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 modificare le chiavi, eliminare o aggiungere indici o 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 consigliate per le chiavi principali.
Lo strumento di migrazione Spanner, uno strumento open source gestito dalla community creato dagli sviluppatori di Google, consente di creare automaticamente uno schema Spanner dallo schema del database di origine. Puoi personalizzare lo schema utilizzando l'assistente per gli schemi dello strumento di migrazione di Spanner.
Lo strumento di migrazione di Spanner importa lo schema e i dati da una delle seguenti posizioni:
- 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 Spanner esegue le seguenti funzioni per valutazioni, consigli e migrazioni dello schema:
- Valutazione e consigli sulla compatibilità dei tipi di dati
- Modifica e consigli per le chiavi principali
- Modifica e consigli per gli indici secondari
- Modifica e suggerimenti della tabella interlacciati
- Suggerimenti generali per la progettazione dello schema di Spanner
- Controllo delle versioni dello schema
- Modifica dello schema collaborativo
Per ulteriori 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 lo strumento di migrazione di Spanner anche per la migrazione dei dati.
Carica i dati di esempio
Dopo aver creato uno schema compatibile con Spanner, puoi preparare il database per il test utilizzando dati di esempio. Puoi utilizzare il flusso di lavoro ETL inverso di BigQuery per caricare i dati di esempio. Per ulteriori informazioni, consulta Caricare dati di esempio.
Esegui la migrazione dell'applicazione
La migrazione di un database richiede driver e librerie diversi, nonché compensazione per le funzionalità non supportate da Spanner. Per ottimizzare in base alle caratteristiche di Spanner, potrebbe essere necessario modificare il codice, i flussi di applicazione e l'architettura.
Di seguito sono riportate alcune delle modifiche necessarie per eseguire la migrazione dell'applicazione a Spanner:
- Spanner non supporta l'esecuzione di codice utente a livello di database, quindi devi spostare eventuali procedure e trigger archiviati a livello di database nell'applicazione.
- Utilizza le librerie client di Spanner e i mapper oggetto-relazionale (ORM). Per ulteriori 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.
- Tieni presente la DML partizionata, le transazioni di sola lettura, i timestamp di commit e i timestamp di lettura e come possono ottimizzare il rendimento delle applicazioni.
Potrebbe anche essere necessario apportare modifiche alla gestione delle transazioni. Non sono disponibili strumenti per aiutarti, quindi devi completare questo passaggio manualmente. Tieni presente quanto segue:
- Il limite di mutazioni per commit è 40.000. Ogni indice secondario di una tabella rappresenta un'ulteriore mutazione 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 DML partizionato.
- Per il livello di isolamento delle transazioni, non è richiesta alcuna gestione perché le transazioni Spanner sono più isolate.
- Poiché Spanner è linearizzabile, gestisce la coerenza e la chiusura per impostazione predefinita.
Testa e ottimizza lo schema e le prestazioni dell'applicazione
L'ottimizzazione delle prestazioni è un processo iterativo in cui valuti metriche come l'utilizzo della CPU e la latenza in base a un sottoinsieme di dati, modifichi lo schema e l'applicazione per migliorare le prestazioni e esegui nuovamente il test.
Ad esempio, nello schema puoi aggiungere o modificare un indice o una chiave primaria. Nella tua applicazione, puoi eseguire scritture collettive o unire o modificare le query.
Per il traffico di produzione in particolare, l'ottimizzazione del rendimento è importante per evitare sorprese. La messa a punto delle prestazioni è più efficace quanto più la configurazione è vicina al throughput del traffico di produzione in tempo reale e alle dimensioni dei dati.
Per testare e ottimizzare le prestazioni dello schema e dell'applicazione:
- Carica un sottoinsieme di dati in un database Spanner. Per maggiori informazioni, consulta Eseguire la migrazione dei dati.
- Indica all'applicazione di utilizzare Spanner.
- Verifica la correttezza controllando i flussi di base.
- Verifica che le prestazioni soddisfino le tue aspettative eseguendo test di carico sulla tua applicazione. Per assistenza su come identificare e ottimizzare le query più costose, consulta Rilevare i problemi di prestazioni delle query con gli insight sulle query.
In particolare, i seguenti fattori possono contribuire a un rendimento suboptimale delle query:
- Query inefficienti: per informazioni su come scrivere query efficienti, consulta le best practice per SQL.
- Utilizzo elevato della CPU: per ulteriori informazioni, consulta Esaminare l'utilizzo elevato della CPU.
- Blocchi: 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 correttamente, l'ottimizzazione delle query non è molto utile.
- Hotspot: gli hotspot in Spanner limitano il throughput delle scritture, soprattutto per le applicazioni con un elevato QPS. Per identificare hotspot o antipattern, controlla le statistiche di Visualizzatore dei parametri chiave dalla console Google Cloud. Per ulteriori 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 prestazioni finché non ottieni risultati soddisfacenti.
Per ulteriori informazioni sulla messa a punto del rendimento del database, contatta l'assistenza Spanner.
Migrazione dei dati
Dopo aver ottimizzato lo schema Spanner e aver eseguito la migrazione dell'applicazione, sposta i dati in un database Spanner vuoto di dimensioni di produzione, quindi passa al database Spanner.
A seconda del database di origine, potresti essere in grado di eseguire la migrazione con tempi di inattività minimi oppure potresti richiedere tempi di inattività prolungati.
Sia per le migrazioni con tempi di inattività minimi sia per quelle con tempi di inattività prolungati, consigliamo di utilizzare Dataflow e lo strumento di migrazione di Spanner.
La tabella seguente mostra le differenze tra le migrazioni con tempi di riposo minimi e quelle con tempi di riposo più lunghi, tra cui origini, formati, dimensioni e throughput supportati.
| Migrazione con tempi di inattività minimi | Migrazione con tempo di inattività | |
|---|---|---|
| Origini supportate | MySQL, PostgreSQL | Qualsiasi database che può esportare in CSV o Avro. |
| Formati di dati supportati | Connettiti direttamente. Consulta Eseguire una 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 le 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
- Lo stream di modifiche (inserimenti e aggiornamenti) dall'ultimo snapshot, chiamato Change Data Capture (CDC)
Sebbene le migrazioni con tempi di riposo minimi contribuiscano a proteggere i dati, il processo comporta delle sfide, tra cui:
- Archiviazione dei dati CDC durante la migrazione dello snapshot.
- Scrivere i dati CDC in Spanner durante l'acquisizione dello stream CDC in entrata.
- Assicurati che la migrazione dei dati CDC a Spanner sia più rapida dello stream CDC in entrata.
Per gestire una migrazione con tempi di inattività minimi, lo strumento di migrazione di Spanner orchestra le seguenti operazioni:
- Configura un bucket Cloud Storage per archiviare gli eventi CDC nel database di origine durante la migrazione degli snapshot.
- Configura un job Datastream che sposta il caricamento collettivo dei dati CDC e trasmette continuamente i dati CDC incrementali al bucket Cloud Storage. Devi configurare il profilo di connessione di origine all'interno dello strumento di migrazione di Spanner.
- Configura il job Dataflow per eseguire la migrazione degli eventi CDC in Spanner.
Quando Dataflow ha copiato la maggior parte dei dati, interrompe la scrittura nel database di origine e attende il completamento della migrazione dei dati. Ciò comporta un breve tempo di inattività mentre Spanner si allinea al database di origine. In seguito, l'applicazione può essere trasferita a Spanner.
Questa procedura è illustrata nel seguente diagramma:
Migrazione con tempi di inattività
Per i database diversi da MySQL, PostgreSQL o Oracle Database, se il database può esportare in CSV o Avro, puoi eseguire la migrazione a Spanner con tempo di inattività. Ti consigliamo di utilizzare Dataflow o lo strumento di migrazione di Spanner.
Le migrazioni con tempi di riposo sono consigliate solo per ambienti di test o applicazioni in grado di gestire alcune ore di inattività. In un database attivo, una migrazione con tempo di riposo può comportare la perdita di dati.
Per eseguire una migrazione con tempo di riposo, segui questi passaggi di alto livello:
- Genera un file dump dei dati dal database di origine.
- Carica il file di dump in Cloud Storage in un formato di dump MySQL, PostgreSQL, Avro o CSV.
- Carica il file dump in Spanner utilizzando Dataflow o lo strumento di migrazione di Spanner.
La generazione di più file dump di piccole dimensioni consente di scrivere più velocemente in Spanner, in quanto Spanner può leggere più file dump in parallelo.
Quando generi un file di dump dal database di origine, per generare uno snapshot coerente dei dati, tieni presente quanto segue:
- Per impedire la modifica dei dati durante la generazione del file 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 disattivata.
Formati consigliati per la migrazione collettiva
Avro è il formato preferito per una migrazione collettiva a Spanner. Se utilizzi Avro, tieni presente quanto segue:
- Per generare un dump Avro dei dati, utilizza uno strumento come DBeam. Per ulteriori informazioni sull'esportazione in Avro, consulta Esportare dati da un database non Spanner in file Avro.
- Per importare i 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 di file 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 Google Cloud modello di importazione. Per ulteriori informazioni, consulta Modelli di pipeline di dati Dataflow.
Se utilizzi MySQL o PostgreSQL, puoi utilizzare lo strumento di migrazione 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 delle tabelle di origine e di destinazione per assicurarsi che corrispondano.
Lo strumento di convalida dei dati (DVT) è uno strumento open source che può connettersi ai data store ed eseguire controlli tra l'origine e Spanner. Ti consigliamo di utilizzarlo per eseguire verifiche 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 conteggio delle 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 ciclica o funzioni hash a livello di riga.
Per eseguire convalide più specifiche, crea controlli personalizzati durante la migrazione.
Configura i meccanismi di passaggio e failover
Le migrazioni sono spesso complesse e richiedono molto tempo. Implementa soluzioni di riserva per evitare un impatto significativo in caso di errore durante la migrazione, in modo da poter tornare al database di origine con un tempo di inattività minimo.
Il consiglio attuale è di utilizzare stream di variazioni per eseguire la replica inversa e scrivere nuovamente nel database di origine tramite uno stream come Pub/Sub o Cloud Storage.
La replica inversa deve:
- Gestire le modifiche ai tipi di dati o ai contenuti.
- Annullare le trasformazioni eseguite durante la migrazione.
- Invia i dati alla destinazione appropriata, tenendo conto degli schemi di sharding nell'origine.