Migrazione omogenea vs eterogenea

Il primo criterio di design è capire se sorgente e destinazione condividono lo stesso motore. Una migrazione omogenea sposta i dati fra database dello stesso engine (es. MySQL on-prem → Cloud SQL for MySQL, o PostgreSQL → AlloyDB): schema, tipi di dato e SQL restano compatibili, quindi non serve conversione. Una migrazione eterogenea cambia motore (es. Oracle → Cloud SQL for PostgreSQL o AlloyDB) e impone la conversione di schema, tipi, stored procedure e query: è più rischiosa, più lenta e richiede test di equivalenza applicativa.

Database Migration Service (DMS) copre entrambi gli scenari: omogenei con lift-and-shift gestito e continuous replication, ed eterogenei Oracle→PostgreSQL con conversione DDL assistita. Datastream è il servizio CDC serverless per lo streaming continuo dei change (spesso verso BigQuery per l’analitica, o come feed CDC). Per carichi Oracle che non possono essere convertiti, Bare Metal Solution ospita Oracle su hardware dedicato adiacente a Google Cloud.

Zero/near-zero downtime con CDC

La strategia dipende dalla finestra di downtime tollerata dal business (l’RTO di cutover).

  • Zero/near-zero downtime: DMS esegue un full dump iniziale e poi attiva la change data capture (CDC), applicando in continuo le modifiche lette dal transaction log della sorgente (binary log MySQL, WAL PostgreSQL, redo log Oracle). Sorgente e destinazione restano sincronizzate; il cutover è una finestra brevissima in cui si ferma la scrittura sulla sorgente, si attende che DMS applichi l’ultimo delta e si ripunta l’applicazione. È la scelta per sistemi H24 con RPO≈0.
  • Extended outage (one-time snapshot): se il business tollera una finestra pianificata, si esporta e importa il dataset in blocco senza CDC. Più semplice, meno componenti, ma downtime proporzionale alla mole di dati.

Il vincolo tecnico del CDC è che la sorgente abbia il logging abilitato correttamente (WAL a livello logical, supplemental logging su Oracle) e connettività verso Google Cloud, tipicamente via private connectivity (VPC peering / private IP) invece che IP pubblico.

Extended outage, fallback e reverse replication

Nessuna migrazione è completa senza un piano di fallback. Dopo il cutover l’applicazione scrive sul nuovo database; se emerge un problema grave occorre poter tornare alla sorgente senza perdere le transazioni accumulate nel frattempo.

La reverse replication risolve esattamente questo: si configura un flusso CDC nella direzione inversa, da Google Cloud verso il database sorgente originale, così che la sorgente resti aggiornata anche dopo il go-live. In caso di rollback si ripunta l’applicazione alla sorgente, già allineata, minimizzando la perdita di dati. Va progettata prima del cutover, non improvvisata dopo. Non confondere il fallback (rollback di migrazione) con il disaster recovery: il DR riguarda la resilienza in esercizio (HA con failover replica, backup e PITR, read replica cross-region) e si misura con RTO/RPO, mentre il fallback è la exit strategy della migrazione stessa.

Migrazione eterogenea: conversione DDL/DML

Nell’eterogenea la parte critica è la conversione. Il DDL (schema: tabelle, tipi, indici, vincoli) va tradotto nei costrutti del motore di destinazione: i tipi Oracle come NUMBER, DATE, CLOB vanno mappati agli equivalenti PostgreSQL. Il DML e la logica proprietaria (PL/SQL, sequenze, trigger) spesso non hanno equivalente diretto e vanno riscritti. DMS assiste la conversione dello schema, ma le stored procedure complesse restano lavoro manuale e vanno validate. Solo dopo la conversione parte il carico dati + CDC.

Trappole tipiche d’esame

  • Downtime quasi nullo per un OLTP H24 → soluzione: DMS con full dump + CDC continuo e cutover breve; lo snapshot one-time (extended outage) fermerebbe il servizio troppo a lungo.
  • Rollback possibile dopo il go-live → soluzione: reverse replication da Google Cloud alla sorgente configurata prima del cutover; senza, il rollback perde le transazioni post-cutover.
  • Oracle → PostgreSQL/AlloyDB → soluzione: migrazione eterogenea con conversione DDL/DML; non è lift-and-shift, PL/SQL e tipi custom richiedono riscrittura e test.
  • “Migrare senza toccare lo schema” MySQL→Cloud SQL → soluzione: migrazione omogenea, nessuna conversione; scegliere l’eterogenea qui aggiunge rischio inutile.
  • Confondere fallback con DR → soluzione: il fallback è reverse replication verso la sorgente; il DR in esercizio è HA failover + PITR + read replica cross-region con RTO/RPO definiti.
  • CDC senza logging/connettività → soluzione: abilitare WAL logical / supplemental logging e private connectivity; senza log dei cambiamenti o rete privata il CDC non parte.