AWS DMS: perché conviene evitare il filtro per colonna

AWS Database Migration Service (DMS) è uno degli strumenti più diffusi per la migrazione e la replica di database, in grado di gestire ambienti sia omogenei sia eterogenei. Quando si utilizza AWS Database Migration Service (DMS) per migrare dati da sorgenti come Amazon RDS MySQL e Amazon RDS PostgreSQL, l'applicazione di filtri sulla sorgente consente di limitare in modo efficace il numero e la tipologia di record trasferiti al database di destinazione. È però importante conoscere alcune limitazioni di questi filtri, per garantire una migrazione senza intoppi.

Panoramica di AWS DMS

AWS DMS abilita la migrazione dei dati replicando in modo continuo le modifiche dal database di origine a quello di destinazione, con un downtime minimo. Tra le funzionalità principali:

• Full Load, CDC e replica continua: supporta sia la migrazione iniziale sia la sincronizzazione continua.
• Mappatura di schemi e tabelle: consente di includere e trasformare gli oggetti in modo flessibile.
• Funzionalità di filtraggio: offre filtri a livello di riga e di colonna per definire quali dati replicare.
• Supporto per più motori di database: è compatibile con MySQL, PostgreSQL, SQL Server, Oracle e altri.

Nonostante queste potenzialità, il filtro per colonna in AWS DMS non sempre si comporta come ci si aspetta, in particolare quando si gestiscono aggiornamenti durante il CDC.

Cos'è il filtro per colonna in AWS DMS?

Il filtro per colonna in AWS DMS consente di includere o escludere righe dalla replica in base a condizioni applicate a colonne specifiche. È possibile, ad esempio, configurare un task DMS in modo che replichi solo le righe in cui una colonna come 'status' è uguale a 'active', oppure quelle in cui una colonna 'timestamp' è successiva a una data specifica. Una funzionalità particolarmente utile quando occorre migrare solo un sottoinsieme di dati o applicare logiche di business durante la migrazione.

Ecco un esempio di regola di filtro per colonna in DMS:

