Database Migration Service (DMS) e Schema Conversion Tool

AWS Database Migration Service (DMS) consente di migrare i database ad AWS con downtime minimo. Supporta migrazioni omogenee (ad esempio, da Oracle a Oracle o da MySQL a MySQL) ed eterogenee (ad esempio, da Oracle ad Aurora PostgreSQL o da SQL Server a MySQL). DMS utilizza un'istanza di replica che legge dall'origine, trasforma facoltativamente i dati e scrive nella destinazione. Pagate solo per il tempo di esecuzione dell'istanza di replica.

DMS dispone di tre componenti fondamentali. Gli Source Endpoints definiscono la connessione al database di origine (URL JDBC, credenziali, TLS). I Target Endpoints definiscono il database di destinazione. La Replication Instance è un server gestito basato su EC2 che DMS configura nel vostro VPC per eseguire il carico di lavoro della migrazione. Scegliete le dimensioni dell'istanza di replica in base alla quantità di dati da migrare e alla necessità di utilizzare il multi-AZ per l'istanza stessa.

DMS supporta due modalità di migrazione. Full Load copia tutti i dati esistenti dall'origine alla destinazione: è adatta quando potete permettervi un downtime o quando l'origine è in sola lettura durante la migrazione. Change Data Capture (CDC) acquisisce le modifiche successive dal transaction log dell'origine al termine del full load, mantenendo sincronizzate origine e destinazione. Una migrazione combinata Full Load + CDC riduce al minimo il downtime: migrate i dati mentre l'origine rimane attiva, quindi eseguite il cutover quando la destinazione è aggiornata.

AWS Schema Conversion Tool (SCT) è un'applicazione scaricabile gratuita che converte automaticamente lo schema del database di origine (DDL) in un formato compatibile con il motore del database di destinazione. Gestisce definizioni di tabelle, viste, stored procedure, funzioni e trigger. Per le migrazioni eterogenee (ad esempio, da Oracle a PostgreSQL), SCT converte automaticamente la maggior parte degli oggetti e segnala quelli che richiedono una revisione manuale a causa di differenze nella sintassi non supportata.

Per le migrazioni omogenee (stesso motore, ad esempio da MySQL on-premises a RDS for MySQL), SCT in genere non è necessario: lo schema è direttamente compatibile. DMS può eseguire immediatamente Full Load + CDC. Per le migrazioni eterogenee (motori diversi), SCT deve prima convertire lo schema, DMS gestisce la migrazione dei dati e potrebbe essere necessario riscrivere manualmente stored procedure e trigger privi di un equivalente nel motore di destinazione.

DMS supporta un'ampia gamma di origini: Oracle, SQL Server, MySQL, MariaDB, PostgreSQL, SAP ASE, MongoDB, IBM Db2 e S3. Le destinazioni supportate includono tutti i servizi elencati sopra, oltre a Amazon Redshift, DynamoDB, Kinesis Data Streams e Kafka. Questo rende DMS utile non solo per le migrazioni relazionali, ma anche per lo streaming degli eventi di modifica relazionali in un data lake o in un'architettura event-driven tramite CDC verso Kinesis.

DMS utilizza regole di mapping delle tabelle (JSON) per controllare quali schemi e tabelle includere o escludere e per applicare trasformazioni ai dati. Potete rinominare schemi o tabelle, convertire i valori delle colonne (ad esempio, trasformare tutte le stringhe in maiuscolo), aggiungere colonne derivate o filtrare le righe. Questa funzionalità è utile quando eseguite la migrazione verso una destinazione con convenzioni di denominazione diverse o quando desiderate migrare solo un sottoinsieme di tabelle.

DMS pubblica metriche in CloudWatch: FullLoadThroughputRowsSource (righe caricate al secondo), CDCLatencySource (ritardo tra il transaction log dell'origine e la relativa lettura da parte di DMS) e CDCLatencyTarget (ritardo tra la lettura da parte di DMS e la scrittura nella destinazione). Monitorate attentamente CDCLatencyTarget durante la fase di sincronizzazione: quando scende quasi a zero, la destinazione ha raggiunto l'origine e siete pronti per il cutover.

DMS Serverless configura e ridimensiona automaticamente la capacità di replica in base al carico di lavoro della migrazione, eliminando la necessità di scegliere e gestire le dimensioni di un'istanza di replica. Specificate le unità di capacità DMS (DCU) minime e massime e DMS ridimensiona automaticamente la capacità all'interno di tale intervallo. È ideale per le migrazioni con carico variabile o quando desiderate evitare il rischio di dimensionare troppo poco l'istanza di replica durante i picchi del carico di migrazione.

Dopo la migrazione, convalidate la completezza dei dati utilizzando Data Validation di DMS. Abilitatela nelle impostazioni del task: DMS confronta il numero di righe e i checksum tra le tabelle di origine e di destinazione, segnalando le discrepanze in una tabella di convalida separata. Per le migrazioni eterogenee, eseguite anche smoke test a livello di applicazione. Non eseguite mai il cutover finché la convalida non mostra zero discrepanze: riconciliare i dati dopo un cutover errato è molto più costoso che dedicare tempo aggiuntivo alla convalida.

Nell'esame SAA-C03, DMS compare negli scenari che richiedono la migrazione di database con downtime minimo. I segnali principali sono: 'migrate database with ongoing replication' → DMS Full Load + CDC. 'heterogeneous engine change' → prima SCT, poi DMS. 'replicate changes in near real time to a data lake' → DMS CDC verso Kinesis o S3. 'consolidate multiple source databases into one target' → più task DMS verso un unico target endpoint. DMS è specifico per la migrazione dei database: per la migrazione dei server utilizzate MGN, mentre per il trasferimento massivo di dati utilizzate DataSync o Snowball.

Verificate la vostra comprensione dei concetti AWS Solutions Architect (SAA-C03) trattati in questa lezione.

In questa lezione avete imparato che: DMS supporta migrazioni di database omogenee ed eterogenee utilizzando le modalità Full Load e CDC, SCT automatizza la conversione dello schema nelle migrazioni con cambio di motore e segnala gli elementi da sottoporre a revisione manuale e DMS Serverless ridimensiona automaticamente la capacità di replica, eliminando la necessità di scegliere le dimensioni dell'istanza. Nella prossima lezione esploreremo Amazon EventBridge per il routing basato sugli eventi e l'architettura dei bus.