Migrazione del database relazionale al Data Lake S3 tramite AWS DMS, Parte I

Il servizio di migrazione dei database di AWS è un servizio cloud che migra database relazionali, database NoSQL, data warehouse e tutti gli altri tipi di archivi dati nel cloud AWS o tra il cloud e le configurazioni on-premises in modo efficiente e sicuro. DMS supporta diversi tipi di database di origine e di destinazione come Oracle, MS SQL Server, MySQL, Postgres SQL, Amazon Aurora, AWS RDS, Redshift e S3, ecc.

Osservazioni durante la migrazione dei dati

Abbiamo lavorato alla progettazione e alla creazione di un data lake AWS S3 e un data warehouse in AWS Redshift con le fonti dati da on-premises per Oracle, MS SQL Server, MySQL, Postgres SQL e MongoDB per i database relazionali. Abbiamo utilizzato AWS DMS per il caricamento iniziale completo e il trasferimento incrementale giornaliero dei dati da queste fonti in AWS S3. 

Con questa serie di post, desidero spiegare le varie sfide affrontate durante la effettiva migrazione dei dati con diversi database relazionali.

1. Data di Modifica Non Popolata Correttamente alla Fonte

AWS DMS viene utilizzato per il caricamento completo e la cattura dei dati modificati dai database di origine. AWS DMS cattura i record modificati basandosi sui log delle transazioni, ma una colonna di data di modifica aggiornata correttamente può aiutare ad applicare la logica di deduplicazione ed estrarre il record modificato più recente per una riga data nel target in S3.

Nel caso in cui i dati modificati non siano disponibili per una tabella o non siano aggiornati correttamente, AWS DMS fornisce un’opzione di regole di trasformazione per aggiungere una nuova colonna durante l’estrazione dei dati dal database di origine. Qui, l’intestazione AR_H_CHANGE_SEQ aiuta ad aggiungere una nuova colonna con un valore come numero univoco incrementale dal database di origine, che consiste in un timestamp e un numero di auto-incremento.

L’esempio di codice seguente aggiunge una nuova colonna come DMS_CHANGE_SEQ al target, che ha un numero univoco incrementale dal database di origine. Si tratta di un numero univoco di 35 cifre con le prime 16 cifre per il timestamp e le successive 19 cifre per il numero di record incrementato dal database. 

{

    "rule-type": "transformation",

    "rule-id": "2",

    "rule-name": "2",

    "rule-target": "column",

    "object-locator": {

        "schema-name": "%",

        "table-name": "%"

    },

    "rule-action": "add-column",

    "value": "DMS_CHANGE_SEQ",

    "expression": "$AR_H_CHANGE_SEQ",

    "data-type": {

        "type": "string",

        "length": 100

    }

}

2. Abilitazione del Logging Supplementare per Oracle come Origine

Per Oracle come database di origine, per catturare i cambiamenti in corso, AWS DMS necessita del logging supplementare minimo abilitato sul database di origine. Di conseguenza, ciò includerà informazioni e colonne aggiuntive nei redo log per identificare i cambiamenti alla sorgente.

Il logging supplementare può essere abilitato per chiavi primarie, chiavi univoche, insiemi di colonne o tutte le colonne. Il logging supplementare per tutte le colonne cattura tutte le colonne delle tabelle nel database di origine e aiuta a sovrascrivere i record completi nel livello target di AWS S3.

La registrazione supplementare di tutte le colonne aumenterà la dimensione dei log di redo, poiché tutte le colonne per la tabella vengono registrate nei log. È necessario configurare i log di redo e di archivio di conseguenza per considerare le informazioni aggiuntive in essi.

3. Larghezza di banda di rete tra i database sorgente e target

Il caricamento completo iniziale dalle fonti on-premises per Oracle, MS SQL Server, ecc., ha funzionato bene e anche la cattura dei dati modificati, per la maggior parte del tempo.

C’era un numero moderato di transazioni per la maggior parte del giorno in un determinato mese, tranne per il processo di fine giornata lavorativa, quotidianamente, dopo la mezzanotte e le attività di fine mese. Abbiamo osservato che i compiti di migrazione DMS erano fuori sincronizzazione o falliti durante questo periodo.

Abbiamo esaminato le metriche delle istanze sorgente, target e di replicazione nei log e abbiamo trovato le seguenti osservazioni:

• CDCLatencySource – il divario, in secondi, tra l’ultimo evento catturato dall’endpoint sorgente e il timestamp attuale del sistema dell’istanza AWS DMS.
• CDCIncomingchanges – il numero totale di eventi di cambiamento in un dato momento che sta aspettando di essere applicato al target. Questo aumenta da zero a migliaia durante le attività di riconciliazione nelle prime ore del mattino.
• CDCLatencySource – il divario, in secondi, tra l’ultimo evento catturato dal punto di origine e il timestamp di sistema attuale dell’istanza AWS DMS. Questo aumenta da zero a qualche migliaio fino a 10-12K secondi durante le attività di riconciliazione quotidiana post-mezzanotte. Questo valore è arrivato fino a 40K durante le attività di fine mese.

Dopo un’ulteriore analisi dei log e della revisione di altre metriche, abbiamo osservato che:

Le metriche AWS DMS NetworkReceiveThroughput servono per comprendere il traffico in arrivo sull’istanza di replica DMS per entrambi i database del cliente e il traffico DMS. Queste metriche aiutano a comprendere eventuali problemi legati alla rete tra il database di origine e l’istanza di replica DMS.

È stato osservato che il throughput di ricezione della rete era fino a 30MB/s, cioè 250Mb/s, a causa della connessione VPN tra l’origine e AWS, che era condivisa anche per altre applicazioni.

La conclusione finale di questo problema è che la connettività tra i database di origine e di destinazione è fondamentale per una migrazione dati riuscita. È necessario garantire una larghezza di banda sufficiente tra i database di origine in locale o di altre origini cloud e l’ambiente AWS prima della effettiva migrazione dei dati.

1. Un tunnel VPN come AWS Site-to-Site VPN o Oracle Cloud Infrastructure (OCI) Site-to-Site VPN (Oracle AWS) può fornire un throughput fino a 1.25 Gbps. Questo sarebbe sufficiente per la migrazione di tabelle di piccole dimensioni o tabelle con meno traffico DML.
2. Per migrazioni di grandi quantità di dati con transazioni pesanti al secondo sulle tabelle, si dovrebbe considerare AWS Direct Connect. Fornisce un’opzione per creare una connessione privata dedicata con supporto per larghezza di banda di 1 Gbps, 10 Gbps, ecc.

Conclusione

Questa è la Parte I della serie multipla per le migrazioni di basi di dati relazionali utilizzando AWS DMS e le relative soluzioni implementate. La maggior parte di queste sfide menzionate in questa serie potrebbero verificarsi durante il processo di migrazione del database e queste soluzioni possono essere consultate.