Il presente documento introduce concetti, principi, terminologia e architettura Migrazione dei database con tempi di inattività quasi azzerati per i cloud architect che stanno eseguendo la migrazione a Google Cloud da ambienti on-premise o da altri ambienti cloud.
Questo documento è la prima parte di due. Parte 2 illustra la configurazione e l'esecuzione del processo di migrazione, inclusi gli errori diversi scenari.
La migrazione del database è il processo di migrazione dei dati da una o più origini i database su 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 eventualmente riorganizzato, nei database di destinazione. I client che hanno eseguito l'accesso ai database di origine vengono poi trasferiti ai database di destinazione e i database di origine vengono disattivati.
Il seguente diagramma illustra questa procedura di migrazione del database.
Questo documento descrive la migrazione del database dal punto di vista dell'architettura:
- I servizi e le tecnologie coinvolti nella migrazione dei database.
- Le differenze tra migrazione omogenea ed eterogenea dei database.
- I compromessi e la selezione di una tolleranza al tempo di riposo della migrazione.
- Un'architettura di configurazione che supporta un piano di riserva se si verificano errori imprevisti durante una migrazione.
Questo documento non descrive la modalità di configurazione di una particolare migrazione del database tecnologia. ma introduce la migrazione del database in termini fondamentali, concettuali e di principio.
Architettura
Il seguente diagramma mostra un'architettura generica per la migrazione dei database.
Un servizio di migrazione del database viene eseguito in 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 in un cloud remoto in un database gestito come Spanner; (b) mostra una migrazione a un su Compute Engine.
Anche se i database di destinazione sono di tipo diverso (gestito e non gestito) e configurazione, l'architettura e la configurazione della migrazione del database sono le stesse in entrambi i casi.
Terminologia
I termini più importanti per la migrazione dei dati di questi documenti sono definiti come segue:
database di origine:un database contenente 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ù i database di origine.
Migrazione del database: una migrazione dei dati dai database di origine ai database di destinazione con l'obiettivo di disattivare i sistemi di 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 appartengono allo stesso sistema di gestione del 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 fornitori diversi.
Sistema di migrazione del database: un sistema o un servizio software che si connette ai database di origine e di destinazione ed esegue la migrazione dei dati dai database di origine ai database di destinazione.
Procedura di migrazione dei dati: una procedura configurata o implementata eseguita dal sistema di migrazione dei dati per trasferire i dati dai database di origine a quelli di destinazione, eventualmente trasformandoli durante il trasferimento.
Replica del database: un trasferimento continuo di dati dai database di origine ai database di destinazione senza lo scopo di disattivare i database di origine. La replica del database (a volte chiamata streaming del database) è un processo continuo.
Classificazione delle migrazioni dei database
Esistono diversi tipi di migrazioni di database che appartengono a classi diverse. Questa sezione descrive i criteri che definiscono queste classi.
Differenza tra replica e migrazione
In una migrazione di database, sposti i dati dai database di origine ai database di destinazione. Una volta completata la migrazione dei dati, elimina i database di origine e reindirizza l'accesso dei client ai database di destinazione. A volte è consigliabile conservare i database di origine come misura di riserva se si verificano problemi imprevisti con i database di destinazione. Tuttavia, una volta che i database di destinazione funzionano in modo affidabile, puoi eliminare i database di origine.
Con la replica del database, invece, trasferisci continuamente i dati dai database di origine ai database di destinazione senza eliminarli. A volte la replica del database è indicata come streaming del database. Sebbene sia stata definita un'ora di inizio, in genere non è stata 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 e completa
Per migrazione del database si intende un trasferimento completo e coerente dei dati. Il set di dati iniziale da trasferire viene definito come un database completo o parziale (un sottoinsieme di dati in un database) più ogni modifica committata successivamente nel sistema di database di origine.
Migrazione eterogenea e migrazione omogenea
Una migrazione di database omogenea è 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 quelle tra un ambiente PostgreSQL come PostgreSQL a una versione gestita come PostgreSQL, Cloud SQL per PostgreSQL o AlloyDB per PostgreSQL.
In una migrazione di database omogenea, gli schemi dei database di origine e di destinazione sono probabilmente identici. Se gli schemi sono diversi, i dati devono essere trasformati durante la migrazione.
La migrazione dei database eterogenei è una migrazione tra origine e destinazione di database di diverse tecnologie di database, ad esempio da un database a Spanner. La migrazione di database eterogenea può avvenire tra gli stessi modelli di dati (ad esempio da relazionale a relazionale) o tra modelli di dati diversi (ad esempio da relazionale a chiave-valore).
La migrazione tra diverse tecnologie di database non comporta necessariamente modelli di dati diversi. Ad esempio, Oracle, MySQL, PostgreSQL e Tutti gli Spanner supportano il modello dei dati relazionali. Tuttavia, i database multimodello come Oracle, MySQL o PostgreSQL supportano diversi modelli di dati. I dati archiviati come documenti JSON in un database multimodello possono essere migrati in MongoDB con poca o nessuna trasformazione necessaria, poiché il modello di dati è lo stesso nel database di origine e di destinazione.
Sebbene la distinzione tra migrazione omogenea ed eterogenea sia basata sulle tecnologie di database, una classificazione alternativa si basa sui modelli di database coinvolti. Ad esempio, una migrazione da un database Oracle Spanner è omogeneo quando entrambi utilizzano il modello dei dati relazionali; a migrazione è eterogenea, ad esempio, se i dati archiviati come oggetti JSON Viene eseguita la migrazione di Oracle a un modello relazionale in Spanner.
La categorizzazione delle migrazioni per modello dei dati esprime in modo più accurato la complessità e l'impegno richiesto per migrare i dati piuttosto che basare la categorizzazione sul coinvolto in un sistema di database. 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 alla destinazione il database, quindi trasferisci l'accesso client al database di destinazione ed elimini il database di origine.
Il trasferimento dei clienti dai database di origine ai database di destinazione comporta diverse procedure:
- Per continuare l'elaborazione, i client devono chiudere le connessioni esistenti al i database di origine e creare nuove connessioni ai database di destinazione. Idealmente, la chiusura delle connessioni avviene in modo corretto, il che significa che non è necessario eseguire il rollback delle transazioni in corso.
- Dopo aver chiuso le connessioni sui database di origine, devi eseguire la migrazione le modifiche rimanenti dai database di origine ai database di destinazione (chiamati draining) per garantire che tutte le modifiche vengano acquisite.
- Potresti dover testare i database di destinazione per assicurarti che siano funzionali e che i clienti siano funzionali e operino all'interno del proprio di obiettivi del livello di servizio (SLO) definiti.
In una migrazione, non è possibile ottenere tempi di inattività completamente azzerati per i clienti; a volte i client non riescono a elaborare le richieste. Tuttavia, puoi ridurre al minimo il periodo di 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 per i database di destinazione molto prima di eseguire il passaggio dei client. Con questo approccio, i test vengono eseguiti in concomitanza con la migrazione.
- Puoi configurare la quantità di dati di cui eseguire la migrazione, ovvero tra i database di origine e di destinazione) di essere il più ridotto possibile quando il cambio nel periodo si avvicina. Questo passaggio riduce il tempo di svuotamento perché le differenze tra i database di origine e quelli di destinazione sono minori.
- Se i nuovi client che operano sui database di destinazione possono essere avviati contemporaneamente ai client esistenti che operano sui database di origine, puoi ridurre il tempo di transizione nel tempo perché i nuovi client sono pronti per essere eseguiti non appena tutti i dati sono stati trasferiti.
Sebbene non sia realistico azzerare il tempo di inattività durante il cambio, è possibile ridurre al minimo il tempo di inattività avviando attività in contemporanea con i dati in corso quando possibile.
In alcuni scenari di migrazione dei database, è accettabile un tempo di inattività significativo. In genere, questo margine è il risultato di requisiti aziendali. In questi casi, puoi semplificare il tuo approccio. Ad esempio, con un database omogeneo migrazione, potresti non richiedere la modifica dei dati; esportare e importare il backup e il ripristino sono gli approcci ideali. A causa delle migrazioni eterogenee, il sistema di migrazione dei database non deve gestire gli aggiornamenti durante la migrazione.
Tuttavia, devi stabilire che il tempo di inattività accettabile sia sufficiente per la migrazione del database e per i test di follow-up. Se questo tempo di riposo non può siano definiti chiaramente o siano inaccettabilmente lunghi, è necessario pianificare una migrazione con tempi di inattività minimi.
Cardinalità della migrazione del database
In molte situazioni la migrazione del database avviene tra un'unica 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 in un database di destinazione.
Tuttavia, una mappatura diretta non è l'unica possibilità. Altre cardinalità include:
- Raggruppamento (n:1). In un consolidamento, esegui la migrazione dei dati da diversi database di origine a un numero inferiore di database di destinazione (o anche un target). Potresti utilizzare questo approccio per semplificare la gestione del database o impiegare un database di destinazione scalabile.
- Distribuzione (1:n). In una distribuzione, esegui la migrazione dei dati da un database di origine a più database di destinazione. Ad esempio, potresti utilizzare questo quando devi eseguire la migrazione di un grande database centralizzato a diversi database di destinazione a livello di regione.
- Ridistribuzione (n:m). In una ridistribuzione, esegui la migrazione dei dati da da diversi database di origine a diversi database di destinazione. Potresti usare questo quando si hanno database di origine con sharding dimensioni diverse. La ridistribuzione distribuisce uniformemente i dati suddivisi in più database di destinazione che rappresentano gli shard.
La migrazione del database offre l'opportunità di riprogettare e implementare l'architettura del database, oltre a eseguire la semplice migrazione dei dati.
Coerenza della migrazione
Si presume che una migrazione del database sia coerente. Nel contesto migrazione, per coerenza si intende quanto segue:
- Completato. Tutti i dati per i quali è specificata la migrazione vengono effettivamente sottoposti a migrazione. I dati specificati possono essere tutti i dati di un database di origine o un sottoinsieme di dati.
- Senza costi aggiuntivi. La migrazione di ogni dato viene eseguita una sola volta. Nel database di destinazione non vengono introdotti dati duplicati.
- Ordine effettuato. Le modifiche ai dati nel database di origine vengono applicate al database di destinazione nello stesso ordine in cui sono state apportate nel database di origine. Questo aspetto è essenziale per garantire la coerenza dei dati.
Un modo alternativo per descrivere la coerenza della migrazione è che, dopo una migrazione, viene completato, lo stato dei dati tra il database di origine e quello di destinazione equivalenti. Ad esempio, in una migrazione omogenea che coinvolge mappatura di un database relazionale, devono esistere le stesse tabelle e righe di origine e di destinazione.
Questo modo alternativo di 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 i contenuti del database di origine nel database di destinazione (quando è possibile un tempo di riposo significativo).
Migrazione attiva/passiva e migrazione attiva/attiva
Una distinzione importante è se i database di origine e di destinazione sono entrambi disponibili per la modifica dell'elaborazione delle query. In una migrazione di database attivo-passivo, i database di origine possono essere modificati durante la migrazione, mentre i database di destinazione consentono solo l'accesso di sola lettura.
Una migrazione attiva-attiva supporta i client che scrivono sia nell'origine che e i database di destinazione durante la migrazione. In questo tipo di migrazione possono verificarsi conflitti. Ad esempio, se lo stesso elemento dati nel database di origine e di destinazione viene modificato in modo da essere in conflitto semanticamente, potrebbe essere necessario eseguire regole di risoluzione dei conflitti per risolvere il problema.
In una migrazione attiva-attiva, devi essere in grado di risolvere tutti i conflitti di dati mediante regole di risoluzione dei conflitti. Se non riesci, potresti riscontrare dati incoerenza.
Architettura di migrazione del database
Un'architettura di migrazione del database descrive i vari componenti necessari per eseguire una migrazione del database. Questa sezione introduce un deployment generico e considera il sistema di migrazione del database come un componente separato. Vengono inoltre descritte le funzionalità di un sistema di gestione del database che supportano la migrazione dei dati, nonché le proprietà non funzionali importanti per molti casi d'uso.
Architettura di deployment
Una migrazione del database può avvenire tra database di origine e di destinazione situati in qualsiasi ambiente, ad esempio on-premise o in cloud diversi. Ogni database di origine e di destinazione può trovarsi in un ambiente diverso; non è necessario che tutti siano collocati 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 con i database di destinazione. Sono coinvolti due cloud e due data center on-premise in questa migrazione del database. Le frecce rappresentano le relazioni di chiamata: il servizio di migrazione del database richiama le interfacce di tutte le origini e tutte le destinazioni o Microsoft SQL Server.
Un caso speciale non trattato qui è la migrazione dei dati da un database allo stesso database. Questo caso speciale utilizza il sistema di migrazione del database solo per la trasformazione dei dati, non per la migrazione dei dati tra sistemi diversi in ambienti diversi.
Fondamentalmente, ci sono tre approcci alla migrazione dei database, che tratta di:
- L'utilizzo di un sistema di migrazione del database
- Utilizzo della funzionalità di replica del sistema di gestione del database
- Utilizzo della funzionalità di migrazione del database personalizzata
Sistema di migrazione dei database
Il sistema di migrazione del database è al centro della migrazione del database. Il sistema esegue l'estrazione effettiva dei dati dai database di origine, trasporta ai database di destinazione e, facoltativamente, li modifica durante il transito. Questa sezione illustra le funzionalità di base del sistema di migrazione del database in generale. Alcuni esempi di sistemi di migrazione del database sono Database Migration Service, Striim, Debezium, tcVision e Cloud Data Fusion.
Processo di migrazione dei dati
L'elemento di base tecnico fondamentale di un sistema di migrazione dei database sono i dati di migrazione. Il processo di migrazione dei dati viene specificato da uno sviluppatore e definisce i database di origine da cui vengono estratti i dati, i database di destinazione in cui vengono migrati i dati e qualsiasi logica di modifica dei dati applicata ai dati durante la migrazione.
Puoi specificare una o più procedure di migrazione dei dati ed eseguirle in sequenza o in contemporanea, a seconda delle esigenze della migrazione. Per Ad esempio, se esegui la migrazione di database indipendenti, la migrazione dei dati processi possono essere eseguiti in parallelo.
Estrazione e inserimento dei dati
Puoi rilevare le modifiche (inserimenti, aggiornamenti ed eliminazioni) in un sistema di database in due modi: tramite il CDC (Change Data Capture) supportato dal database in base a un log delle transazioni e tramite query differenziali dei dati stessi utilizzando l'interfaccia di query di un sistema di gestione del database.
CDC basata su un log delle transazioni
La copia dei dati dal canale supportata dal database si basa su funzionalità di gestione del database separate dall'interfaccia di query. Un approccio si basa 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, pertanto è possibile osservare ogni modifica. Per migrazione di database, questo logging è estremamente utile, poiché il CDC garantisce che ogni la modifica è visibile e viene successivamente migrata nel database di destinazione senza perdita di dati e nell'ordine corretto.
La CDC è l'approccio preferito per acquisire le modifiche nella gestione di un database di un sistema operativo completo. La tecnologia CDC è integrata nel database stesso e ha l'impatto sul carico minimo sul sistema.
Query differenziali
Se non esiste una funzionalità del sistema di gestione del database che supporti l'osservazione di tutte le modifiche nell'ordine corretto, puoi utilizzare le query differenziali come alternativa. In questo approccio, ogni elemento di dati in un database riceve un attributo aggiuntivo contenente un timestamp o un numero di sequenza. Ogni volta che i dati viene modificato, viene aggiunto il timestamp della modifica o il numero di sequenza aumentati. Un algoritmo di polling legge tutti gli elementi di dati dall'ultima volta che eseguito o dall'ultimo numero di sequenza utilizzato. Una volta che l'algoritmo di polling ha determinato le modifiche, registra l'ora o il numero di sequenza corrente nel suo stato interno e poi le trasmette al database di destinazione.
Sebbene questo approccio funzioni senza problemi per inserimenti e aggiornamenti, è necessario progettare con attenzione le eliminazioni perché un'eliminazione rimuove un elemento di dati dal database. Dopo aver eliminato i dati, è impossibile per l'inquilino rilevare che . Puoi implementare un'eliminazione utilizzando un campo di stato aggiuntivo (un flag di eliminazione logico) che indica 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 è avvenuta l'eliminazione.
Per le varianti sulle query differenziali, consulta Change Data Capture (CDC).
Le query differenziali sono l'approccio meno preferito perché implica lo schema e le funzionalità. L'esecuzione di query sul database aggiunge anche un carico di query che non riguarda l'esecuzione della logica del client.
Adattatore e agente
Il sistema di migrazione dei database richiede l'accesso all'origine e al database sistemi operativi. Gli adattatori sono l'astrazione che incapsula la funzionalità di accesso. Nella forma più semplice, un adattatore può essere un driver JDBC inserendo dati in un database di destinazione che supporta JDBC. In un contesto più complesso, caso, un adattatore è in esecuzione nell'ambiente del target (a volte chiamato agent), 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, che 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 del design del sistema di database. In entrambi i casi, l'adattatore o l'agente apporta modifiche di migrazione dei 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, viene eseguita la migrazione dei dati dai database di origine ai database di destinazione senza modifiche. Queste migrazioni dirette sono in genere omogenee.
Molti casi d'uso, tuttavia, richiedono la modifica dei dati durante la migrazione e il processo di sviluppo. In genere, la modifica è necessaria quando esistono differenze nello schema, nei valori dei dati o opportunità di ripulire i dati durante la transizione.
Le sezioni seguenti descrivono diversi tipi di modifiche che possono essere richieste in una migrazione dei dati: trasformazione dei dati, 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 dall'origine per configurare un database. Ecco alcuni esempi:
- Trasformazione del tipo di dati. A volte i tipi di dati tra l'origine e i database di destinazione non sono equivalenti. In questi casi, il tipo di dati trasformazione trasmette il valore di origine al valore target in base al tipo e regole di trasformazione. Ad esempio, un tipo di timestamp dell'origine potrebbe trasformare in una stringa nella destinazione.
- Trasformazione della struttura dei dati. 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 più 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-figlio in Spanner. I documenti di un sistema di database di documenti di origine potrebbero essere decomposti 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 dei tipi di dati. La trasformazione del valore dei dati cambia senza modificare il tipo di dati. Ad esempio, un fuso orario locale viene convertito in Tempo Universale Coordinato (UTC). In alternativa, un codice postale breve (cinque cifre) rappresentato come stringa viene convertito in un codice postale lungo (cinque cifre seguite da un trattino seguite da 4 cifre, noto anche come codice postale +4).
Arricchimento e correlazione dei dati
La trasformazione dei dati viene applicata ai dati esistenti senza fare riferimento a dati di riferimento aggiuntivi correlati. Con l'arricchimento dei dati, i dati aggiuntivi vengono per l'arricchimento dei 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. Nella un database di destinazione, ad esempio, potresti collegare un cliente a tutti ordini evasi e annullati in cui i dati del cliente e l'ordine 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 la città nome 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 utilizzare un elenco di tutti i clienti noti come dati di riferimento.
Riduzione e filtro dei dati
Un altro tipo di trasformazione dei dati è la riduzione o il filtro dei dati di origine prima di eseguirne la migrazione a un database di destinazione.
- Riduzione dei dati. La riduzione dei dati rimuove gli attributi da un elemento di dato. Ad esempio, se in un elemento dati è presente un codice postale, il nome della città corrispondente potrebbe non essere obbligatorio e viene eliminato perché può essere ricalcolato o perché non è più necessario. A volte queste informazioni vengono conservate per motivi storici per registrare il nome della città inserito dall'utente, anche se il nome della città cambia nel tempo.
- Filtro dei dati. Il filtro dei dati rimuove completamente un elemento di dati. Per Ad esempio, tutti gli ordini annullati potrebbero essere rimossi e non trasferiti database di destinazione.
Combinazione o ricombinazione di dati
Se i dati vengono migrati da diversi database di origine a diversi database di destinazione, può essere necessario combinarli in modo diverso tra i database di origine e di destinazione.
Supponiamo che i clienti e gli ordini siano archiviati in due diversi database di origine. Un database di origine contiene tutti gli ordini e un secondo database di origine per tutti i clienti. Dopo la migrazione, i clienti e i loro ordini vengono archiviati in un file 1:n relazione all'interno di un singolo schema di database di destinazione, non in una singola destinazione ma diversi database di destinazione dove 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 del 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. Ecco alcuni approcci per indirizzare il database di destinazione:
- Indirizzamento basato su schema. L'indirizzamento basato sullo schema determina il database di destinazione in base allo schema. Ad esempio, tutti gli elementi dati di una raccolta di clienti o tutte le righe di una tabella dei clienti vengono migrati nello stesso database di destinazione che memorizza le informazioni sui clienti, anche se queste informazioni sono state distribuite in più database di origine.
- Routing basato sui contenuti. Il routing basato sui contenuti (ad esempio, utilizzando un router basato sui contenuti) determina il database di destinazione in base ai valori dei dati. Per Ad esempio, tutti i clienti che si trovano nella regione dell'America Latina vengono migrati di un database di destinazione specifico che rappresenta quella regione.
Puoi utilizzare entrambi i tipi di indirizzi contemporaneamente in una migrazione di database. Indipendentemente dal tipo di indirizzamento utilizzato, il database di destinazione deve avere lo schema corretto in modo che gli elementi di dati siano archiviati.
Persistenza dei dati in transito
I sistemi di migrazione dei database, o gli ambienti su cui vengono eseguiti, possono non riuscire durante una migrazione e i dati in transito potrebbero andare persi. In caso di errori, devi riavviare il sistema di migrazione del database e assicurarti che i dati memorizzati nel database di origine vengano migrati in modo coerente e completo ai database di destinazione.
Nell'ambito della procedura di ripristino, il sistema di migrazione del database deve identificare dell'ultimo elemento di dati migrato per determinare da dove iniziare l'estrazione i database di origine. Per riprendere in corrispondenza di un errore, il sistema deve mantenere uno stato interno sull'avanzamento della migrazione.
Puoi mantenere lo stato in diversi modi:
- Puoi archiviare tutti gli elementi di dati estratti all'interno della migrazione del database prima di qualsiasi modifica del database e poi rimuovi l'elemento dati una volta la versione modificata è stata archiviata nel database di destinazione. Questo assicura che il sistema di migrazione dei database possa determinare esattamente ovvero i dati estratti e archiviati.
- Puoi mantenere un elenco di riferimenti agli elementi di dati in transito. Una possibile soluzione è archiviare le chiavi principali o altri identificatori univoci di ogni elemento di dati insieme a un attributo di stato. In seguito a un errore, è la base per un ripristino coerente del sistema.
- Puoi eseguire query sui database di origine e di destinazione dopo un errore per determinare la differenza tra i sistemi di database di origine e di destinazione. Il successivo dato da estrarre viene determinato in base alla differenza.
Altri approcci per mantenere lo stato possono dipendere dall'origine specifica o Microsoft SQL Server. Ad esempio, un sistema di migrazione del database può tenere traccia di quali voci del log delle transazioni vengono recuperate dal database di origine e quali vengono inserite nel database di destinazione. In caso di errore, la migrazione può è riavviato dall'ultima voce inserita correttamente.
La persistenza dei dati in transito è importante anche per altri motivi oltre a errori o guasti. Ad esempio, potrebbe non essere possibile eseguire query sui dati dall'origine per determinarne lo stato. Se, ad esempio, il database di origine conteneva una coda, i messaggi in quella coda potrebbero essere stati rimossi punto di accesso.
Un altro caso d'uso per la persistenza dei dati in transito è una finestra di grandi dimensioni l'elaborazione dei dati. Durante la modifica dei dati, gli elementi di dati possono essere trasformati indipendentemente l'uno dall'altro. Tuttavia, a volte la modifica dei dati dipende diversi elementi di dati (ad esempio, numerare gli elementi di dati elaborati giornalmente, a partire da zero ogni giorno).
Un ultimo caso d'uso per la persistenza dei dati in transito è fornire la ripetibilità degli stessi durante la modifica quando il sistema di database non può accedere nuovamente ai database di origine. Ad esempio, potrebbe essere necessario eseguire nuovamente le modifiche ai dati con regole di modifica diverse, quindi verificare e confrontare i risultati con le modifiche iniziali dei dati. Questo approccio potrebbe essere necessario se devi monitorare eventuali incoerenze nel database di destinazione a causa di una modifica errata dei dati.
Verifica della completezza e della coerenza
Devi verificare che la migrazione del database sia completa e coerente. Questo controllo garantisce che ogni elemento dati venga sottoposto a migrazione una sola volta, che i set di dati nei database di origine e di destinazione siano identici e che la migrazione sia completata.
A seconda delle regole di modifica dei dati, è possibile che un elemento di dati venga 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 del database monitora gli elementi filtrati, puoi confrontare i dati 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 è quando il database di destinazione del database di origine. Nello specifico, gli schemi nei file di origine e di destinazione sono uguali, 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 offerta con la maggior parte dei sistemi di gestione di database per replicare un database in un altro.
Esistono due tipi di replica dei dati: logica e fisica.
Replica logica: nel caso della replica logica, le modifiche agli oggetti del database vengono trasferite in base ai relativi identificatori di replica (di solito chiavi principali). Il vantaggio della replica logica è che si flessibile, granulare e personalizzabile. In alcuni casi, la replica logica consente di replicare le modifiche tra diverse versioni del motore del database. Molti database supportano filtri di replica logica, in cui è possibile definire l'insieme da replicare. I principali svantaggi sono che la replica logica potrebbe introdurvi un sovraccarico delle prestazioni e la latenza di questo metodo di replica è in genere superiore a quella della replica fisica.
Replicazione fisica: al contrario, la replicazione 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 efficienti, soprattutto nel caso di strutture di dati non relazionali. Tuttavia, non è personalizzabile e dipende molto dalla versione del motore del database.
Esempi: Replica MySQL, Replica PostgreSQL (vedi anche pglogical), o Replica di Microsoft SQL Server.
Tuttavia, se è necessaria la modifica dei dati o se la cardinalità è diversa rispetto a una mappatura diretta, sono necessarie le capacità di un sistema di migrazione dei database per affrontare questo caso d'uso.
Funzionalità di migrazione del database personalizzata
Alcuni motivi per creare una funzionalità di migrazione del database anziché utilizzare un di migrazione dei database o sistema di gestione dei database le seguenti:
- Ti serve il controllo completo su ogni dettaglio.
- Vuoi riutilizzare le funzionalità di migrazione del database.
- Vuoi ridurre i costi o semplificare la tua impronta tecnologica.
I componenti di base per la creazione di funzionalità di migrazione includono quanto segue:
- Esportazione e importazione: se il tempo di riposo non è un fattore determinante, puoi utilizzare l'esportazione e l'importazione del database per eseguire la migrazione dei dati in migrazioni di database omogenee. Tuttavia, per l'esportazione e l'importazione è necessario disattivare l'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, backup e il ripristino comporta tempi di inattività perché devi disattivare il database di origine che il backup contenga tutti i dati e le ultime modifiche. Il tempo di riposo prosegue fino al completamento del ripristino nel database di destinazione.
- Query differenziali: se è possibile modificare lo schema del database, puoi estenderlo in modo da poter eseguire query sulle modifiche del database nell'interfaccia di query. Viene aggiunto un attributo timestamp aggiuntivo che indica la data e l'ora dell'ultima modifica. È possibile aggiungere un ulteriore flag di eliminazione che indica se l'elemento dati è stato eliminato o meno (eliminazione logica). Con questi due modifiche, un poller eseguito a intervalli regolari può eseguire query su tutte le modifiche dall'ultima esecuzione. Le modifiche vengono applicate al database di destinazione. Altri approcci vengono discussi nei Change Data Capture (CDC).
Queste sono solo alcune delle possibili opzioni per creare un database personalizzato migrazione. Sebbene una soluzione personalizzata offra il massimo della flessibilità e del controllo rispetto all'implementazione, richiede inoltre una manutenzione costante per risolvere i bug, di scalabilità e altri problemi che potrebbero sorgere durante migrazione.
Considerazioni aggiuntive sulla migrazione dei database
Le sezioni seguenti illustrano brevemente gli aspetti non funzionali importanti nel contesto della migrazione del 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 delle modifiche al database fuori sequenza. L'integrità dei dati deve essere preservata indipendentemente la causa dell'errore (ad esempio un bug nel sistema, un'interruzione di rete, un arresto anomalo di una VM o un errore di una zona).
Si verifica una perdita di dati quando un sistema di migrazione recupera i dati dall'origine e non lo archivia nei database di destinazione a causa di alcuni errori. Quando i dati vengono persi, i database di destinazione non corrispondono a quelli di origine e quindi sono incoerenti e incompleti. Completezza e coerenza la funzionalità di verifica segnala questo stato Verifica della completezza e coerenza.
Scalabilità
In una migrazione di database, il tempo necessario per la migrazione è una metrica importante. In una migrazione con zero downtime (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 molto più rapida della frequenza di aggiornamento dei sistemi di database di origine, soprattutto se il sistema di database di origine è di grandi dimensioni. Più alta è la velocità di trasferimento, più veloce sarà la migrazione del database.
Quando i sistemi dei database di origine sono inattivi e non vengono modificati, la migrazione potrebbe essere più rapida perché non ci sono modifiche da incorporare. In un omogeneo, i tempi di migrazione potrebbero essere piuttosto rapidi perché utilizzare le funzionalità di backup e ripristino o di esportazione e importazione e il trasferimento di file delle scale.
Alta disponibilità e ripristino di emergenza
In genere, i database di origine e di destinazione sono configurati per l'alta disponibilità. Un database primario ha una replica di lettura corrispondente che viene promossa a database primario in caso di errore.
In caso di errore di una zona, il failover dei database di origine o di destinazione viene eseguito in un'altra zona che sia sempre disponibile. Se un errore di zona si verifica durante un database migrazione, il sistema di migrazione stesso ne risentirà perché diverse o i database di destinazione a cui accede diventano inaccessibili. Il sistema di migrazione deve ricollegarsi ai database principali appena promossi in esecuzione dopo un errore. Una volta riconnesso il sistema di migrazione del database, deve recuperare per garantire la completezza e la coerenza dei dati in di destinazione. Il sistema di migrazione deve determinare l'ultima per stabilire dove riprendere la configurazione.
Se il sistema di migrazione del database presenta errori (ad esempio, nella zona in cui viene eseguito diventa inaccessibile), deve essere recuperato. Un approccio di ripristino prevede riavvio a freddo. In questo approccio, il sistema di migrazione dei database è installato in operativa e riavviata. Il problema principale da risolvere è che 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 con coerenza nei database di destinazione.
Se il sistema di migrazione dei database è abilitato per l'alta disponibilità, può verificarsi un errore per poi proseguire con l'elaborazione. Se il tempo di inattività del database è limitato di migrazione è importante, devi selezionare un database e implementare la disponibilità del servizio.
In termini di recupero della migrazione del database, il ripristino di emergenza è molto simile all'alta disponibilità. Anziché effettuare nuovamente il collegamento all'account principale appena promosso in una zona diversa, il sistema di migrazione dei database deve riconnettersi in una regione diversa (regione di failover). Lo stesso vale per il sistema di migrazione del database stesso. Se la regione in cui viene eseguita la migrazione del database di sistema non è più accessibile, il sistema di migrazione del database deve eseguire il failover a un'altra regione e continuare dall'ultimo trasferimento di dati coerente.
Problemi
Diverse insidie possono causare dati incoerenti nei database di destinazione. Ecco alcuni esempi comuni da evitare:
- Violazione dell'ordine. Se la scalabilità del sistema di migrazione ottenuti con lo scale out, sono in esecuzione diversi processi di trasferimento di dati contemporaneamente (in parallelo). Le modifiche in un sistema di database di origine vengono ordinate in base alle transazioni impegnate. Se le modifiche vengono rilevate dal log delle transazioni, l'ordine deve essere mantenuto durante la migrazione. Il trasferimento parallelo dei dati può modificare l'ordine a causa della velocità variabile 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, i timestamp dei commit. I database di destinazione non avranno timestamp di commit perché i timestamp di commit vengono utilizzati solo per stabilire una modifica dei dati nei database di origine. È importante assicurarsi che gli inserimenti nei database di destinazione siano coerenti con il timestamp, il che significa che tutte le modifiche con lo stesso timestamp devono trovarsi nella stessa transazione di inserimento, aggiornamento o upsert. In caso contrario, il database di destinazione potrebbe avere stato incoerente (temporaneamente) se vengono inserite alcune modifiche e altre con lo stesso timestamp non lo sono. Questo stato temporaneo incoerente non è importante se non viene eseguito l'accesso ai database di destinazione per l'elaborazione. Tuttavia, se vengono utilizzati per i test, la coerenza è fondamentale. Un altro aspetto è la creazione dei valori timestamp nel database di origine e il loro rapporto con il momento del commit della transazione in cui sono impostati. A causa di dipendenze del commit delle transazioni, ovvero una transazione con un timestamp precedente potrebbero diventare visibili 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'incongruenza nel database di destinazione.
- Dati mancanti o duplicati. Quando si verifica un failover, è necessario un recupero attento se alcuni dati non vengono replicati tra la replica principale e quella di failover. Ad esempio, il failover di un database di origine e non tutti i dati vengono replicati nella replica di failover. Allo stesso tempo, la migrazione dei dati al database di destinazione è già stata eseguita prima dell'errore. Dopo il failover, il database principale appena promosso è in ritardo in termini di modifiche ai dati nel database di destinazione (chiamato flashback). Una migrazione sistema deve riconoscere la situazione e riprendersi in modo tale in modo che il database di destinazione e il database di origine tornino stato.
- Transazioni locali. Per fare in modo che i campi di origine e di destinazione ricevono le stesse modifiche, un approccio comune consiste nel far sì sia nel database di origine che in quello di destinazione, invece di utilizzare di migrazione. Questo approccio presenta diversi problemi. Un problema è che due scritture nel database sono due transazioni distinte; potresti riscontrare un errore dopo il completamento della prima e prima del completamento della seconda. Questo scenario causa dati incoerenti da cui devi recuperare. Inoltre, esistono vari clienti in generale e non sono coordinati. I client non conoscono l'ordine di commit delle transazioni del database di origine e quindi non possono scrivere nei database di destinazione che implementano quell'ordine di transazioni. I clienti potrebbero modificare l'ordine, il che può causare incoerenze nei dati. A meno che tutti gli accessi non passino attraverso client coordinati, e tutti i clienti assicurano l'ordine di transazione target, questo approccio può generare una con il database di destinazione.
In generale, ci sono altri pericoli da tenere presente. Il modo migliore per trovare i problemi che potrebbero portare a incoerenze nei dati è eseguire un'analisi completa degli errori che itera in tutti i possibili scenari di errore. Se la concorrenza è implementata nel sistema di migrazione del database, è necessario esaminare tutti i possibili ordini di esecuzione del processo di migrazione dei dati per garantire la coerenza dei dati. Se sono implementati l'alta disponibilità e il ripristino di emergenza (o entrambi), devono essere esaminate tutte le possibili combinazioni di errori.
Passaggi successivi
- Letto 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. Dai un'occhiata al nostro Centro architetture cloud.