Panoramica della migrazione

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 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:

  1. Valuta la complessità della migrazione.
  2. Esegui la migrazione dello schema.
  3. Esegui la migrazione dell'applicazione.
  4. Testa e ottimizza le tue prestazioni.
  5. Eseguire la migrazione dei dati.
  6. Convalida la migrazione.
  7. Configurare meccanismi di cutover e failover.

Il seguente diagramma illustra questa procedura:

Diagramma del processo di migrazione che mostra valutazione, schema e applicazione migrazione, test e ottimizzazione, migrazione dei dati, il cutover.

In queste fasi, il piano di migrazione può variare notevolmente in base a fattori come origine e dimensione del database, requisiti di inattività, codice dell'applicazione complessità, schema dello sharding, funzioni o trasformazioni personalizzate e failover e la strategia di 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 le guida pertinente:

Se stai eseguendo la migrazione da un altro database, potresti aver bisogno di ulteriori strumenti e personalizzazioni non trattati in questa guida.

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. Solo alcuni strumenti supportare determinati database di origine. Per alcune fasi della procedura, non è stato disponibili, per permetterti di completare questi passaggi manualmente.

  • Strumento di migrazione Spanner è uno strumento open source che esegue valutazioni di base, oltre a schemi e delle migrazioni di dati.
  • Strumento di convalida dei dati (DVT, Data Validation Tool) è un metodo di convalida dei dati standardizzato creato da Google e supportato open source. Puoi integrare i DVT nei Google Cloud.
  • Datastream è un servizio Google Cloud che consente di leggere gli eventi Change Data Capture (CDC) e i dati collettivi da un del database di origine.
  • Dataflow è un servizio Google Cloud che consente di scrivere più grandi quantità di dati in Spanner in modo efficiente usando i modelli. Questi modelli non generano un file di dump, il file di dump deve essere generato dagli strumenti del database di origine strumenti di terze parti.

La seguente tabella riassume gli strumenti principali consigliati per ogni fase di migrazione per alcuni database di origine comuni. Puoi eseguire la migrazione e 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 il tuo approccio, raccogliere dati sul database di origine, tra cui:

  • Pattern di query
  • Quantità di logica dell'applicazione che dipende dalle funzionalità del database come 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 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, 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 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 saperne di più sulle migrazioni dello schema con lo strumento di migrazione di Spanner, consulta 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 di database richiede driver e librerie diversi, per le funzionalità non supportate da Spanner. A ottenere funzionalità simili e 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, vedi Panoramica di API, librerie client e 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.

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 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.

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:

  1. Caricare un sottoinsieme dei tuoi dati in un database Spanner. Per Per ulteriori informazioni, vedi Eseguire la migrazione dei dati.
  2. Puntare l'applicazione a Spanner.
  3. Verifica la correttezza controllando i flussi di base.
  4. Verifica che il rendimento soddisfi le tue aspettative eseguendo test di carico sulla tua applicazione. Per aiutarti a identificare e ottimizzare per le query più costose, Rileva i problemi di prestazioni delle query con Query Insights. In particolare, i seguenti fattori possono contribuire a una query non ottimale rendimento:
    1. Query inefficienti: per informazioni su come scrivere query efficienti, consulta le best practice per SQL.
    2. Utilizzo elevato della CPU: per ulteriori informazioni, consulta Esamina l'utilizzo elevato della CPU.
    3. Blocco: per ridurre i colli di bottiglia causati dal blocco delle transazioni, vedi Identifica le transazioni che potrebbero causare elevate latenze.
    4. Progettazione dello schema inefficiente: se lo schema non è progettato in modo adeguato, esegui una query l'ottimizzazione non è molto utile.
    5. Hotspotting: gli hotspot in Spanner limitano la velocità effettiva di scrittura, soprattutto per le applicazioni con un valore QPS elevato. Per identificare gli hotspot anti-pattern, controlla 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.
  5. 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 del database con tempi di inattività minimi o potresti aver bisogno di 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à
Fonti supportate MySQL e PostgreSQL Qualsiasi database che possa essere esportato in formato CSV 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 migrazioni con tempi di inattività minimi da MySQL, PostgreSQL e Oracle Database. 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 questo snapshot, noto come Change Data Capture (CDC, Change Data Capture).

Sebbene le migrazioni con tempi di inattività minimi aiutino 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 i seguenti elementi processi per te:

  1. Configura un bucket Cloud Storage per archiviare gli eventi CDC sul database di origine durante l'avanzamento della migrazione dello snapshot.
  2. 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.
  3. Configura il job Dataflow per eseguire la migrazione del 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. 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:

Il diagramma mostra il processo di una migrazione con tempi di inattività minimi.

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 tempo di inattività sono consigliate solo per gli ambienti di test in grado di gestire anche 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:

  1. Generare un file di dump dei dati dal database di origine.
  2. Carica il file di dump in Cloud Storage in un database MySQL, PostgreSQL, Avro o Formato di dump del file CSV.
  3. 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 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.

Avro è il formato preferito per una migrazione collettiva a Spanner. Se utilizzi Avro, considera quanto segue:

Se utilizzi un file CSV, considera 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 dati CSV, utilizza un job di importazione di Dataflow. Puoi creare il tuo modello di importazione Dataflow o utilizzare una sessione di Google Cloud importa il modello. 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 dati in Spanner, consulta Linee guida sul rendimento per il caricamento collettivo.

Convalidare la migrazione dei dati

La convalida dei dati è il processo di confronto dei dati sia dall'origine che tabelle di destinazione per assicurarne la corrispondenza.

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 usarlo per convalide di base durante la migrazione, ad esempio:

  • Verifica 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 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 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 suggerimento 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.

Il diagramma mostra il processo di cutover.

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.