{
  "rules": [\
    {\
      "rule-type": "selection",\
      "rule-id": "1",\
      "rule-name": "FilterActiveUsers",\
      "object-locator": {\
        "schema-name": "public",\
        "table-name": "users"\
      },\
      "rule-action": "include",\
      "filters": [\
        {\
          "filter-type": "source",\
          "column-name": "status",\
          "filter-conditions": [\
            {\
              "filter-operator": "eq",\
              "value": "active"\
            }\
          ]\
        }\
      ]\
    }\
  ]

Caso d'uso: filtro per colonna durante la migrazione dei dati

Per verificare come DMS gestisce il filtro per colonna abbiamo realizzato un proof of concept (POC) per la migrazione dei dati da un'istanza RDS MySQL 8.0 a un'altra istanza RDS MySQL 8.0 tramite AWS Database Migration Service (DMS). Il requisito era semplice: replicare le righe dalla tabella di origine a quella di destinazione solo quando una colonna specifica, denominata "name", soddisfa una determinata condizione (cioè quando name = "b"). A questo scopo abbiamo sfruttato la funzionalità di filtro sulla colonna sorgente di DMS, che permette di includere o escludere righe in base a valori specifici.

Setup

• Origine: RDS MySQL 8.0.36
• Destinazione: RDS MySQL 8.0.36
• Versione DMS: Engine 3.5.4
• Modalità di migrazione: Full Load con CDC

Sul database di origine è stata creata una tabella di esempio:

CREATE TABLE `Sample` (
`id` varchar(255) NOT NULL,
`name` varchar(255) NOT NULL,
PRIMARY KEY (`id`)
);

È stato configurato un task di migrazione DMS con un filtro a livello di colonna per replicare solo le righe in cui name = 'b'.

Regola di mappatura DMS:

{
"rules": [\
{\
"rule-type": "selection",\
"rule-id": "098947021",\
"rule-name": "098947021",\
"object-locator": {\
"schema-name": "Test",\
"table-name": "Sample"\
},\
"rule-action": "include",\
"filters": [\
{\
"filter-type": "source",\
"column-name": "name",\
"filter-conditions": [\
{\
"filter-operator": "eq",\
"value": "b"\
}\
]\
}\
]\
}\
]
}

regola di selezione con filtro sulla sorgente

Osservazioni e risultati:

L'inserimento di una riga con name = 'b' è stato replicato correttamente. Allo stesso modo, un insert con name = 'a' è stato giustamente ignorato. Gli aggiornamenti, invece, mostrano delle incongruenze:

• L'update da name='a' a name='b' è stato ignorato, anche se il CDC aveva intercettato l'evento.

Se la validazione DMS è attiva, questo comportamento genera disallineamenti tra i record del database di origine e quello di destinazione, perché la validazione segnala le discrepanze.

Ciò evidenzia ancora una volta come AWS DMS applichi i filtri sulla base dello stato pre-update, con possibili problemi di integrità dei dati quando si utilizza il filtro per colonna.

Causa principale: come AWS DMS applica i filtri

AWS DMS valuta i filtri sulle colonne in base allo stato della riga precedente all'aggiornamento. Nello specifico:

• Eventi di insert: il filtro si applica ai valori della riga inserita.
• Eventi di update: il filtro viene valutato prima che l'aggiornamento venga applicato.
• Eventi di delete: il filtro verifica lo stato della riga prima della cancellazione.

Poiché gli update vengono filtrati in base allo stato originario della riga, un aggiornamento che modifica name = 'a' in name = 'b' viene ignorato: la riga non soddisfaceva la condizione del filtro prima dell'update, quindi non viene mai replicata.

Questo comportamento può generare incongruenze nei dati. Se un'applicazione si affida al filtraggio delle righe dopo un aggiornamento, i dati attesi rischiano di non essere mai replicati.

Workaround: filtraggio sul database di destinazione

Poiché AWS DMS non offre un'opzione per applicare i filtri dopo l'elaborazione di un aggiornamento, è necessario adottare un workaround:

Passaggio 1: rimuovere i filtri sulle colonne dal task DMS

Modificare il task DMS in modo che replichi tutti i dati, senza alcun filtro.

Passaggio 2: implementare il filtraggio sul database di destinazione

Anziché replicare direttamente nella tabella Sample del database di destinazione, è possibile replicare in una tabella di staging e poi utilizzare un trigger o una stored procedure per spostare le righe valide nella tabella Sample.

Creare una tabella di staging (sample_staging) nel database RDS MySQL di destinazione. Questa tabella conterrà temporaneamente i dati replicati prima del trasferimento nella tabella Sample.

Ad esempio, in MySQL:

CREATE TABLE sample_staging (
id INT PRIMARY KEY,
name VARCHAR(255)
);

Passaggio 3: creare una stored procedure

Creare una stored procedure che sposti le righe valide (ad esempio quelle in cui name = 'b') dalla tabella di staging (sample_staging) alla tabella di destinazione (Sample). Questa procedura gestirà sia gli insert sia gli update.

CREATE PROCEDURE MoveValidRowsToSample()
BEGIN
-- Insert or update valid rows in the Sample table
INSERT INTO Sample (id, name)
SELECT id, name
FROM sample_staging
WHERE name = 'b'
ON DUPLICATE KEY UPDATE
name = VALUES(name);
--Delete valid rows from the staging table
DELETE FROM sample_staging
WHERE name = 'b';
END

Passaggio 4: creare un trigger

Creare un trigger sulla tabella di staging (sample_staging) che richiami automaticamente la stored procedure ogni volta che una riga viene inserita o aggiornata.

CREATE TRIGGER after_insert_sample_staging
AFTER INSERT ON sample_staging
FOR EACH ROW
BEGIN
CALL MoveValidRowsToSample();
END

CREATE TRIGGER after_update_sample_staging
AFTER UPDATE ON sample_staging
FOR EACH ROW
BEGIN
CALL MoveValidRowsToSample();
END

Come funziona

• Database di origine: contiene i dati originali.
• AWS DMS: replica i dati dall'origine alla tabella sample_staging nel database RDS MySQL di destinazione.
• Tabella di staging (sample_staging): conserva temporaneamente tutti i dati replicati.
• Trigger: richiama automaticamente la stored procedure ogni volta che vengono inseriti o aggiornati dati nella tabella sample_staging.
• Stored procedure: sposta le righe valide (in cui name = 'b') da sample_staging alla tabella Sample.
• Tabella di destinazione (Sample): contiene solo le righe valide, dopo l'elaborazione del trigger e della stored procedure.

In PostgreSQL è possibile implementare una funzione analoga utilizzando trigger BEFORE INSERT OR UPDATE.

Test su RDS PostgreSQL

Per essere certi che il problema non fosse specifico di MySQL, abbiamo eseguito lo stesso test su RDS PostgreSQL. I risultati sono stati identici:

• Gli aggiornamenti che portavano una riga a soddisfare la condizione del filtro non venivano replicati nella tabella di destinazione.
• Questo conferma che il problema non dipende dallo specifico database, ma è una limitazione del modo in cui DMS gestisce i filtri sulle colonne durante il CDC.