Scegliere lo strumento giusto

Database Migration Service (DMS) e Datastream sono entrambi costruiti sul CDC (Change Data Capture), ma risolvono problemi diversi e l’esame gioca proprio su questa confusione. DMS è lo strumento di migrazione: sposta un intero database verso Google Cloud con l’obiettivo di un cutover finale e downtime minimo. Datastream è un servizio di replica/CDC serverless pensato per alimentare pipeline analitiche o di integrazione, non per portare la produzione su una nuova piattaforma.

Regola pratica per gli scenari: se la domanda parla di “migrare a Cloud SQL o AlloyDB con downtime minimo” → DMS. Se parla di “replicare i cambiamenti verso BigQuery per analitica quasi real-time” → Datastream.

Database Migration Service

DMS copre migrazioni omogenee (MySQL → Cloud SQL for MySQL, PostgreSQL → Cloud SQL for PostgreSQL o AlloyDB, SQL Server → Cloud SQL for SQL Server) ed eterogenee (Oracle → PostgreSQL su Cloud SQL o AlloyDB). Nelle omogenee il motore non cambia; nelle eterogenee serve una conversione di schema (conversion workspace) perché dialetto SQL, tipi di dato e oggetti differiscono.

Il flusso tipico è: full dump iniziale + replica continua via CDC letta dal transaction log della sorgente (binary log per MySQL, WAL per PostgreSQL, redo log per Oracle). La sorgente resta operativa mentre i dati si sincronizzano; al cutover si promuove la destinazione e si ripunta l’applicazione. È questo che rende il downtime minimo (continuous migration), in contrasto con un import one-time in cui il fermo coincide con la durata del dump. DMS è serverless e non ha un costo proprio: si paga la destinazione.

Datastream

Datastream esegue CDC serverless da Oracle, MySQL, PostgreSQL e SQL Server verso BigQuery (replica diretta) o Cloud Storage; da lì si può proseguire con Dataflow verso altre destinazioni come Cloud SQL o Spanner. Il caso d’uso classico è mantenere BigQuery allineato quasi in tempo reale con un database OLTP per analitica, senza gravare sul database di produzione. Non è uno strumento di cutover: non “diventa” il database primario dell’applicazione.

Sorgenti on-prem e fuori Google Cloud

Entrambi migrano o replicano da database ospitati on-prem o su altri cloud. La connettività va progettata a parte: IP allowlisting, VPC peering / private connectivity, reverse SSH tunnel, oppure VPN/Interconnect per il traffico privato. Occorre inoltre abilitare il logging CDC sulla sorgente (binary log per MySQL, logical replication/WAL per PostgreSQL, supplemental logging per Oracle) e un utente con i privilegi adeguati: molti fallimenti “di connessione” derivano proprio da questi prerequisiti mancanti.

Trappole tipiche d’esame

  • Oracle → PostgreSQL con downtime minimo → DMS eterogeneo (conversion workspace): è la migrazione, con replica continua CDC fino al cutover. Datastream qui è la risposta esca: serve per CDC verso BigQuery, non fa cutover applicativo.
  • Replica continua verso BigQuery per dashboard quasi real-time → Datastream: DMS migra e si conclude con un cutover, non è progettato per alimentare in modo permanente un data warehouse.
  • One-time vs continuous migration → scegli continuous per il minimo downtime: one-time è solo snapshot (fermo pari alla durata del dump); continuous è snapshot + CDC con cutover a sincronizzazione avvenuta.
  • Mantenere Oracle come Oracle senza refactor → Bare Metal Solution, non DMS: DMS eterogeneo converte a PostgreSQL; se l’applicazione richiede Oracle nativo la conversione non è un’opzione e la migrazione lift-and-shift va su Bare Metal Solution.
  • Migrazione omogenea ≠ zero downtime automatico: anche MySQL → Cloud SQL richiede CDC + cutover per ridurre il fermo; senza replica continua resta un import con downtime pari al caricamento.
  • Sorgente on-prem che “non si connette” → prerequisiti CDC e connettività: verifica binary log/WAL/supplemental logging abilitati, privilegi dell’utente e private connectivity/VPC peering/SSH tunnel prima di sospettare lo strumento.