Questo documento descrive il processo di migrazione del database a Spanner. Descriviamo le fasi della migrazione e gli strumenti a cui consigliata per ogni fase, a seconda del database di origine e di altri fattori. Gli strumenti consigliati includono i prodotti Google Cloud, nonché strumenti commerciali e open source di terze parti. 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 le tue prestazioni.
- 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 e la strategia di failover e replica.
Strumenti di migrazione
Ti consigliamo di utilizzare i seguenti strumenti per assisterti nelle varie fasi del tuo migrazione, a seconda del database di origine e di altri fattori. Alcuni strumenti supportano solo determinati database di origine. Per alcune fasi della procedura, non è stato disponibili, per permetterti di completare questi passaggi manualmente.
Strumento di migrazione Spanner (SMT) è uno strumento open source in grado di eseguire valutazioni di base, conversioni di schemi e alle migrazioni dei dati.
Valutazione della migrazione dei database (DMA) offre una valutazione di base per eseguire 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 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 di cui eseguire la migrazione:
- Dati esistenti nel database di origine.
- Flusso di modifiche apportate al database di origine durante la migrazione.
Lo strumento di convalida dei dati (DVT) è un metodo di convalida dei dati standardizzato 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 tuo database di origine è MySQL, puoi eseguire parte della migrazione iniziale utilizzando i file di 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 stai lavorando utilizzando un file di dump o collegando direttamente l'origine database:
| Fase di migrazione | File dump | Connessione diretta al database di origine |
|---|---|---|
| Test | Utilizza SMT con mysqldump. |
Utilizza SMT con mysqldump. |
| Conversione schema | Utilizza SMT con mysqldump. |
Utilizza SMT per configurare e convertire lo schema. |
| Caricamento 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. 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 che tu stia lavorando con un file di dump o connettendoti direttamente dall'origine database:
| 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 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, 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 ottimizzare lo schema per Spanner. Ad esempio, potresti voler modificare le chiavi, eliminare o aggiungere gli indici oppure aggiungere o rimuovere colonne di tabelle esistenti. per ottimizzare lo schema. per Spanner, Best practice di progettazione dello schema e Consigliati strategie di migrazione della chiave primaria.
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 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 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, vedi Carica dati di esempio.
Esegui la migrazione dell'applicazione
Una migrazione di database richiede driver e librerie diversi, 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 del codice utente a livello di database, quindi devi spostare le procedure e i 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.
- Prendi nota della DML partizionata, delle transazioni di sola lettura, dei timestamp di commit e dei timestamp di lettura e scopri come possono ottimizzare le prestazioni dell'applicazione.
Potresti anche dover apportare modifiche alla gestione delle transazioni. Non sono disponibili strumenti disponibile per aiutarti, 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 per impostazione predefinita.
Testa e ottimizza le prestazioni dello schema e dell'applicazione
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.
Per il traffico di produzione in particolare, l'ottimizzazione delle prestazioni è importante evitare sorprese. L'ottimizzazione delle prestazioni è più efficace, più la configurazione è vicina la velocità effettiva del traffico di produzione live e le 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, consulta 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
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.
- Blocco: per ridurre i colli di bottiglia causati dal blocco delle transazioni, vedi Identifica le transazioni che potrebbero causare elevate latenze.
- Progettazione dello schema inefficiente: se lo schema non è progettato in modo adeguato, esegui una query l'ottimizzazione non è molto utile.
- Hotspotting: gli hotspot nella velocità effettiva di scrittura del limite di Spanner, soprattutto per le applicazioni con un valore QPS elevato. Per identificare gli hotspot o anti-pattern, seleziona la casella Chiave Visualizzatore statistiche 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 ed eseguito la migrazione del sposterai i tuoi dati in un ambiente vuoto il database Spanner e poi si passa il 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.
Per le migrazioni con tempi di inattività minimi e per quelle con tempi di inattività prolungati, consigliamo di utilizzare Dataflow e lo strumento di migrazione Spanner.
La tabella seguente mostra le differenze tra le migrazioni con tempi di inattività minimi e migrazioni con tempi di inattività più lunghi, tra cui origini, formati, dimensioni e velocità effettiva.
| Migrazione con tempi di inattività minimi | Migrazione con tempi di inattività | |
|---|---|---|
| Origini supportate | MySQL, PostgreSQL | Qualsiasi database esportabile in formato CSV o Avro |
| Formati di dati supportati | Mettiti in contatto direttamente con te. Vedi direttamente e la connessione 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 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
- Il flusso di modifiche (inserimenti e aggiornamenti) da questo snapshot, noto come Change Data Capture (CDC, Change Data Capture).
Anche se le migrazioni con tempi di inattività minimi aiutano a proteggere i dati, il processo comporta 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 le seguenti operazioni:
- 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 degli eventi CDC in Spanner.
Quando Dataflow ha copiato la maggior parte dei dati, smette di scrivere in il 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 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 tempo reale, la 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 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 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 evitare che i dati cambino durante la generazione del file di dump, prima di eseguire il dump, applica un blocco di lettura sul database di origine.
- Genera il file di dump utilizzando una replica di lettura dal database di origine con e 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, consulta Esporta i 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 in Spanner.
Se utilizzi CSV, tieni presente quanto segue:
- Per generare un dump dei dati in formato CSV, utilizza la generazione di file CSV supportata sorgente. 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 Google Cloud. Per ulteriori informazioni, vedi 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 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 verifiche 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 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 di hash a livello di riga.
Per eseguire convalide più specifiche, crea controlli personalizzati durante la migrazione.
Configura i meccanismi di transizione e failover
Le migrazioni sono spesso complesse e richiedono molto tempo. Integra i video di riserva per evitare un impatto significativo in caso di errore durante la migrazione, consentendoti di passare tornare al database di origine con tempi di inattività minimi.
Il consiglio attuale è di utilizzare cambia flussi per eseguire la replica inversa e scrivere nel database di origine attraverso 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.
- Invia i dati alla destinazione appropriata, tenendo conto degli schemi di sharding nell'origine.