Questo documento illustra la configurazione ed esecuzione del processo di migrazione del database, inclusi gli scenari di errore. Questo documento fa parte della seconda parte di due parti. Parte 1 introduce concetti, principi e terminologia del database con tempi di inattività quasi azzerati migrazione per cloud architect che devono eseguire la migrazione dei database in Google Cloud da ambienti on-premise o da altri ambienti cloud.
Configurazione della migrazione del database
Questa sezione descrive le varie fasi di una migrazione del database. Innanzitutto, configura la migrazione. Una volta completata la migrazione e effettuato il passaggio ai database di destinazione, rimuovi i database di origine o, implementare un piano di riserva a causa di problemi con la migrazione, dopo il cambio. Un piano di riserva contribuisce a garantire la continuità aziendale.
Durante la migrazione, devi prestare particolare attenzione a eventuali modifiche dello schema o dei dati che potrebbero essere introdotte. Per ulteriori informazioni sull'impatto di questi delle modifiche, vedi Modifiche dinamiche durante la migrazione più avanti in questo documento.
Specifica schema di destinazione
Per ogni sistema di database di destinazione, devi definire e creare lo schema. Per le migrazioni di database omogenee, puoi creare questa specifica più rapidamente esportando lo schema del database di origine nel database di destinazione, creando così lo schema del database di destinazione.
Il nome dello schema è importante. Un'opzione è associare i nomi degli schemi di origine e di destinazione. Tuttavia, sebbene questo semplifichi il passaggio ai client, questo approccio potrebbe confondere gli utenti se gli strumenti si connettono all'origine e alla destinazione schemi di database contemporaneamente, ad esempio per confrontare i dati. Se astrai il nome dello schema utilizzando un file di configurazione e assegnando al database di destinazione nomi diversi dall'origine, facilitano la distinzione e schemi di machine learning.
Con migrazioni di database eterogenee, è necessario creare ciascun database di destinazione . Questo processo di progettazione può richiedere diverse iterazioni. Prima di poter per implementare la migrazione, potrebbe essere necessario modificare ulteriormente gli schemi per per supportare il processo di migrazione e qualsiasi modifica ai dati.
Perché probabilmente creerai database di destinazione più volte quando eseguirai il test ed eseguire la migrazione, il processo di creazione dello schema deve essere ripetibili (idealmente eseguiti tramite script di installazione). Puoi usare un codice per controllare la versione degli script, garantire la coerenza e accedere alla cronologia delle modifiche degli script.
Semântica di migrazione ed esecuzione delle query
Alla fine, dovrai passare i client dall'accesso ai sistemi di database di origine all'accesso ai sistemi di database di destinazione. Nelle integrazioni di database omogenee, le query possono rimanere invariate se gli schemi non vengono modificati. Sebbene i client debbano essere testati sui sistemi di database di destinazione, non devono essere modificati a causa delle query.
Per le migrazioni di database eterogenee in generale, è necessario modificare le query perché gli schemi dei database di origine e di destinazione sono diversi. La potrebbe trattarsi di una mancata corrispondenza del tipo di dati tra i database di origine e quelli di destinazione. Nella Inoltre, non tutte le funzionalità del linguaggio di query disponibili nella sistemi di database disponibili nei sistemi di database di destinazione oppure conversa. In casi estremi, potrebbe essere necessario convertire una query da un'origine del sistema di database in varie query sul sistema di destinazione. In uno scenario opposto, in cui nel database di destinazione sono disponibili più funzionalità del linguaggio di query rispetto a quello di origine, potrebbe essere necessario combinare più query dal database di origine in un'unica query sul database di destinazione corrispondente.
Anche la semantica delle query può variare. Ad esempio, alcuni sistemi di database materializzare un aggiornamento all'interno di una transazione immediatamente all'interno di quella transazione in modo che, quando viene letto lo stesso elemento di dati, venga recuperato il valore aggiornato. Altri sistemi non materializzano immediatamente un aggiornamento e aspettano il commit della transazione. Se la logica del sistema del database di origine si basa sulla scrittura materializzata, la stessa logica sul database di destinazione può causare dati non corretti o persino errori.
Se devi eseguire la migrazione delle query, devi testare tutte le funzionalità per assicurarti il comportamento dei client è lo stesso prima e dopo la migrazione. Puoi anche i test a livello di dati, ma questi test non sostituiscono quelli sul client livello. I clienti eseguono query dal punto di vista della logica di business e possono testati solo a livello di logica di business.
Processi di migrazione
Per le migrazioni di database eterogenee, i processi di migrazione specificano estratti dai sistemi di database di origine vengono modificati e inseriti nei o Microsoft SQL Server. Le modifiche ai dati, come quelle descritte nella sezione Modifiche ai dati di questo documento, vengono definite ed eseguite mentre gli elementi di dati vengono estratti dai database di origine e trasferiti ai database di destinazione.
Con le migrazioni omogenee dei database, quando gli schemi dei database di origine e di destinazione sono equivalenti, la modifica dei dati non è richiesta. I dati vengono inseriti nei database di destinazione come sono stati estratti dai database di origine.
A seconda del sistema di migrazione del database, potrebbero essere necessarie diverse configurazioni. Ad esempio, devi specificare se i dati da modificare e trasferiti devono essere archiviati a intermittenza nel sistema di migrazione dei database. L'archiviazione dei dati può rallentare il processo di migrazione complessivo, ma velocizza il ripristino in caso di errore. Potrebbe essere necessario specificare il tipo di verifica. Ad esempio, alcuni sistemi di migrazione dei database eseguono query sull'origine e per stabilire l'equivalenza del set di dati migrato fino al punto della query. La gestione degli errori richiede di specificare il ripristino da errori comportamento degli utenti. Anche in questo caso, questo requisito dipende dal sistema di migrazione del database in uso.
È inutile dire che devi testare la migrazione dei dati in modo approfondito e ripetuto. Idealmente, la migrazione viene testata per garantire che tutti i dati noti dell'elemento sottoposto a migrazione, non si verificano errori di modifica dei dati, prestazioni e velocità effettiva sia sufficiente e il tempo necessario per la migrazione sarà completato.
Processi di riserva
Durante una migrazione dei database, i database di origine rimangono operativi (a meno che la migrazione comporta tempi di inattività pianificati). Se la migrazione del database non va a buon fine in qualsiasi momento, puoi (nello scenario peggiore) interrompere la migrazione e reimpostare il database di destinazione sullo stato iniziale. Una volta risolti gli errori, puoi riavvia la migrazione del database. L'errore e la risoluzione non influiscono sul sistemi di database di origini operative.
Se si verificano errori dopo il completamento della migrazione del database e i client vengono trasferiti ai database di destinazione, la procedura di errore e risoluzione potrebbe influire sui client impedendo loro di funzionare correttamente. Nella migliore delle ipotesi, l'errore viene risolto rapidamente e il tempo di inattività per i clienti è breve. Nel peggiore delle ipotesi, l'errore non viene risolto o la risoluzione richiede molto tempo e devi ripristinare i client nei database di origine.
Per ripristinare i client nei database di origine, devi eseguire la migrazione di tutte le modifiche ai dati nei database di destinazione ai database di origine. Puoi impostare ed eseguire questo processo come migrazione del database completa e separata. Tuttavia, poiché a questo punto i client non sono operativi nei database di destinazione, si verificheranno downtime significativi.
Per evitare tempi di inattività del client in questo scenario, devi avviare la migrazione vengono elaborati immediatamente dopo il completamento della migrazione originale del database. Ogni evento la modifica applicata ai sistemi di database di destinazione viene applicata immediatamente sistemi di database di origine. Seguendo questo approccio si garantisce che sia il target che che i sistemi di database di origine siano sempre sincronizzati.
La preparazione di un fallback dai database di destinazione ai database di origine richiede molto impegno. È fondamentale decidere se implementare e testare processi di fallback o comprendere le conseguenze di una mancata esecuzione, ovvero con tempi di inattività significativi.
Esecuzione della migrazione del database
L'esecuzione di una migrazione di database prevede cinque fasi distinte, che in questa sezione di cui parleremo. Una sesta fase è una fallback, mentre una fallback è un caso estremo considerata un'eccezione a una normale esecuzione di migrazione del database.
Il processo descritto in questa sezione è una migrazione di database eterogeneo con tempi di riposo quasi nulli. Se puoi permetterti un tempo di riposo significativo, puoi combinare le prime tre fasi (caricamento iniziale, migrazione continua e svuotamento) in un'unica fase utilizzando l'approccio di backup e ripristino o di esportazione e importazione.
Una migrazione di database omogenea rappresenta un caso speciale. Con questo tipo di migrazione, puoi utilizzare la funzionalità di replica del sistema di gestione dei database (ad i sistemi che la supportano) che esegue la migrazione dei dati mentre il database rimangono operativi.
Le fasi illustrate qui delineano un approccio che potrebbe essere necessario modificare in base ai requisiti del processo di migrazione del database.
Fase 1: caricamento iniziale
Il punto di partenza è eseguire la migrazione di tutti i dati specificati per la migrazione da tutti i database di origine. All'inizio della migrazione dei dati, i database di origine hanno un determinato stato, che cambia durante la migrazione.
Un suggerimento per avviare una migrazione mentre le modifiche vengono apportate contemporaneamente è tenere presente che l'ora del sistema di database immediatamente prima dell'estrazione del primo dato. Con questo timestamp, puoi ricavare tutte le modifiche al database dal log delle transazioni a partire da quel momento. Inoltre, il caricamento iniziale deve leggere lo stato del database su tutti i dati. Potrebbe essere necessario un blocco di breve durata per evitare di leggere un set di dati incoerente.
Questa fase prevede quanto segue:
- Prendi nota dell'ora di sistema del database subito prima dell'avvio della migrazione del database.
- Esecuzione di un processo di migrazione del caricamento iniziale che esegue una query sul set di dati
(complete o parziali) dai database di origine che devono essere
e la migrazione del set di dati. In un modello di database relazionale, le procedure di migrazione del caricamento iniziale eseguono query come
SELECT *o query con selezione o proiezione o entrambe. Il processo di migrazione modifica i dati come specificato durante il processo.
Durante l'esecuzione dei processi di migrazione del caricamento iniziale, i client in genere apportano modifiche ai database di origine. Poiché l'ora del sistema di database viene registrata puoi ricavare queste modifiche dal log delle transazioni in un secondo momento.
Il risultato della fase di caricamento iniziale è la migrazione completa del set di dati iniziale dai sistemi di database di origine ai sistemi di database di destinazione. Tuttavia, i database di origine e di destinazione non sono ancora sincronizzati perché probabilmente i client hanno modificato i database di origine durante la migrazione. La fase 2 prevede l'acquisizione e la migrazione di queste modifiche.
Fase 2: continua la migrazione
Continuare la migrazione ha due scopi. Innanzitutto, legge le modifiche che si sono verificate nei database di origine dopo l'avvio del caricamento iniziale. In secondo luogo, acquisisce e trasferisce queste modifiche ai database di destinazione.
Questa fase prevede quanto segue:
- Avvio dei processi di migrazione continua dal sistema di database tempo registrato nella Fase 1. La migrazione legge il log delle transazioni da quel momento e applica ogni modifica al sistema di database di destinazione.
- Eseguire qualsiasi modifica dei dati. Il processo di migrazione esegue questo passaggio come specificato.
A volte le modifiche registrate dopo l'ora del sistema del database vengono trasferite durante il caricamento iniziale. Pertanto, è possibile che queste modifiche possano essere applicate una seconda volta durante la migrazione. Devi definire le tue procedure di migrazione per assicurarti che le modifiche non vengano applicate due volte, ad esempio utilizzando gli identificatori. Supponiamo che un elemento di dati modificato venga trasferito durante il caricamento iniziale e che l'inserimento venga registrato nel log delle transazioni. Applicando un identificatore all'elemento dati, il sistema di migrazione può determinare log delle transazioni che non è necessario inserire un'altra volta perché l'elemento dati esiste già.
Il risultato della fase di migrazione continua è che i database di destinazione sono completamente sincronizzati o quasi completamente sincronizzati con i database di origine. Quando una modifica in un sistema di database di origine non viene migrata, devi un database quasi sincronizzato.
A seconda di come configuri il sistema di migrazione del database, le discrepanze possono essere piccole o grandi. Ad esempio, per aumentare l'efficienza, non tutte le modifiche la migrazione deve essere eseguita immediatamente, altrimenti puoi creare un carico alla sorgente in caso di modifiche al picco dell'origine. In generale, le modifiche vengono raccolte di cui viene eseguita la migrazione in batch come operazioni collettive. Con batch più piccoli, si verificano meno discrepanze tra la sorgente e la destinazione, ma la sorgente può comportare un carico maggiore se le modifiche vengono apportate di frequente.
Se la dimensione del batch è configurata in modo dinamico, è meglio sincronizzare inizialmente batch più grandi nella fase di migrazione continua e poi sincronizzare batch di dimensioni gradualmente ridotte quando i database sono quasi aggiornati. Questo approccio rende più efficiente il processo di aggiornamento e riduce la discrepanza tra i database di origine e di destinazione in un secondo momento.
Fase 3: svuotamento
Per prepararti a trasferire i client dai database di origine ai database di destinazione, devi assicura che i database di origine e di destinazione siano completamente sincronizzati. Il traferimento è il processo di migrazione delle modifiche rimanenti dai database di origine ai database di destinazione.
Questa fase è costituita da quanto segue:
- Mettere in stato di attesa i sistemi di database di origine. Ciò significa che non possono verificarsi modifiche ai dati nel database di origine e che il log delle transazioni non riceve voci di modifica aggiuntive.
- In attesa della migrazione di tutte le modifiche ai database di destinazione. Questo processo è l'effettivo svuotamento delle modifiche.
- Al termine dello svuotamento, esegui il backup dei database di destinazione per abbiano un punto di partenza definito per i futuri backup incrementali.
Il risultato della fase di svuotamento è che i sistemi di database di origine e di destinazione vengono sincronizzati e non verranno apportate modifiche ai dati.
Per assicurare che lo svuotamento sia completato, viene inserito un "ultimo inserimento" che un elemento dati può essere scritto in un database di origine. Una volta visualizzato l'elemento dati "ultimo insert" nel database di destinazione corrispondente, la fase di svuotamento è completata.
Fase 4: cambio
Una volta completata la fase di svuotamento, puoi trasferire i client ai database di destinazione. Consigliamo le seguenti best practice:
- Prima di abilitare l'accesso al database di produzione, testa la versione di base per garantire che i clienti siano operativi comportarsi come previsto. Il numero di scenari di test determinerà lo stato per il database di produzione.
- Esegui il backup dei database di destinazione prima di abilitare l'accesso client. Questo migliore assicura che lo stato iniziale dei database di destinazione recuperabili.
Al termine del passaggio, i clienti saranno pienamente operativi e inizieranno a accedere a database di produzione (quelli che nel documento sono indicati come fino a questo punto).
Fase 5: eliminazione del database di origine
Una volta completato il passaggio ai database di produzione, puoi eliminare i database di origine. È buona norma eseguire un backup finale di ogni origine in modo che tu abbia uno stato finale definito accessibile. I regolamenti relativi ai dati potrebbero richiedere anche backup finali per motivi di conformità.
Fase 6: fallback
L'implementazione di un fallback, soprattutto per i client di database molto critici, può rappresentano una valida protezione da eventuali inconvenienti legati alla migrazione. Un'alternativa è come una migrazione, ma al contrario. In altre parole, con un piano di riserva configuri una migrazione dai database di destinazione ai database di origine. Con le migrazioni di database eterogenee, il fallback è più complesso. Ecco perché di eseguire il passaggio solo dopo aver verificato meticolosamente che i tuoi di migrazione del database e le applicazioni connesse gli accordi sul livello del servizio (SLA).
Dopo aver svuotato i database di origine e aver eseguito il backup di tutti i database, puoi attivare i processi di migrazione che identificano le modifiche nei database di destinazione e le eseguono nei database di origine prima del passaggio.
La creazione di questi processi di migrazione garantisce che, dopo che i clienti apportino modifiche i database di destinazione, i database di origine e il relativo stato dei dati vengono mantenuti aggiornati. Potrebbe essere necessario un piano di riserva alcuni giorni o alcune settimane dopo il passaggio. Ad esempio, i client potrebbero accedere alla funzionalità per la prima volta e essere bloccati a causa di una funzionalità non funzionante che non può essere riparata rapidamente. Nella In questo caso, è possibile ripristinare l'accesso dei client ai database di origine. Prima di ripristinare i client, tutte le modifiche ai database di destinazione devono lo svuotamento nei database di origine.
In questo approccio, alcune circostanze richiedono un'attenzione particolare:
- Devi progettare gli schemi di destinazione in modo che una migrazione inversa (dalla destinazione ai database di origine) è possibile. Ad esempio, se il processo di migrazione iniziale (dall'origine alla destinazione) include unioni o aggregazioni, una migrazione inversa non è banale o addirittura impossibile. In tal caso, i singoli dati devono essere disponibili anche nei database di destinazione.
- Potrebbe verificarsi un problema in cui i database di origine dispongono di log delle transazioni, ma i database di destinazione non forniscono una funzionalità non funzionale di questo tipo. Nella In questo caso, una migrazione inversa (dalla destinazione all'origine) deve basarsi le query differenziali. Questa configurazione deve essere progettata e preparata negli schemi del database di destinazione.
- I client che operavano originariamente sui database di origine devono essere conservati disponibili e operative, in modo da poter essere attivate in un fallback. Per garantire l'equivalenza funzionale, qualsiasi modifica funzionale apportata ai client che accedono ai database di destinazione deve essere apportata anche ai client che accedono al database di origine.
Sebbene un piano di riserva sia l'ultima risorsa, la sua implementazione è essenziale e deve essere considerata come una migrazione completa del database, che include i test.
Modifiche dinamiche durante la migrazione
In generale, i database sono sistemi dinamici perché i valori di schema e dati possono cambiare. Gli schemi di database possono cambiare in base a fattori come i requisiti aziendali e i valori dei dati possono cambiare insieme alle modifiche dello schema o indipendentemente da queste. Dati le modifiche ai valori possono avvenire in modo dinamico in qualsiasi momento con le modifiche corrispondenti dell'implementazione di un'applicazione. Le seguenti sezioni discutono alcuni dei possibili modifiche e le loro implicazioni per una migrazione di database.
Modifiche allo schema
I database possono essere suddivisi in sistemi che richiedono uno schema predefinito senza schema o senza schema. In generale, i sistemi che richiedono lo schema predefinito supporta le operazioni di modifica dello schema, ad esempio l'aggiunta o colonne in un sistema relazionale.
In questi sistemi, puoi controllare le modifiche attraverso un processo di gestione dei cambiamenti. R perché il processo di gestione dei cambiamenti consente di apportare modifiche in modo controllato. Qualsiasi operazione che dipendono dallo schema, come query o processi di migrazione dei dati, vengono modificate per garantire una variazione globale coerente.
I sistemi di database che non richiedono uno schema predefinito possono essere modificati in qualsiasi nel tempo. Una modifica dello schema non può essere eseguita solo da un utente autorizzato, in alcuni casi è possibile tramite programmazione. In questi casi, una modifica dello schema può avvenire in qualsiasi momento. Le operazioni che dipendono dallo schema potrebbero non riuscire, ad esempio le query o processi di migrazione dei dati. Per evitare modifiche non controllate dello schema in questi sistemi di database, devi implementare una procedura di gestione delle modifiche come convenzione e regola accettata anziché tramite l'applicazione forzata del sistema.
Modifiche ai dati
In generale, gli schemi controllano i possibili valori dei dati per i vari dati attributi. I sistemi senza schema non hanno vincoli sui valori dei dati.
In entrambi i casi, possono essere visualizzati valori di dati che non erano stati precedentemente archiviati. Per Ad esempio, i tipi di enumerazione sono spesso implementati come un insieme di stringhe nel database sistemi operativi. A livello di linguaggio di programmazione, questi valori potrebbero essere implementati nei client come tipi di enumerazione veri e propri, ma non necessariamente. È possibile che un client memorizzi ciò che considera un valore di enumerazione valido, mentre altri client non lo considerano valido. Inoltre, un processo di migrazione dei dati potrebbe disattivare la funzionalità dei valori di enumerazione. Se vengono visualizzati nuovi valori, potrebbe non riuscire.
Un altro esempio si trova nella memorizzazione delle strutture JSON. In molti casi JSON le strutture sono memorizzate in una stringa di tipo dati; tuttavia, vengono interpretati come Valori JSON al momento dell'accesso. Se la struttura JSON cambia, il sistema del database non rilevarlo; processi di migrazione dei dati che interpretano una stringa come un file JSON potrebbero non riuscire.
Modifiche al processo di migrazione
La gestione dei cambiamenti durante una migrazione continua del database è difficile e complessa e può causare errori di migrazione o incoerenze nei dati. È ottimale che le modifiche richieste vengono ritardate fino alla fine della fase di svuotamento, momento in cui i sistemi di database di origine e di destinazione siano sincronizzati. Modifiche in questo periodo sono quindi confinati ai database di destinazione e ai relativi client (a meno che viene implementato anche il fallback).
Se hai bisogno di modificare il processo di migrazione durante una migrazione dei dati, consigliamo di mantenere al minimo le modifiche ed eventualmente di apportare diverse delle modifiche, anziché una più complessa. Inoltre, ti consigliamo di eseguire prima un test di queste modifiche utilizzando istanze di test dei database di origine e di destinazione. Idealmente, carichi l'origine di test con i dati di produzione di cui poi esegui la migrazione al target di test. Con questo approccio, puoi verificare le modifiche proposte senza influire sulla migrazione in produzione in corso. Dopo aver testato e verificato le modifiche, puoi applicarle al sistema di produzione.
Affinché sia possibile apportare modifiche durante una migrazione dei dati in corso, devi essere in grado per arrestare il sistema di migrazione dei dati e riavviarlo, possibilmente con dati modificati i processi di migrazione. In questo caso, non è necessario partire dal a partire da una fase iniziale di caricamento dei dati. Se il sistema di migrazione dei dati supporta puoi usare anche una funzionalità di prova di esecuzione della migrazione.
Ti consigliamo di evitare di modificare lo schema, i valori dei dati o i processi di migrazione dei dati durante una migrazione dei dati. Se devi apportare modifiche, ti consigliamo di riavviare la migrazione dei dati dall'inizio per assicurarti di avere uno stato iniziale definito. In ogni caso, è fondamentale eseguire il test utilizzando di produzione ed eseguire il backup dei database prima di applicare modifiche che, se necessario, è possibile ripristinare uno stato coerente dell'intero sistema.
Mitigazione degli errori di migrazione
Durante una migrazione del database possono verificarsi problemi imprevisti. Di seguito sono evidenziate alcune aree che possono richiedere una pianificazione preliminare:
- Velocità in uscita insufficiente. Un sistema di migrazione può non essere sufficiente nonostante il test di carico. Questo problema può avere diverse cause, ad esempio come aumento imprevisto della frequenza delle modifiche al database di origine o della rete della limitazione. Puoi prepararti a questo caso preparando risorse aggiuntive per lo scale up o lo scale out dinamico di tutti i componenti coinvolti.
- Instabilità del database. I database di origine o di destinazione possono essere in stato di instabilità, il che può rallentare i processi di migrazione dei dati o impedire l'accesso in modo intermittente. I processi di migrazione dei dati potrebbero dover eseguire il ripristino di frequente. In questo caso, un cambio di HA o RE intenzionale risolvere il problema. Il passaggio cambia l'ambiente non funzionale (macchine e spazio di archiviazione) e potrebbe contribuire ad attenuare il problema. In questo caso, devi testare il cambio e il ripristino della migrazione del database per garantire che il passaggio non causi incoerenze nei dati nei database di destinazione.
- Superamento delle dimensioni del file del log delle transazioni. In alcuni casi, le transazioni I log vengono archiviati in file con un limite superiore. È possibile che questo viene raggiunto il limite superiore e la migrazione del database non riesce. È importante comprendere quali parti di un sistema di database possono essere riconfigurate dinamicamente per risolvere le limitazioni delle risorse man mano che si presentano. Se determinato gli aspetti non possono essere configurati dinamicamente, il dimensionamento iniziale deve essere attentamente determinato.
Più rendi realistici e completi i test preliminari, più è probabile che tu riesca a trovare potenziali problemi da risolvere in anticipo.
Passaggi successivi
- Consulta le seguenti risorse sulla migrazione del database:
- Consulta la sezione Migrazione del database per altre guide alla migrazione del database.
- Esplora le architetture di riferimento, i diagrammi e le best practice su Google Cloud. Dai un'occhiata al nostro Centro architetture cloud.