Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
# Fase 3: migrazione
Dopo aver completato la pianificazione della migrazione e identificato una strategia di migrazione, ha luogo la migrazione effettiva. In questa fase, viene progettato il database di destinazione, i dati di origine vengono migrati verso la destinazione e i dati vengono convalidati.
![\[Iterative migration process\]](http://docs.aws.amazon.com/it_it/prescriptive-guidance/latest/strategy-database-migration/images/iterative-migration-process.png)
Si tratta di un processo iterativo che include più cicli di conversione, migrazione e test. Una volta completati i test funzionali e prestazionali, puoi passare al nuovo database.
La fase di migrazione comprende i seguenti passaggi chiave, descritti nelle seguenti sezioni:
+ [Conversione dello schema](convert-schema.md)
+ [Migrazione dei dati](migrate-data.md)
+ [Aggiornamento dell'applicazione](update-app.md)
+ [Test della migrazione](test-migration.md)
+ [Passaggio al nuovo database](cut-over.md)
# Convertire lo schema
Una delle attività chiave durante la migrazione del database è la migrazione dello schema dal motore di database di origine al motore di database di destinazione. Se esegui il rehosting o la ripiattaforma, il motore di database non cambierà. Questa operazione viene definita *migrazione omogenea del database* ed è possibile utilizzare gli strumenti nativi del database per migrare lo schema.
Tuttavia, se state riprogettando l'applicazione, la conversione dello schema potrebbe richiedere uno sforzo maggiore. In questo caso, si effettuerà una *migrazione eterogenea del database, in cui i motori di database* di origine e di destinazione saranno diversi. Lo schema corrente del database potrebbe utilizzare pacchetti e funzionalità che non possono essere convertiti direttamente nel motore di database di destinazione. Alcune funzionalità potrebbero essere disponibili con un nome diverso. Pertanto, la conversione dello schema richiede una buona conoscenza dei motori di database di origine e di destinazione. Questa attività può essere impegnativa, a seconda della complessità dello schema corrente.
AWS fornisce due risorse per aiutarti con la conversione dello schema: AWS Schema Conversion Tool (AWS SCT) e i playbook di migrazione.
## AWS SCT
AWS SCT è uno strumento gratuito che può aiutarti a convertire il tuo database esistente da un motore all'altro. AWS SCT supporta diversi database di origine, tra cui Oracle, Microsoft SQL Server, MySQL, Sybase e IBM Db2 LUW. Puoi scegliere tra database di destinazione come Aurora MySQL e Aurora PostgreSQL.
AWS SCT fornisce un'interfaccia utente grafica che si connette direttamente ai database di origine e di destinazione per recuperare gli oggetti dello schema corrente. Una volta connesso, è possibile generare un rapporto di valutazione della migrazione del database per ottenere un riepilogo di alto livello dello sforzo di conversione e delle azioni da intraprendere. La seguente illustrazione della schermata mostra un esempio di rapporto di valutazione della migrazione del database.
![\[Sample database migration assessment report from AWS SCT\]](http://docs.aws.amazon.com/it_it/prescriptive-guidance/latest/strategy-database-migration/images/sct-assessment-report.png)
Con AWS SCT è possibile convertire lo schema e distribuirlo direttamente nel database di destinazione oppure è possibile ottenere file SQL per lo schema convertito. Per ulteriori informazioni, consulta [Uso dell'interfaccia AWS Schema Conversion Tool utente](https://docs.aws.amazon.com/SchemaConversionTool/latest/userguide/CHAP_UserInterface.html) nella AWS documentazione.
## Playbook sulla migrazione
Sebbene AWS SCT converta molti degli oggetti di origine, alcuni aspetti della conversione richiedono interventi e regolazioni manuali. Per facilitare questa operazione, AWS fornisce dei playbook di migrazione che descrivono in dettaglio le incompatibilità e le somiglianze tra due database. [Per ulteriori informazioni su questi playbook, consultate le risorse sul sito Web.AWS Database Migration Service](https://aws.amazon.com/dms/resources/) AWS
# Esegui la migrazione dei dati
Una volta completata la migrazione dello schema, puoi spostare i dati dal database di origine al database di destinazione. A seconda dei requisiti di disponibilità dell'applicazione, è possibile eseguire un semplice processo di estrazione che esegue una copia unica dei dati di origine nel nuovo database. In alternativa, è possibile utilizzare uno strumento che copia i dati correnti e continua a replicare tutte le modifiche finché non si è pronti per passare al nuovo database. Per le migrazioni con rehosting e ripiattaforma, ti consigliamo di utilizzare strumenti nativi specifici del database per migrare i dati.
Gli strumenti che possono aiutarti con il trasferimento dei dati includono AWS Database Migration Service () e strumenti di migrazione offline.AWS DMS Queste informazioni vengono descritte nelle sezioni seguenti.
## AWS DMS
Dopo averli utilizzati AWS SCT per convertire gli oggetti dello schema dal motore di database di origine al motore di destinazione, è possibile utilizzarli AWS DMS per migrare i dati. Con AWS DMS puoi mantenere attivo e funzionante il database di origine mentre i dati vengono replicati. È possibile eseguire una copia unica dei dati o eseguire una copia con replica continua. Quando i database di origine e di destinazione sono sincronizzati, puoi mettere il database offline e spostare le operazioni nel database di destinazione. AWS DMS può essere utilizzato per migrazioni di database omogenee (ad esempio, da un database Oracle locale a un database Amazon RDS for Oracle) nonché migrazioni eterogenee (ad esempio, da un database Oracle locale a un database Amazon RDS for PostgreSQL). Per ulteriori informazioni sull'utilizzo di AWS DMS, consulta la [documentazione di AWS DMS](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_GettingStarted.html).
## Opzioni di migrazione offline
È possibile utilizzare altre opzioni oltre AWS DMS a estrarre i dati dal database di origine e caricarli nel database di destinazione. Queste opzioni sono adatte soprattutto quando è consentito il downtime delle applicazioni durante l'attività di migrazione dei dati. Alcuni esempi di questi metodi includono:
+ Un estratto di valori separati da virgole (CSV) dal database di origine caricato nel database di destinazione
+ Per i database di origine Oracle, l'utilità **ora2pg** per copiare i dati su PostgreSQL
+ Lavori personalizzati di estrazione, trasformazione, caricamento (ETL) per copiare i dati dall'origine alla destinazione
# Aggiornamento dell'applicazione
Una migrazione di database non è quasi mai una migrazione di soli database. È necessario esaminare l'applicazione che utilizza il database per assicurarsi che funzioni come previsto con il nuovo database. Le modifiche sono minime se si sta semplicemente riospitando o riplatformando lo stesso motore di database, ma possono essere più significative se si decide di passare a un nuovo motore di database.
Se l'applicazione si basa su una mappatura relazionale a oggetti (ORM) per interagire con il database, non richiederà tante modifiche quando si esegue la migrazione a un nuovo motore di database. Tuttavia, se l'applicazione prevede interazioni personalizzate con il database o query SQL create dinamicamente, le modifiche possono essere considerevoli. Potrebbero esserci differenze nei formati di query che devono essere corrette per assicurarsi che l'applicazione funzioni come previsto.
Ad esempio, in Oracle, la concatenazione di una stringa con `NULL` restituisce la stringa originale. Tuttavia, in PostgreSQL, la concatenazione di una stringa con restituzioni. `NULL` `NULL` Un altro esempio è come `NULL` vengono trattate le stringhe vuote. In PostgreSQL, le stringhe vuote sono due cose diverse`NULL`, mentre i database come Oracle le trattano allo stesso modo. In Oracle, se inserisci una riga con il valore della colonna impostato su `NULL` o una stringa vuota, puoi recuperare entrambi i tipi di valori utilizzando la clausola:. `where` `where is NULL` In PostgreSQL, `where` questa clausola restituirà solo una riga in cui il valore della colonna è effettivamente NULL; non restituirà la riga con un valore di stringa vuoto. [Per ulteriori informazioni su queste differenze, consulta i playbook sulla migrazione elencati nella pagina web delle risorse.AWS Database Migration Service](https://aws.amazon.com/dms/resources/)
# Verificate la migrazione
I test funzionali e prestazionali sono una parte essenziale delle migrazioni dei database. Test funzionali dettagliati assicureranno che l'applicazione funzioni con il nuovo database senza problemi. È necessario dedicare tempo allo sviluppo di unit test per testare i flussi di lavoro delle applicazioni.
I test delle prestazioni assicurano che i tempi di risposta del database rientrino in un intervallo di tempo accettabile. È possibile identificare i punti deboli, ottimizzare e ripetere il test delle prestazioni. Ripetete il ciclo secondo necessità per ottenere i risultati prestazionali desiderati.
I test possono essere manuali o automatizzati. Ti consigliamo di utilizzare un framework automatizzato per i test. Durante la migrazione, dovrai eseguire il test più volte, quindi disporre di un framework di test automatizzato aiuta ad accelerare i cicli di correzione e ottimizzazione dei bug.
Questo test può rivelare problemi che non sono stati rilevati durante le fasi di sviluppo. Ad esempio, qualsiasi query convertita in modo errato avrà esito negativo o restituirà risultati errati, causando il fallimento del test funzionale. I test delle prestazioni possono rivelare problemi come gli indici mancanti che rallentano i tempi di risposta alle query. Possono inoltre rivelare problemi di prestazioni che richiedono l'ottimizzazione del motore di database, a seconda del carico di lavoro, o la modifica della query.
# Tagliare
La strategia di cutover del database è in genere strettamente associata ai requisiti di inattività dell'applicazione. Le strategie che è possibile utilizzare per il cutover del database includono la migrazione offline, la migrazione flash-cut, la configurazione attiva/attiva del database e la migrazione incrementale. Questi dettagli vengono illustrarti nelle sezioni seguenti.
## Migrazione offline
Se riesci a mettere offline l'applicazione per un periodo prolungato durante le operazioni di scrittura, puoi utilizzare le impostazioni delle attività AWS DMS a caricamento completo o una delle opzioni di migrazione offline per la migrazione dei dati. Il traffico di lettura può continuare durante la migrazione, ma il traffico di scrittura deve essere interrotto. Poiché tutti i dati devono essere copiati dal database di origine, vengono utilizzate risorse del database di origine come I/O e CPU.
Ad alto livello, la migrazione offline prevede i seguenti passaggi:
1. Completa la conversione dello schema.
1. Avvia i tempi di inattività per il traffico di scrittura.
1. Esegui la migrazione dei dati utilizzando una delle opzioni di migrazione offline.
1. Verifica i tuoi dati.
1. Indirizza l'applicazione al nuovo database.
1. Termina i tempi di inattività delle applicazioni.
## Migrazione Flash-cut
Nella migrazione flash-cut, l'obiettivo principale è ridurre al minimo i tempi di inattività. Questa strategia si basa sulla replica continua dei dati (CDC) dal database di origine al database di destinazione. Vengono utilizzati tutti i read/write traffic will continue on the current database while the data is being migrated. Because all the data needs to be copied from the source database, source server resources such as I/O componenti e la CPU. È necessario eseguire dei test per assicurarsi che questa attività di migrazione dei dati non influisca sulle prestazioni SLAs dell'applicazione.
A un livello elevato, la migrazione flash-cut prevede i seguenti passaggi:
1. Completa la conversione dello schema.
1. Configurazione AWS DMS in modalità di replica continua dei dati.
1. Quando i database di origine e di destinazione sono sincronizzati, verifica i dati.
1. Avvia il downtime dell'applicazione.
1. Implementate la nuova versione dell'applicazione, che rimanda al nuovo database.
1. Termina il periodo di inattività dell'applicazione.
## Configurazione attiva/attiva del database
La configurazione attiva/attiva del database prevede l'impostazione di un meccanismo per mantenere sincronizzati i database di origine e di destinazione mentre entrambi i database vengono utilizzati per il traffico di scrittura. Questa strategia richiede più lavoro rispetto alla migrazione offline o istantanea, ma offre anche una maggiore flessibilità durante la migrazione. Ad esempio, oltre a subire tempi di inattività minimi durante la migrazione, è possibile spostare il traffico di produzione verso il nuovo database in piccoli batch controllati anziché eseguire un cutover una tantum. [È possibile eseguire operazioni di scrittura doppia in modo da apportare modifiche a entrambi i database oppure utilizzare uno strumento di replica bidirezionale come HVR per mantenere i database sincronizzati.](https://www.hvr-software.com/product/) Questa strategia presenta una maggiore complessità in termini di configurazione e manutenzione, pertanto sono necessari ulteriori test per evitare problemi di coerenza dei dati.
Ad alto livello, la configurazione attiva/attiva del database prevede i seguenti passaggi:
1. Completa la conversione dello schema.
1. Copia i dati esistenti dal database di origine al database di destinazione, quindi mantieni sincronizzati i due database utilizzando uno strumento di replica bidirezionale o due scritture dall'applicazione.
1. Quando i database di origine e di destinazione sono sincronizzati, verifica i dati.
1. Inizia a spostare un sottoinsieme del traffico verso il nuovo database.
1. Continua a spostare il traffico fino a quando tutto il traffico del database non sarà stato spostato nel nuovo database.
## Migrazione incrementale
Nella migrazione incrementale, si esegue la migrazione dell'applicazione in parti più piccole anziché eseguire un cutover completo una tantum. Questa strategia di cutover potrebbe presentare molte varianti, in base all'architettura dell'applicazione corrente o al refactoring che intendete apportare all'applicazione.
È possibile utilizzare un [modello di progettazione](https://samirbehara.com/2018/09/10/monolith-to-microservices-using-strangler-pattern/) per aggiungere nuovi microservizi indipendenti per sostituire parti di un'applicazione legacy monolitica esistente. Questi microservizi indipendenti dispongono di tabelle proprie che non sono condivise o accessibili da nessun'altra parte dell'applicazione. È possibile migrare questi microservizi nel nuovo database uno per uno, utilizzando una qualsiasi delle altre strategie di cutover. I microservizi migrati iniziano a utilizzare il nuovo database per il traffico di lettura/scrittura, mentre tutte le altre parti dell'applicazione continuano a utilizzare il vecchio database. Una volta completata la migrazione di tutti i microservizi, l'applicazione precedente viene disattivata. Questa strategia suddivide la migrazione in parti più piccole e gestibili e può quindi ridurre i rischi associati a una migrazione di grandi dimensioni.
# Segui le best practice su AWS
Oltre alle attività di migrazione discusse nelle sezioni precedenti, dovresti dedicare del tempo ad assicurarti di seguire le migliori pratiche per ospitare il tuo database nel AWS Cloud. Consulta la [AWS documentazione](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_BestPractices.html) per le migliori pratiche per lavorare con i database relazionali su AWS.