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 i prodotti Google Cloud e strumenti commerciali e open source. Insieme, questi strumenti consentono di velocizzare migrazioni e ridurre i rischi.
Qualsiasi migrazione di Spanner prevede le seguenti fasi fondamentali:
- Valuta la complessità della migrazione.
- Esegui la migrazione dello schema.
- Caricare i dati di esempio.
- Esegui la migrazione dell'applicazione.
- Testa e ottimizza il rendimento.
- Esegui la migrazione dei dati.
- Convalida la migrazione.
- Configurare meccanismi di cutover 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, 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 servizio Google Cloud 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 servizio Google Cloud che consente di scrivere una grande quantità di dati in Spanner in modo efficiente usando 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 di convalida dei dati creato da Google e supportato dalla community open source. Puoi integrare i DVT nei Google Cloud.
Strumenti di migrazione per i database di origine MySQL
Se il tuo database di origine è MySQL, puoi eseguire parte della migrazione iniziale utilizzando i file di dump di MySQL. Devi connetterti direttamente al database MySQL di origine in esecuzione per completare una migrazione in produzione.
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 |
|---|---|---|
| Test | 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 database di origine PostgreSQL
Se il tuo database di origine utilizza PostgreSQL, puoi eseguire alcuni le fasi della migrazione utilizzando un file di dump PostgreSQL. Devi connetterti direttamente al database PostgreSQL di origine in esecuzione per completare la migrazione.
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 |
|---|---|---|
| Test | Utilizza SMT con pg_dump. |
Utilizza DMA. |
| Conversione schema | Utilizza SMT con pg_dump. |
Utilizza SMT per configurare e convertire lo schema. |
| Caricamento 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 |
Valuta la complessità della migrazione
Per valutare l'ambito e la complessità della migrazione e pianificare il tuo approccio, devi raccogliere i 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 ottimizzare lo schema per Spanner. Ad esempio, puoi modificare 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 consigliate per le chiavi principali.
Strumento di migrazione Spanner, uno strumento open source gestito dalla community creato dagli sviluppatori di Google, crea automaticamente uno schema Spanner dal 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 la valutazione dello schema: consigli e migrazioni:
- Valutazione e consigli sulla compatibilità dei tipi di dati
- Modifica e consigli per le chiavi primarie
- 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 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 da testare 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
Una migrazione di database richiede driver e librerie diversi, per le funzionalità non supportate da Spanner. A ottimizzare in base ai punti di forza di Spanner, Potresti dover modificare il codice, i flussi delle applicazioni e l'architettura.
Ecco alcune delle modifiche necessarie per eseguire la migrazione della tua applicazione Spanner:
- Spanner non supporta l'esecuzione del codice utente a livello di database, quindi devi spostare le procedure e i trigger archiviati a livello di database nell'applicazione.
- Utilizzare le librerie client di Spanner e i mappatori relazionali di oggetti (ORM). Per ulteriori informazioni, consulta la panoramica delle API, delle librerie client e dei driver ORM.
- Se devi tradurre le query, traducile manualmente o utilizza altri strumenti di terze parti.
- Prendi nota del DML partizionato, transazioni di sola lettura, commit timestamp e leggere i timestamp e e come possono ottimizzare le prestazioni delle applicazioni.
Potrebbe anche essere necessario apportare modifiche alla gestione delle transazioni. Non sono disponibili strumenti per aiutarti, quindi devi completare questo passaggio manualmente. Conserva tieni presente quanto segue:
- Il limite di mutazioni per commit è 40.000. Ogni indice secondario su una tabella c'è 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 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 gestione dei blocchi per impostazione predefinita.
Testa e ottimizza le prestazioni di schema e applicazioni
L'ottimizzazione delle prestazioni è un processo iterativo in cui vengono valutate metriche come Utilizzo della CPU e latenza in base a un sottoinsieme dei tuoi dati (modifica lo schema) e l'applicazione per migliorare le prestazioni e ripetere il test.
Ad esempio, nello schema, potresti aggiungere o modificare un indice oppure modificare un e la chiave primaria. Nella tua applicazione, puoi eseguire scritture in batch, oppure unire modificare le query.
In particolare, per il traffico di produzione, l'ottimizzazione del rendimento è importante per evitare sorprese. La regolazione delle prestazioni è più efficace quanto più la configurazione è vicina al throughput e alle dimensioni dei dati del traffico di produzione in tempo reale.
Per testare e ottimizzare lo schema e il rendimento dell'applicazione:
- Carica un sottoinsieme di dati in un database Spanner. Per Per ulteriori informazioni, vedi Eseguire la migrazione dei dati.
- Indica l'applicazione a 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 aiutarti a identificare e ottimizzare
per le query costose,
Rileva i problemi di prestazioni delle query con Query Insights.
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 Esamina 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 in modo adeguato, esegui una query l'ottimizzazione non è molto utile.
- Hotspotting: gli hotspot in Spanner limitano la velocità effettiva di scrittura, soprattutto per le applicazioni con un valore QPS elevato. Per identificare hotspot o antipattern, controlla le statistiche di Visualizzatore dei parametri chiave dalla console Google Cloud. Per ulteriori informazioni evita le aree cliccabili, vedi Scegli una chiave primaria per impedire gli hotspot.
- Se modifichi lo schema o gli indici, ripeti la correttezza e le prestazioni fino a ottenere risultati soddisfacenti.
Per saperne di più sull'ottimizzazione delle prestazioni del database, contatta Supporto di 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 del database con tempi di inattività minimi o potresti aver bisogno di tempi di inattività prolungati.
Sia per le migrazioni con tempo di inattività minimo sia per quelle con tempo di inattività prolungato, 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 tempi 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 inattività minimi contribuiscano a proteggere i tuoi dati, il processo comporta delle sfide, tra cui:
- Archiviazione dei dati CDC durante la migrazione dello snapshot.
- Scrittura dei dati CDC in Spanner durante l'acquisizione dell'oggetto in entrata flusso CDC.
- Garantire che la migrazione dei dati CDC a 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 elementi processi per te:
- Configura un bucket Cloud Storage per archiviare gli eventi CDC sul database di origine durante l'avanzamento della migrazione dello snapshot.
- Configura un job Datastream che sposta la quantità collettiva carico di dati CDC e trasmette continuamente dati CDC incrementali al nel bucket Cloud Storage. Hai configurato il profilo di connessione di origine nello strumento di migrazione di Spanner.
- Configura il job Dataflow per eseguire la migrazione del 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. Questo porta in un breve tempo di inattività mentre Spanner raggiunge l'origine per configurare un database. 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 esportarli in formato CSV o Avro, quindi eseguire la migrazione a Spanner o un tempo di inattività. Ti consigliamo di utilizzare Dataflow o 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 in produzione, una migrazione con tempo di riposo può comportare la perdita di dati.
Per eseguire una migrazione in caso di inattività, segui questi passaggi generali:
- Genera un file dump dei dati dal database di origine.
- Carica il file di dump in Cloud Storage in un database MySQL, PostgreSQL, Avro o Formato di dump del file CSV.
- Carica il file di dump in Spanner utilizzando Dataflow o lo strumento di migrazione di Spanner.
La generazione di più file dump di piccole dimensioni rende più veloce la scrittura Spanner, poiché può leggere più file di dump in parallelo.
Quando generi un file di dump dal database di origine, per generare un un'istantanea 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, considera quanto segue:
- Per generare un dump Avro dei dati, utilizza uno strumento come DBeam. Per ulteriori informazioni sull'esportazione in Avro, consulta Esportare i 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 dati CSV, utilizza un job di importazione di Dataflow. Puoi creare il tuo modello di importazione Dataflow o utilizzare un modello di importazione Google Cloud. 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.
Strumento di convalida dei dati (DVT, Data Validation Tool) è 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:
- Controlla che tutte le tabelle siano state create e che tutte le mappature dello schema siano risposta corretta .
- Corrisponde al conteggio delle 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 ciclica o funzioni 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. 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.
- Inverti eventuali trasformazioni eseguite durante la migrazione.
- Esegui il push dei dati nella destinazione appropriata, tenendo conto schemi dello sharding nell'origine.