Best practice per la migrazione dei database

La migrazione di un database è più complessa dello spostamento di una VM perché i database sono con stato e spesso hanno connessioni attive 24 ore su 24, 7 giorni su 7. Un semplice approccio di copia e ripristino richiede ore di inattività, una situazione inaccettabile per i sistemi di produzione. Le procedure consigliate per la migrazione dei database usano la replica continua dei dati per mantenere sincronizzate l'origine e la destinazione mentre si convalida la destinazione, quindi eseguono un breve passaggio pianificato, durante il quale il traffico viene reindirizzato al nuovo database Azure.

Azure Database Migration Service (DMS) è un servizio completamente gestito che orchestra migrazioni online (con tempi di inattività quasi nulli) e offline (basate su un periodo di inattività) dai principali motori locali ai servizi di database gestiti di Azure. DMS supporta origini come SQL Server, MySQL, PostgreSQL, MongoDB, Oracle e destinazioni come Azure SQL Database, Azure SQL Managed Instance, Azure Database for MySQL e Azure Cosmos DB. Il servizio si integra con Data Migration Assistant (DMA) per i controlli di compatibilità pre-migrazione.

Prima di eseguire la migrazione di SQL Server, esegua Data Migration Assistant (DMA) sul database di origine. DMA identifica: problemi di compatibilità (funzionalità usate nel database non supportate dalla destinazione Azure SQL), modifiche incompatibili, funzionalità deprecate e consigli sulle prestazioni. Genera un report HTML dettagliato che assegna la priorità ai problemi in base alla gravità, affinché il team possa risolverli prima dell'inizio della finestra di migrazione.

La migrazione offline mantiene il database di origine offline per tutta la durata della migrazione: è una soluzione accettabile per database di piccole dimensioni o sistemi non critici per i quali è possibile pianificare una finestra di manutenzione. La migrazione online usa il rilevamento dei dati modificati (CDC) o la replica del registro delle transazioni per replicare continuamente le modifiche mentre viene caricato il nuovo database, riducendo i tempi di inattività al solo passaggio finale. La migrazione online è consigliata per database di dimensioni superiori a 1 GB o con SLA che richiedono meno di 1 ora di inattività.

Un progetto di migrazione DMS specifica la connessione all'origine (nome del server, autenticazione, nomi dei database), la connessione alla destinazione (stringa di connessione Azure SQL) e la modalità di migrazione (online o offline). È inoltre possibile selezionare i database e le tabelle da migrare. DMS convalida la connettività prima dell'avvio. Il progetto di migrazione viene mantenuto nel portale Azure, consentendo di monitorare lo stato di avanzamento, riprovare le tabelle non riuscite e visualizzare log dettagliati delle attività.

Esegua sempre la migrazione dello schema prima dei dati. Usi DMA o SQL Server Management Studio (SSMS) per creare script e distribuire tabelle, viste, stored procedure, funzioni e indici nel database Azure SQL di destinazione. Verifichi che tutti gli oggetti dello schema esistano e vengano compilati senza errori prima di consentire a DMS di avviare il trasferimento dei dati. Gli errori dello schema rilevati durante la migrazione possono danneggiare l'esecuzione della migrazione e costringerLa a ripartire da zero.

DMS esegue un caricamento completo dei dati leggendo la tabella del database di origine una alla volta e scrivendo le righe nella destinazione Azure SQL tramite inserimento bulk. Durante il caricamento completo, il servizio gestisce le tabelle di grandi dimensioni suddividendole in batch. Gli indici nella destinazione vengono disabilitati durante il caricamento per massimizzare la velocità, quindi ricreati al termine. Per database molto grandi (su scala TB), valuti l'utilizzo di Azure Data Factory o di esportazioni bacpac per precaricare i dati e ridurre il tempo di esecuzione di DMS.

Per le migrazioni online, DMS abilita SQL Server Change Data Capture (CDC) nell'origine per acquisire le operazioni INSERT, UPDATE e DELETE che si verificano mentre è in corso il caricamento completo. Al termine del caricamento completo, DMS riapplica le modifiche acquisite nella destinazione, riducendo gradualmente il divario. Quando la latenza scende quasi a zero, il database è pronto per il cutover. CDC richiede che SQL Server Agent sia in esecuzione e che il database di origine sia in modalità full recovery.

Quando il ritardo di CDC è minimo, avvii il cutover nel portale DMS. DMS interrompe l'accettazione di nuovi eventi CDC, applica le modifiche rimanenti e contrassegna la migrazione come completata. A questo punto, reindirizzi le stringhe di connessione dell'applicazione all'endpoint Azure SQL. Esegua query di convalida dei dati confrontando il numero di righe e gli aggregati dei checksum tra origine e destinazione per le tabelle critiche. Mantenga il database di origine in modalità di sola lettura per 24–48 ore dopo il cutover, nel caso sia necessario eseguire un rollback.

Dopo la migrazione, Azure SQL Database potrebbe comportarsi diversamente da SQL Server locale a causa delle differenze nelle cache dei piani di query, nelle statistiche e nell'hardware. Esegua il Database Experimentation Assistant (DEA) per riprodurre le tracce del carico di lavoro nella destinazione Azure e confrontare i piani di esecuzione. Abiliti Automatic Tuning in Azure SQL per consentire al servizio di creare o eliminare automaticamente gli indici e imporre piani di query privi di regressioni, migliorando nel tempo le prestazioni senza interventi manuali.

DMS consente di eseguire la migrazione anche di motori open source: da MySQL a Azure Database for MySQL usando il modello mysqldump + binlog replication e da PostgreSQL a Azure Database for PostgreSQL usando gli slot di replica logica. Per le migrazioni da MongoDB a Cosmos DB, utilizzi l'API Cosmos DB for MongoDB e la pipeline nativa mongodump / mongorestore oppure il connettore MongoDB di Azure Data Factory per il CDC incrementale. Testi sempre la migrazione su una copia non di produzione prima di eseguirla sui dati live.

In questa lezione ha imparato che Azure Database Migration Service orchestra le migrazioni di database online e offline, che la valutazione pre-migrazione con DMA rileva i problemi di compatibilità prima della finestra di migrazione e che la cattura delle modifiche dei dati consente un cutover con tempi di inattività quasi nulli per i database di produzione. Prossimamente ci concentreremo sull'ottimizzazione dei costi di Azure.