Case Study
ETL bidirezionale tra due database MySQL con Kafka, Debezium e Apache NiFi
schedule3 min
calendar_today26 luglio 2025
syncCaricamento...
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 centro del sistema. 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 come 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.
In pratica: ogni modifica effettuata nel database legacy doveva propagarsi nel nuovo database in tempo quasi reale, e in alcuni casi specifici anche nel senso opposto.
La nostra soluzione tecnica
Abbiamo costruito un flusso ETL (Extract, Transform, Load) moderno e reattivo, con strumenti open source pensati per architetture in tempo reale e per un’integrazione dei dati scalabile:
- Kafka come bus di eventi centrale
- Debezium per il change data capture del database legacy
- Apache NiFi per orchestrare, trasformare e instradare 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 organizzati per entità (es.db_source.users,db_source.orders). - Trasformazione e normalizzazione
In Apache NiFi abbiamo configurato una pipeline in grado 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.
In questo modo il dato più recente è sempre allineato tra le due strutture. - (Opzionale) Flussi inversi e logiche selettive
Per casi specifici (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. In Shellonback trasformiamo questa difficoltà in un’occasione per far evolvere i sistemi.
Con strumenti come Kafka, Debezium e NiFi costruiamo 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 valutazione gratuita.
forum
Devi tenere allineati due database durante una migrazione? Chiedimi come.
Ti rispondiamo subito e, se vuoi, prepariamo il preventivo per il tuo caso.