Come abbiamo mantenuto sincronizzati due database con strutture differenti fino alla migrazione finale
In ogni progetto di trasformazione digitale c’è un momento in cui il passato e il futuro devono coesistere.
Un database legacy, pieno di storia, ma non più sostenibile. Un nuovo schema, pulito e normalizzato, pronto a diventare il cuore pulsante del sistema. Ma nel mezzo c’è il presente, con tutte le sue esigenze di coerenza, integrità e continuità operativa.
È in questo scenario che siamo stati chiamati a intervenire con Shellonback.
🧩 La sfida
Il cliente aveva due database MySQL:
- Database “source”: un sistema legacy non normalizzato, ancora utilizzato in produzione.
- Database “destination”: un nuovo database normalizzato, destinato a sostituire il primo.
L’obiettivo: mantenere sincronizzati entrambi i database per un periodo di transizione, fino alla migrazione completa.
Tradotto: ogni modifica effettuata nel database legacy doveva propagarsi nel nuovo database, in tempo quasi reale, e viceversa in alcuni casi specifici.
⚙️ La nostra soluzione tecnica
Abbiamo costruito un flusso ETL (Extract, Transform, Load) moderno e reattivo, utilizzando strumenti open source pensati per architetture real-time e data integration scalabile:
- Kafka come bus di eventi centrale
- Debezium per il change data capture del database legacy
- Apache NiFi per orchestrare, trasformare e dirigere i flussi tra le varie fonti e destinazioni
🧪 Il flusso, passo dopo passo
- 📥 Cattura dei cambiamenti
Grazie a Debezium, ogni inserimento, aggiornamento o cancellazione nel database legacy viene intercettato in tempo reale tramite il binlog di MySQL.
Questi eventi vengono pubblicati automaticamente su Kafka, in topic strutturati per entità (es.db_source.users,db_source.orders). - 🔀 Trasformazione e normalizzazione
In Apache NiFi, abbiamo configurato una pipeline intelligente capace di:- Leggere i messaggi da Kafka
- Trasformare i dati secondo le regole di normalizzazione richieste
- Gestire i mapping tra entità (es. split di tabelle, join logici, ristrutturazione JSON)
- 📤 Scrittura sul database di destinazione
Dopo la trasformazione, NiFi esegue l’upsert (insert/update) nel nuovo database normalizzato.
Questo assicura che il dato più recente sia sempre allineato tra le due strutture. - (Opzionale) ↩️ Flussi inversi e logiche selettive
Per specifici casi (es. modifiche su tabelle amministrative del nuovo DB), abbiamo previsto il flusso inverso: dal destination al source, sempre con Kafka e NiFi.
🚀 I benefici per il cliente
- ✅ Continuità operativa: nessun downtime durante la migrazione
- 🔄 Dati coerenti tra vecchio e nuovo schema, anche in presenza di strutture divergenti
- 🧼 Normalizzazione graduale: la trasformazione avviene in tempo reale, senza dover attendere la fine del progetto
- 🔍 Audit e tracciabilità: ogni cambiamento è monitorabile e ricostruibile
📈 Quando la sincronizzazione diventa un vantaggio competitivo
La maggior parte delle aziende teme il momento della migrazione dei dati. Con Shellonback, trasformiamo questa sfida in un’opportunità di evoluzione.
Utilizzando strumenti come Kafka, Debezium e NiFi, creiamo architetture resilienti e flessibili, capaci di adattarsi a ogni esigenza.
Se stai affrontando una migrazione dati, una ristrutturazione dei tuoi sistemi o vuoi semplicemente modernizzare la tua infrastruttura, parliamone.
👉 Contattaci oggi per una call di assessment gratuita.
