Questo documento introduce concetti, principi, terminologia e architettura della migrazione dei database con tempi di inattività prossimi allo zero per i Cloud Architect che stanno eseguendo la migrazione di database a Google Cloud da ambienti on-premise o da altri ambienti cloud.
Il presente documento è la parte 1 di due parti. La parte 2 riguarda la configurazione e l'esecuzione del processo di migrazione, inclusi gli scenari di errori.
La migrazione dei database è il processo di migrazione dei dati da uno o più database di origine a uno o più database di destinazione utilizzando un servizio di migrazione dei database. Al termine di una migrazione, il set di dati nei database di origine risiede completamente, anche se ristrutturato, nei database di destinazione. I client che hanno eseguito l'accesso ai database di origine vengono quindi trasferiti ai database di destinazione e i database di origine vengono disattivati.
Il seguente diagramma illustra questo processo di migrazione del database.
Questo documento descrive la migrazione dei database dal punto di vista dell'architettura:
- I servizi e le tecnologie coinvolti nella migrazione dei database.
- Le differenze tra una migrazione di database omogenea ed eterogenea.
- I compromessi e la selezione di una tolleranza per il tempo di inattività della migrazione.
- Un'architettura di configurazione che supporta un fallback se si verificano errori imprevisti durante una migrazione.
Questo documento non descrive come impostare una determinata tecnologia di migrazione dei database. Piuttosto, introduce la migrazione dei database in termini fondamentali, concettuali e di principio.
Architettura
Il seguente diagramma mostra un'architettura generica di migrazione dei database.
Un servizio di migrazione dei database viene eseguito all'interno di Google Cloud e accede ai database di origine e di destinazione. Sono rappresentate due varianti: (a) mostra la migrazione da un database di origine in un data center on-premise o da un cloud remoto a un database gestito come Spanner; (b) mostra una migrazione a un database su Compute Engine.
Anche se i database di destinazione sono diversi per tipo (gestito e non gestito) e configurazione, l'architettura e la configurazione della migrazione dei database sono le stesse per entrambi i casi.
Terminologia
I termini più importanti per la migrazione dei dati per questi documenti sono definiti come segue:
database di origine: un database contenente i dati di cui eseguire la migrazione in uno o più database di destinazione.
database di destinazione: un database che riceve dati di cui è stata eseguita la migrazione da uno o più database di origine.
migrazione dei database: una migrazione dei dati dai database di origine ai database di destinazione con l'obiettivo di disattivare i sistemi dei database di origine al termine della migrazione. Viene eseguita la migrazione dell'intero set di dati o di un sottoinsieme.
migrazione omogenea: una migrazione dai database di origine ai database di destinazione in cui i database di origine e di destinazione fanno parte dello stesso sistema di gestione dei database dello stesso provider.
migrazione eterogenea:una migrazione dai database di origine ai database di destinazione in cui i database di origine e di destinazione appartengono a sistemi di gestione dei database diversi di provider diversi.
sistema di migrazione dei database: un sistema software o un servizio che si connette ai database di origine e a quelli di destinazione ed esegue migrazioni di dati dai database di origine a quelli di destinazione.
Processo di migrazione dei dati:un processo configurato o implementato eseguito dal sistema di migrazione dei dati per trasferire i dati dai database di origine a quelli di destinazione, eventualmente trasformandoli durante il trasferimento.
replica dei database: un trasferimento continuo di dati dai database di origine ai database di destinazione senza l'obiettivo di disattivare i database di origine. La replica del database (a volte chiamata streaming del database) è un processo in corso.
Classificazione delle migrazioni dei database
Esistono diversi tipi di migrazioni dei database che appartengono a classi diverse. In questa sezione vengono descritti i criteri che definiscono tali classi.
Replica e migrazione
Con una migrazione dei database, i dati vengono spostati dai database di origine a quelli di destinazione. Al termine della migrazione dei dati, elimini i database di origine e reindirizzi l'accesso del client ai database di destinazione. A volte, mantieni i database di origine come misura di riserva in caso di problemi imprevisti con i database di destinazione. Tuttavia, una volta che i database di destinazione sono operativi in modo affidabile, dovrai eliminare i database di origine.
Con la replica dei database, al contrario, i dati vengono trasferiti in modo continuo dai database di origine a quelli di destinazione senza eliminare i database di origine. A volte la replica del database è definita flusso del database. Anche se esiste un'ora di inizio definita, in genere non è definita un'ora di completamento. La replica potrebbe essere stata arrestata o diventare una migrazione.
Questo documento illustra solo la migrazione dei database.
Migrazione parziale o completa
Per migrazione del database si intende un trasferimento completo e coerente di dati. Devi definire il set di dati iniziale da trasferire come database completo o parziale (un sottoinsieme di dati di un database) seguito da ogni modifica apportata al sistema di database di origine.
Migrazione eterogenea e migrazione omogenea
Una migrazione omogenea dei database è una migrazione tra i database di origine e di destinazione della stessa tecnologia di database, ad esempio la migrazione da un database MySQL a un database MySQL o da un database Oracle® a un database Oracle. Le migrazioni omogenee includono anche le migrazioni tra un sistema di database self-hosted, come PostgreSQL, a una versione gestita come Cloud SQL per PostgreSQL o AlloyDB per PostgreSQL.
In una migrazione omogenea dei database, gli schemi per i database di origine e di destinazione sono probabilmente identici. Se gli schemi sono diversi, i dati dei database di origine devono essere trasformati durante la migrazione.
La migrazione di database eterogenea è una migrazione tra database di origine e di destinazione di diverse tecnologie di database, ad esempio da un database Oracle a Spanner. La migrazione eterogenea di database può avvenire tra gli stessi modelli di dati (ad es. da relazionale a relazionale) o tra diversi modelli di dati (ad es. da relazionale a valore-chiave).
La migrazione tra diverse tecnologie di database non comporta necessariamente modelli di dati diversi. Ad esempio, Oracle, MySQL, PostgreSQL e Spanner supportano tutti il modello dei dati relazionali. Tuttavia, i database multi-modello come Oracle, MySQL o PostgreSQL supportano modelli di dati diversi. È possibile eseguire la migrazione a MongoDB dei dati archiviati come documenti JSON in un database multi-modello con una trasformazione minima o nulla necessaria, dal momento che il modello dei dati è lo stesso nel database di origine e in quello di destinazione.
Sebbene la distinzione tra migrazione omogenea ed eterogenea si basa sulle tecnologie di database, una categorizzazione alternativa si basa sui modelli di database coinvolti. Ad esempio, una migrazione da un database Oracle a Spanner è omogenea quando entrambi utilizzano il modello dei dati relazionali; una migrazione è eterogenea se, ad esempio, viene eseguita la migrazione dei dati archiviati come oggetti JSON in Oracle a un modello relazionale in Spanner.
La classificazione delle migrazioni in base al modello dei dati esprime in modo più accurato la complessità e l'impegno necessari per eseguire la migrazione dei dati piuttosto che basare la categorizzazione sul sistema di database coinvolto. Tuttavia, poiché la classificazione comunemente utilizzata nel settore si basa sui sistemi di database coinvolti, le sezioni rimanenti si basano su questa distinzione.
Tempo di inattività della migrazione: zero, minimo o significativo
Dopo aver eseguito correttamente la migrazione di un set di dati dall'origine al database di destinazione, puoi trasferire l'accesso del client al database di destinazione ed eliminare il database di origine.
Il passaggio dei client dai database di origine a quelli di destinazione prevede diversi processi:
- Per continuare l'elaborazione, i client devono chiudere le connessioni esistenti ai database di origine e creare nuove connessioni ai database di destinazione. Idealmente, la chiusura delle connessioni avviene senza problemi, il che significa che non esegui inutilmente il rollback delle transazioni in corso.
- Dopo aver chiuso le connessioni sui database di origine, devi eseguire la migrazione delle modifiche rimanenti dai database di origine ai database di destinazione (chiamati eliminazione) per assicurarti che tutte le modifiche vengano acquisite.
- Potresti dover testare i database di destinazione per assicurarti che siano funzionanti e che i client siano funzionali e operino all'interno degli obiettivi del livello di servizio (SLO) definiti.
In una migrazione, non è possibile ottenere tempi di inattività completamente pari a zero per i client, ma a volte i client non sono in grado di elaborare le richieste. Tuttavia, puoi ridurre al minimo il tempo in cui i client non sono in grado di elaborare le richieste in diversi modi (tempo di inattività vicino allo zero):
- Puoi avviare i client di test in modalità di sola lettura sui database di destinazione molto prima di eseguire il cambio dei client. Con questo approccio, i test vengono eseguiti in contemporanea con la migrazione.
- Puoi configurare la quantità di dati di cui viene eseguita la migrazione (ossia, in transito tra i database di origine e di destinazione) in modo che sia il più ridotta possibile all'avvicinarsi del passaggio nel periodo. Questo passaggio riduce il tempo per lo svuotamento perché esistono meno differenze tra i database di origine e i database di destinazione.
- Se i nuovi client che operano sui database di destinazione possono essere avviati in contemporanea con quelli esistenti che operano sui database di origine, puoi ridurre il passaggio nel tempo poiché i nuovi client sono pronti per essere eseguiti non appena tutti i dati vengono svuotati.
Sebbene non sia realistico raggiungere tempi di inattività durante il passaggio, puoi ridurre al minimo il tempo di inattività avviando attività in contemporanea alla migrazione dei dati in corso, se possibile.
In alcuni scenari di migrazione del database, sono accettabili tempi di inattività significativi. In genere, questo importo è il risultato dei requisiti aziendali. In questi casi, puoi semplificare l'approccio. Ad esempio, con una migrazione omogenea del database, potresti non richiedere la modifica dei dati; l'esportazione e l'importazione o il backup e il ripristino sono approcci perfetti. Nel caso delle migrazioni eterogenee, il sistema di migrazione dei database non deve gestire aggiornamenti dei sistemi di database di origine durante la migrazione.
Tuttavia, devi stabilire che il tempo di inattività accettabile sia sufficiente per eseguire la migrazione del database e i test di follow-up. Se questo tempo di inattività non può essere stabilito chiaramente o è inaccettabilmente lungo, devi pianificare una migrazione che preveda tempi di inattività minimi.
Cardinalità di migrazione del database
In molte situazioni la migrazione del database avviene tra un singolo database di origine e un singolo database di destinazione. In queste situazioni, la cardinalità è 1:1 (mappatura diretta). Ciò significa che viene eseguita la migrazione di un database di origine senza modifiche a un database di destinazione.
Tuttavia, una mappatura diretta non è l'unica possibilità. Altre cardinalità includono quanto segue:
- Consolidamento (n:1). In un consolidamento, eseguirai la migrazione dei dati da diversi database di origine a un numero inferiore di database di destinazione (o anche a una sola destinazione). Potresti usare questo approccio per semplificare la gestione del database o utilizzare un database di destinazione in grado di scalare.
- Distribuzione (1:n). In una distribuzione, esegui la migrazione dei dati da un database di origine a più database di destinazione. Ad esempio, puoi utilizzare questo approccio quando devi eseguire la migrazione di un grande database centralizzato contenente dati regionali in diversi database di destinazione a livello di regione.
- Ridistribuzione (n:m). In una ridistribuzione, esegui la migrazione dei dati da diversi database di origine a più database di destinazione. Potresti utilizzare questo approccio quando disponi di database di origine con sharding con shard di dimensioni molto diverse. La ridistribuzione distribuisce uniformemente i dati con sharding su diversi database di destinazione che rappresentano gli shard.
La migrazione dei database offre l'opportunità di riprogettare e implementare l'architettura dei database oltre alla semplice migrazione dei dati.
Coerenza della migrazione
L'aspettativa è che una migrazione del database sia coerente. Nel contesto della migrazione, per coerente si intende quanto segue:
- Completo. Tutti i dati specificati per essere migrati vengono effettivamente migrati. I dati specificati potrebbero essere tutti i dati di un database di origine o un sottoinsieme di dati.
- Duplica gratuitamente. Ogni dato viene migrato una volta sola e solo una volta. Non vengono inseriti dati duplicati nel database di destinazione.
- Ordinato. Le modifiche ai dati nel database di origine vengono applicate al database di destinazione nello stesso ordine in cui si sono verificate nel database di origine. Questo aspetto è essenziale per garantire la coerenza dei dati.
Un modo alternativo per descrivere la coerenza della migrazione è che, al termine della migrazione, lo stato dei dati tra i database di origine e di destinazione è equivalente. Ad esempio, in una migrazione omogenea che comporta la mappatura diretta di un database relazionale, le stesse tabelle e righe devono esistere nei database di origine e di destinazione.
Questo modo alternativo per descrivere la coerenza della migrazione è importante perché non tutte le migrazioni dei dati si basano sull'applicazione sequenziale delle transazioni nel database di origine al database di destinazione. Ad esempio, puoi eseguire il backup del database di origine e utilizzare il backup per ripristinare il contenuto del database di origine nel database di destinazione (quando è possibile un tempo di inattività significativo).
Migrazione attiva-passiva e attiva-attiva
Una distinzione importante è se il database di origine e quello di destinazione sono entrambi aperti a modificare l'elaborazione delle query. In una migrazione dei database attivi-passivi, i database di origine possono essere modificati durante la migrazione, mentre i database di destinazione consentono l'accesso in sola lettura.
Una migrazione attiva-attiva supporta i client che scrivono sia nei database di origine sia nei database di destinazione durante la migrazione. In questo tipo di migrazione, possono verificarsi conflitti. Ad esempio, se lo stesso elemento di dati nel database di origine e di destinazione viene modificato in modo da entrare in conflitto tra loro semanticamente, potrebbe essere necessario eseguire regole di risoluzione dei conflitti per risolverlo.
In una migrazione attiva-attiva, devi essere in grado di risolvere tutti i conflitti di dati utilizzando le regole di risoluzione dei conflitti. Se non è possibile, potresti notare un'incoerenza tra i dati.
Architettura di migrazione dei database
Un'architettura di migrazione del database descrive i vari componenti necessari per eseguire una migrazione del database. Questa sezione introduce un'architettura di deployment generica e tratta il sistema di migrazione del database come un componente separato. Descrive inoltre le funzionalità di un sistema di gestione dei database che supporta la migrazione dei dati, nonché le proprietà non funzionali importanti per molti casi d'uso.
Architettura di deployment
Una migrazione di database può avvenire tra database di origine e di destinazione situati in qualsiasi ambiente, come on-premise o cloud diversi. Ogni database di origine e di destinazione può trovarsi in un ambiente diverso; non è necessario che tutti siano colorati nello stesso ambiente.
Il seguente diagramma mostra un esempio di architettura di deployment che coinvolge diversi ambienti.
DB1 e DB2 sono due database di origine, mentre DB3 e Spanner sono i database di destinazione. La migrazione del database prevede due cloud e due data center on-premise. Le frecce rappresentano le relazioni di chiamata: il servizio di migrazione del database richiama le interfacce di tutti i database di origine e di destinazione.
Un caso speciale non discusso qui è la migrazione dei dati da un database nello stesso database. Questo caso speciale utilizza il sistema di migrazione dei database solo per la trasformazione dei dati, non per la migrazione dei dati tra sistemi diversi in ambienti diversi.
Fondamentalmente, sono tre gli approcci alla migrazione dei database, che vengono trattati in questa sezione:
- Utilizzando un sistema di migrazione del database
- Utilizzo della funzionalità di replica del sistema di gestione dei database
- Utilizzo della funzionalità di migrazione dei database personalizzata
Sistema di migrazione dei database
Il sistema di migrazione dei database è al centro della migrazione dei database. Il sistema esegue l'effettiva estrazione dei dati dai database di origine, trasporta i dati ai database di destinazione e, facoltativamente, modifica i dati durante il transito. Questa sezione illustra in generale le funzionalità di base del sistema di migrazione dei database. Esempi di sistemi di migrazione dei database includono Database Migration Service, Striim, Debezium, tcVision e Cloud Data Fusion.
Processo di migrazione dei dati
L'elemento tecnico fondamentale di un sistema di migrazione dei database è il processo di migrazione dei dati. Il processo di migrazione dei dati è specificato da uno sviluppatore e definisce i database di origine da cui vengono estratti i dati, i database di destinazione in cui viene eseguita la migrazione e qualsiasi logica di modifica dei dati applicata ai dati durante la migrazione.
Puoi specificare uno o più processi di migrazione dei dati ed eseguirli in sequenza o contemporaneamente, a seconda delle esigenze della migrazione. Ad esempio, se esegui la migrazione di database indipendenti, i corrispondenti processi di migrazione dei dati possono essere eseguiti in parallelo.
Estrazione e inserimento dati
Puoi rilevare modifiche (inserzioni, aggiornamenti, eliminazioni) in un sistema di database in due modi: Change Data Capture (CDC) supportato dal database in base a un log delle transazioni ed esecuzione di query differenziali sui dati stessi utilizzando l'interfaccia di query di un sistema di gestione del database.
CDC basata su un log delle transazioni
La CDC supportata da database si basa su funzionalità di gestione dei database che sono separate dall'interfaccia di query. Un approccio è basato sui log delle transazioni (ad esempio il log binario in MySQL). Un log delle transazioni contiene le modifiche apportate ai dati nell'ordine corretto. Il log delle transazioni viene letto continuamente, quindi è possibile osservare ogni modifica. Per la migrazione del database, questo logging è estremamente utile, poiché CDC garantisce che ogni modifica sia visibile e venga successivamente migrata nel database di destinazione senza perdite e nell'ordine corretto.
CDC è l'approccio preferito per acquisire le modifiche in un sistema di gestione dei database. La tecnologia CDC è integrata nel database e ha il minimo impatto sul carico sul sistema.
Query differenziale
Se non esiste alcuna funzionalità del sistema di gestione dei database che supporti l'osservazione di tutte le modifiche nell'ordine corretto, puoi utilizzare le query differenziali come alternativa. In questo approccio, a ogni elemento di dati di un database viene assegnato un attributo aggiuntivo contenente un timestamp o un numero di sequenza. Ogni volta che l'elemento di dati viene modificato, viene aggiunto il timestamp della modifica o il numero di sequenza aumenta. Un algoritmo di polling legge tutti gli elementi di dati dall'ultima volta che è stato eseguito o dall'ultimo numero di sequenza utilizzato. Una volta che l'algoritmo di polling ha determinato le modifiche, registra l'ora corrente o il numero di sequenza nel suo stato interno e poi trasmette le modifiche al database di destinazione.
Anche se questo approccio funziona senza problemi per inserti e aggiornamenti, devi progettare con attenzione le eliminazioni perché un'eliminazione rimuove un elemento di dati dal database. Dopo che i dati sono stati eliminati, il poller non può rilevare che si è verificata un'eliminazione. Per implementare un'eliminazione, utilizza un campo di stato aggiuntivo (un flag di eliminazione logico) che indichi che i dati sono stati eliminati. In alternativa, gli elementi di dati eliminati possono essere raccolti in una o più tabelle e il poller accede a queste tabelle per determinare se si è verificata l'eliminazione.
Per le varianti delle query differenziali, consulta Change Data Capture.
Le query differenziali sono l'approccio meno preferito perché comporta modifiche di schema e funzionalità. Eseguire query sul database aggiunge anche un carico di query non correlato all'esecuzione della logica del client.
Adattatore e agente
Il sistema di migrazione dei database richiede l'accesso all'origine e ai sistemi di database. Gli adattatori sono l'astrazione che incapsula la funzionalità di accesso. Nel formato più semplice, un adattatore può essere un driver JDBC per l'inserimento di dati in un database di destinazione che supporta JDBC. In un caso più complesso, viene eseguito un adattatore nell'ambiente di destinazione (a volte chiamato agente), accedendo a un'interfaccia di database integrata come i file di log. In un caso ancora più complesso, un adattatore o un agente si interfaccia con un altro sistema software, che a sua volta accede al database. Ad esempio, un agente accede a Oracle GoldenGate e questo a sua volta accede a un database Oracle.
L'adattatore o l'agente che accede a un database di origine implementa l'interfaccia CDC o l'interfaccia di query differenziale, a seconda della progettazione del sistema del database. In entrambi i casi, l'adattatore o l'agente fornisce modifiche al sistema di migrazione del database e il sistema di migrazione del database non sa se le modifiche sono state acquisite tramite CDC o query differenziali.
Modifica dei dati
In alcuni casi d'uso, i dati vengono migrati dai database di origine ai database di destinazione non modificati. Queste migrazioni dirette sono in genere omogene.
Molti casi d'uso, tuttavia, richiedono la modifica dei dati durante il processo di migrazione. In genere, è necessaria la modifica quando ci sono differenze nello schema, differenze nei valori dei dati o opportunità di pulizia dei dati durante la transizione.
Le seguenti sezioni discutono dei diversi tipi di modifiche che possono essere necessarie in una migrazione dei dati: trasformazione, arricchimento o correlazione dei dati e riduzione o filtraggio dei dati.
Trasformazione dei dati
La trasformazione dei dati trasforma alcuni o tutti i valori dei dati del database di origine. Tra gli esempi di tali prodotti o servizi figurano:
- Trasformazione del tipo di dati. A volte i tipi di dati tra i database di origine e di destinazione non sono equivalenti. In questi casi, la trasformazione del tipo di dati trasmette il valore di origine al valore target in base alle regole di trasformazione del tipo. Ad esempio, un tipo di timestamp dell'origine potrebbe essere trasformato in una stringa nella destinazione.
- Trasformazione della struttura dei dati. La trasformazione della struttura dei dati modifica la struttura nello stesso modello di database o tra diversi modelli di database. Ad esempio, in un sistema relazionale, una tabella di origine potrebbe essere suddivisa in due tabelle di destinazione oppure diverse tabelle di origine potrebbero essere denormalizzate in un'unica tabella di destinazione utilizzando un join. Una relazione 1:n nel database di origine potrebbe essere trasformata in una relazione padre e figlio in Spanner. I documenti di un sistema di database di documenti di origine potrebbero essere scomposti in un insieme di righe relazionali in un sistema di destinazione.
- Trasformazione del valore dei dati. La trasformazione dei valori dei dati è separata dalla trasformazione del tipo di dati. La trasformazione dei valori dei dati modifica il valore senza modificare il tipo di dati. Ad esempio, il fuso orario locale viene convertito nel fuso orario UTC (Coordinated Universal Time). Oppure, un codice postale breve (cinque cifre) rappresentato da una stringa viene convertito in un codice postale lungo (cinque cifre seguite da un trattino seguito da quattro cifre, noto anche come ZIP+4).
Arricchimento e correlazione dei dati
La trasformazione dei dati viene applicata ai dati esistenti senza riferimento a dati di riferimento aggiuntivi correlati. Con l'arricchimento dei dati, vengono eseguite query sui dati aggiuntivi per arricchire i dati di origine prima che vengano archiviati nel database di destinazione.
- Correlazione dei dati. È possibile correlare i dati di origine. Ad esempio, puoi combinare i dati di due tabelle in due database di origine. In un database di destinazione, ad esempio, potresti collegare un cliente a tutti gli ordini aperti, evasi e annullati, in cui i dati del cliente e quelli degli ordini provengono da due diversi database di origine.
- Arricchimento dei dati. L'arricchimento dei dati aggiunge dati di riferimento. Ad esempio, potresti arricchire i record che contengono solo un codice postale aggiungendo il nome della città corrispondente al codice postale. Una tabella di riferimento contenente i codici postali e i nomi delle città corrispondenti è un set di dati statico a cui si accede per questo caso d'uso. Anche i dati di riferimento possono essere dinamici. Ad esempio, potresti usare un elenco di tutti i clienti noti come dati di riferimento.
Riduzione e filtro dei dati
Un altro tipo di trasformazione dei dati sta riducendo o filtrando i dati di origine prima di eseguirne la migrazione in un database di destinazione.
- Riduzione dei dati. Riduzione dei dati rimuove gli attributi da un elemento di dati. Ad esempio, se un codice postale è presente in un elemento di dati, il nome della città corrispondente potrebbe non essere obbligatorio ed è stato eliminato, perché può essere ricalcolato o perché non è più necessario. A volte queste informazioni vengono conservate per motivi storici al fine di registrare il nome della città inserito dall'utente, anche se il nome cambia nel tempo.
- Filtro dei dati. Il filtro dei dati rimuove completamente un elemento di dati. Ad esempio, tutti gli ordini annullati potrebbero essere rimossi e non trasferiti nel database di destinazione.
Combinazione o ricombinazione di dati
Se i dati vengono migrati da database di origine diversi a database di destinazione diversi, può essere necessario combinare i dati in modo diverso tra i database di origine e quelli di destinazione.
Supponiamo che clienti e ordini siano archiviati in due diversi database di origine. Un database di origine contiene tutti gli ordini, mentre un secondo database di origine contiene tutti i clienti. Dopo la migrazione, i clienti e i loro ordini vengono archiviati in una relazione 1:n all'interno di un singolo schema di database di destinazione, non in un singolo database di destinazione, ma in diversi database di destinazione in cui ciascuno contiene una partizione dei dati. Ogni database di destinazione rappresenta una regione e contiene tutti i clienti e i relativi ordini situati in quella regione.
Indirizzamento database di destinazione
A meno che non sia presente un solo database di destinazione, ogni elemento di dati di cui viene eseguita la migrazione deve essere inviato al database di destinazione corretto. Un paio di approcci per affrontare il database di destinazione includono quanto segue:
- Indirizzamento basato su schema. L'indirizzamento basato su schema determina il database di destinazione in base allo schema. Ad esempio, viene eseguita la migrazione di tutti gli elementi di dati di una raccolta di clienti o di tutte le righe di una tabella clienti nello stesso database di destinazione in cui sono archiviate le informazioni sui clienti, anche se queste informazioni sono state distribuite in diversi database di origine.
- Routing basato sui contenuti. Il routing basato sui contenuti (ad esempio mediante un router basato sui contenuti) determina il database di destinazione in base ai valori dei dati. Ad esempio, tutti i clienti che si trovano nella regione dell'America Latina vengono migrati a un database di destinazione specifico che rappresenta quella regione.
Puoi utilizzare entrambi i tipi di indirizzi contemporaneamente in una migrazione del database. Indipendentemente dal tipo di indirizzo utilizzato, il database di destinazione deve avere lo schema corretto in modo che gli elementi di dati vengano archiviati.
Persistenza dei dati in transito
I sistemi di migrazione dei database, o gli ambienti in cui vengono eseguiti, possono presentare errori durante una migrazione e i dati in transito possono andare persi. In caso di errori, devi riavviare il sistema di migrazione del database e assicurarti che i dati archiviati nel database di origine vengano migrati in modo coerente e completo nei database di destinazione.
Nell'ambito del ripristino, il sistema di migrazione dei database deve identificare l'ultimo elemento di dati di cui è stata eseguita la migrazione per determinare da dove iniziare l'estrazione dai database di origine. Per riprendere nel punto di errore, il sistema deve mantenere uno stato interno durante l'avanzamento della migrazione.
Puoi mantenere lo stato in diversi modi:
- Puoi archiviare tutti gli elementi di dati estratti all'interno del sistema di migrazione del database prima di qualsiasi modifica e quindi rimuovere l'elemento di dati dopo che la relativa versione modificata è stata archiviata correttamente nel database di destinazione. Questo approccio garantisce che il sistema di migrazione dei database possa determinare esattamente ciò che viene estratto e archiviato.
- Puoi gestire un elenco di riferimenti agli elementi di dati in transito. Una possibilità è archiviare le chiavi primarie o altri identificatori univoci di ogni elemento di dati insieme a un attributo di stato. Dopo un errore, questo stato è la base per ripristinare il sistema in modo coerente.
- Puoi eseguire query sui database di origine e di destinazione dopo un errore nel determinare la differenza tra i sistemi di database di origine e di destinazione. L'elemento di dati successivo da estrarre viene determinato in base alla differenza.
Altri approcci per mantenere lo stato possono dipendere da database di origine specifici. Ad esempio, un sistema di migrazione del database può tenere traccia delle voci di log delle transazioni recuperate dal database di origine e di quelle inserite nel database di destinazione. Se si verifica un errore, la migrazione può essere riavviata dall'ultima voce inserita correttamente.
La persistenza dei dati in transito è importante anche per altri motivi oltre a errori o errori. Ad esempio, potrebbe non essere possibile eseguire query sui dati del database di origine per stabilirne lo stato. Ad esempio, se il database di origine conteneva una coda, i messaggi al suo interno potrebbero essere stati rimossi a un certo punto.
Un altro caso d'uso per la persistenza dei dati in transito è l'elaborazione di grandi finestre di dati. Durante la modifica dei dati, gli elementi di dati possono essere trasformati in modo indipendente l'uno dall'altro. Tuttavia, a volte la modifica dei dati dipende da diversi elementi di dati (ad esempio, la numerazione degli elementi di dati elaborati al giorno, a partire da zero ogni giorno).
Un caso d'uso finale per la persistenza dei dati in transito è quello di garantire la ripetibilità dei dati durante la modifica dei dati, quando il sistema di database non riesce ad accedere nuovamente ai database di origine. Ad esempio, potresti dover eseguire nuovamente le modifiche ai dati con regole di modifica diverse e poi verificare e confrontare i risultati con le modifiche iniziali ai dati. Questo approccio potrebbe essere necessario se devi monitorare eventuali incoerenze nel database di destinazione a causa di una modifica non corretta dei dati.
Verifica di completezza e coerenza
Devi verificare che la migrazione del database sia completa e coerente. Questo controllo garantisce che ogni elemento di dati venga migrato una sola volta, che i set di dati nei database di origine e di destinazione siano identici e che la migrazione sia completa.
A seconda delle regole di modifica dei dati, è possibile che un elemento di dati sia stato estratto, ma non inserito in un database di destinazione. Per questo motivo, il confronto diretto dei database di origine e di destinazione non è un approccio solido per verificare la completezza e la coerenza. Tuttavia, se il sistema di migrazione dei database monitora gli elementi filtrati, puoi confrontare i database di origine e di destinazione insieme agli elementi filtrati.
Funzionalità di replica del sistema di gestione dei database
Un caso d'uso speciale in una migrazione omogenea è in cui il database di destinazione è una copia del database di origine. In particolare, gli schemi nei database di origine e di destinazione sono gli stessi, i valori dei dati sono gli stessi e ogni database di origine è una mappatura diretta (1:1) a un database di destinazione.
In questo caso, puoi utilizzare la funzionalità di replica integrata fornita con la maggior parte dei sistemi di gestione dei database per replicare un database in un altro.
Esistono due tipi di replica dei dati: logica e fisica.
Replica logica: in caso di replica logica, le modifiche agli oggetti di database vengono trasferite in base ai relativi identificatori di replica (di solito chiavi primarie). Il vantaggio della replica logica è che è flessibile, granulare e puoi personalizzarla. In alcuni casi, la replica logica consente di replicare le modifiche tra diverse versioni motore del database. Molti motori di database supportano filtri di replica logica, in cui puoi definire il set di dati da replicare. Gli svantaggi principali sono che la replica logica potrebbe introdurre un overhead delle prestazioni e la latenza di questo metodo di replica è solitamente superiore a quella della replica fisica.
Replica fisica: al contrario, la replica fisica funziona a livello di blocco del disco e offre prestazioni migliori con una latenza di replica inferiore. Per set di dati di grandi dimensioni, la replica fisica può essere più semplice ed efficiente, soprattutto nel caso di strutture di dati non relazionali. Tuttavia, non è personalizzabile e dipende fortemente dalla versione del motore del database.
Alcuni esempi sono la replica MySQL, la replica PostgreSQL (vedi anche pglogical o replica Microsoft SQL Server.
Tuttavia, se è necessaria la modifica dei dati o se hai una cardinalità diversa da una mappatura diretta, sono necessarie le funzionalità di un sistema di migrazione del database per risolvere questo caso d'uso.
Funzionalità personalizzata di migrazione del database
Ecco alcuni motivi per creare una funzionalità di migrazione dei database anziché utilizzare un sistema di migrazione o di gestione dei database:
- Hai bisogno del controllo completo su ogni dettaglio.
- Vuoi riutilizzare le funzionalità di migrazione dei database.
- Vuoi ridurre i costi o semplificare l'impronta tecnologica.
I componenti di base per la creazione della funzionalità di migrazione includono quanto segue:
- Esportazione e importazione: se il tempo di inattività non è un fattore determinante, puoi utilizzare l'esportazione e l'importazione dei database per eseguire la migrazione dei dati in migrazioni di database omogenee. Tuttavia, l'esportazione e l'importazione richiedono la chiusura del database di origine per impedire gli aggiornamenti prima di esportare i dati. In caso contrario, le modifiche potrebbero non essere acquisite nell'esportazione e il database di destinazione non sarà una copia esatta del database di origine.
- Backup e ripristino: come nel caso di esportazione e importazione, il backup e il ripristino comportano tempi di inattività perché devi uscire dal database di origine in modo che il backup contenga tutti i dati e le ultime modifiche. Il tempo di inattività continua fino al completamento del ripristino nel database di destinazione.
- Query differenziale: se è possibile modificare lo schema del database, puoi estenderlo in modo che sia possibile eseguire query sulle modifiche del database nell'interfaccia della query. Viene aggiunto un altro attributo timestamp, che indica l'ora dell'ultima modifica. È possibile aggiungere un ulteriore flag di eliminazione che indica se l'elemento di dati è stato eliminato o meno (eliminazione logica). Con queste due modifiche, un poller eseguito in intervalli regolari può eseguire query su tutte le modifiche dall'ultima esecuzione. Le modifiche vengono applicate al database di destinazione. Altri approcci sono descritti in Change Data Capture.
Queste sono solo alcune delle opzioni possibili per creare una migrazione personalizzata del database. Sebbene una soluzione personalizzata offra la massima flessibilità e il massimo controllo sull'implementazione, richiede anche una manutenzione costante per correggere bug, limitazioni della scalabilità e altri problemi che potrebbero verificarsi durante una migrazione del database.
Considerazioni aggiuntive sulla migrazione dei database
Le seguenti sezioni parlano brevemente degli aspetti non funzionali che sono importanti nel contesto della migrazione dei database. Questi aspetti includono gestione degli errori, scalabilità, alta disponibilità e ripristino di emergenza.
Gestione degli errori
Gli errori durante la migrazione del database non devono causare la perdita di dati o l'elaborazione di modifiche al database non corrette. L'integrità dei dati deve essere preservata indipendentemente da ciò che ha causato l'errore (ad esempio un bug nel sistema, un'interruzione di rete, un arresto anomalo della VM o un errore di zona).
Si verifica una perdita di dati quando un sistema di migrazione recupera i dati dai database di origine e non li archivia nei database di destinazione a causa di alcuni errori. Quando i dati vengono persi, i database di destinazione non corrispondono ai database di origine e sono quindi incoerenti e incompleti. La funzionalità di verifica di completezza e coerenza contrassegna questo stato (Verifica di completezza e coerenza).
Scalabilità
In una migrazione di database, il tempo di migrazione è una metrica importante. In una migrazione senza tempi di inattività (nel senso di tempi di inattività minimi), la migrazione dei dati avviene mentre i database di origine continuano a cambiare. Per eseguire la migrazione in un periodo di tempo ragionevole, la velocità di trasferimento dei dati deve essere significativamente più veloce rispetto a quella degli aggiornamenti dei sistemi di database di origine, soprattutto quando il sistema di database di origine è di grandi dimensioni. Maggiore è la velocità di trasferimento, più rapido sarà il completamento della migrazione del database.
Quando i sistemi di database di origine sono in stato di inattività e non vengono modificati, la migrazione potrebbe essere più rapida perché non ci sono modifiche da incorporare. In un database omogeneo, i tempi di migrazione potrebbero essere piuttosto rapidi, perché puoi utilizzare funzionalità di backup e ripristino o di esportazione e importazione e il trasferimento dei file ha una scalabilità.
Alta disponibilità e ripristino di emergenza
In generale, i database di origine e di destinazione sono configurati per l'alta disponibilità. Un database principale ha una replica di lettura corrispondente che viene promossa a database principale quando si verifica un errore.
In caso di errore di una zona, i database di origine o di destinazione eseguono il failover in una zona diversa per essere costantemente disponibili. Se si verifica un errore di zona durante una migrazione del database, il sistema di migrazione stesso ne risentirà perché diversi database di origine o di destinazione a cui accede diventano inaccessibili. Il sistema di migrazione deve riconnettersi ai database primari appena promossi in esecuzione dopo un errore. Una volta riconnesso il sistema di migrazione dei database, deve recuperare la migrazione stessa per garantire la completezza e la coerenza dei dati nei database di destinazione. Il sistema di migrazione deve determinare l'ultimo trasferimento coerente per stabilire dove riprendere.
Se il sistema di migrazione del database stesso non funziona (ad esempio, la zona in cui viene eseguito diventa inaccessibile), è necessario recuperarlo. Un approccio di ripristino è il riavvio a freddo. Con questo approccio, il sistema di migrazione dei database viene installato in una zona operativa e riavviato. Il problema principale da risolvere è che il sistema di migrazione deve essere in grado di determinare l'ultimo trasferimento di dati coerente prima dell'errore e continuare da quel momento per garantire la completezza e la coerenza dei dati nei database di destinazione.
Se il sistema di migrazione dei database è abilitato per l'alta disponibilità, può eseguire il failover e continuare l'elaborazione in seguito. Se è importante un tempo di inattività limitato del sistema di migrazione del database, devi selezionare un database e implementare l'alta disponibilità.
In termini di recupero della migrazione del database, il ripristino di emergenza è molto simile all'alta disponibilità. Anziché riconnettersi ai database primari appena promossi in una zona diversa, il sistema di migrazione dei database deve riconnettersi ai database in un'altra regione (una regione di failover). Lo stesso vale per il sistema di migrazione del database. Se la regione in cui viene eseguito il sistema di migrazione dei database diventa inaccessibile, il sistema di migrazione dei database deve eseguire il failover in un'altra regione e continuare dall'ultimo trasferimento di dati coerente.
Insidie
Diverse insidie possono causare incoerenza dei dati nei database di destinazione. Ecco alcune opzioni comuni da evitare:
- Violazione dell'ordine. Se la scalabilità del sistema di migrazione viene raggiunta attraverso lo scale out, diversi processi di trasferimento di dati vengono eseguiti contemporaneamente (in parallelo). Le modifiche in un sistema di database di origine vengono ordinate in base alle transazioni impegnate. Se le modifiche vengono prelevate dal log delle transazioni, l'ordine deve essere mantenuto durante l'intera migrazione. Il trasferimento di dati in parallelo può cambiare l'ordine a causa della diversa velocità tra i processi sottostanti. È necessario assicurarsi che i dati vengano inseriti nei database di destinazione nello stesso ordine in cui vengono ricevuti dai database di origine.
- Violazione della coerenza. Con le query differenziali, i database di origine hanno attributi di dati aggiuntivi che contengono, ad esempio, timestamp del commit. I database di destinazione non avranno timestamp di commit perché i timestamp di commit vengono utilizzati solo per stabilire la gestione dei cambiamenti nei database di origine. È importante garantire che gli inserti nei database di destinazione devono essere coerenti con timestamp, il che significa che tutte le modifiche con lo stesso timestamp devono essere nello stesso inserimento, aggiornamento o transazione upert. In caso contrario, il database di destinazione potrebbe avere uno stato incoerente (temporaneamente) se alcune modifiche vengono inserite e altre con lo stesso timestamp. Questo stato di incoerenza temporaneo non è importante se non si accede ai database di destinazione per l'elaborazione. Tuttavia, se vengono utilizzati per i test, la coerenza è fondamentale. Un altro aspetto è la creazione dei valori dei timestamp nel database di origine e il loro rapporto con l'ora di commit della transazione in cui sono impostati. A causa delle dipendenze del commit delle transazioni, una transazione con un timestamp precedente potrebbe diventare visibile dopo una transazione con un timestamp successivo. Se la query differenziale viene eseguita tra le due transazioni, non vedrà la transazione con il timestamp precedente, causando un'incoerenza sul database di destinazione.
- Dati mancanti o duplicati. Quando si verifica un failover, è necessario un recupero attento se alcuni dati non vengono replicati tra l'unità principale e la replica di failover. Ad esempio, un database di origine esegue il failover e non tutti i dati vengono replicati nella replica di failover. Allo stesso tempo, viene già eseguita la migrazione dei dati nel database di destinazione prima dell'errore. Dopo il failover, il database primario appena promosso è in ritardo per quanto riguarda le modifiche dei dati al database di destinazione (chiamato Flashback). Un sistema di migrazione deve riconoscere questa situazione ed eseguire il ripristino in modo che il database di destinazione e il database di origine tornino a essere uno stato coerente.
- Transazioni locali. Affinché il database di origine e di destinazione ricevano le stesse modifiche, un approccio comune consiste nel far scrivere ai client sia nel database di origine che in quello di destinazione anziché utilizzare un sistema di migrazione dei dati. Questo approccio presenta diversi inconvenienti. Un'insidia è che due scritture di database sono due transazioni separate; potresti riscontrare un errore dopo la prima e prima della seconda. Questo scenario causa dati incoerenti da cui devi recuperare. Inoltre, ci sono diversi client in generale e non sono coordinati. I client non conoscono l'ordine di commit della transazione del database di origine e pertanto non possono scrivere nei database di destinazione che implementano quell'ordine di transazione. I clienti potrebbero modificare l'ordine, causando un'incoerenza dei dati. A meno che tutti gli accessi non passino attraverso client coordinati e tutti i client non si assicurano che l'ordine della transazione di destinazione avvenga, questo approccio può portare a uno stato incoerente con il database di destinazione.
In generale, ci sono altre insidie a cui fare attenzione. Il modo migliore per individuare i problemi che potrebbero causare incoerenze nei dati è eseguire un'analisi completa degli errori che esegua l'iterazione di tutti i possibili scenari di errore. Se nel sistema di migrazione dei database viene implementata la contemporaneità, è necessario esaminare tutti i possibili ordini di esecuzione del processo di migrazione dei dati per garantire che la coerenza dei dati venga preservata. Se viene implementata l'alta disponibilità e il ripristino di emergenza (o entrambi), è necessario esaminare tutte le possibili combinazioni di errori.
Passaggi successivi
- Leggi Migrazioni dei database: Concetti e principi (Parte 2).
- Scopri di più sulla migrazione dei database nei seguenti documenti:
- Consulta Migrazione dei database per altre guide alla migrazione dei database.
- Esplora le architetture di riferimento, i diagrammi e le best practice su Google Cloud. Visita il nostro Cloud Architecture Center.