Le service de migration de base de données AWS est un service cloud qui migre des bases de données relationnelles, des bases de données NoSQL, des entrepôts de données et tous les autres types de magasins de données dans le cloud AWS ou entre le cloud et les configurations sur site de manière efficace et sécurisée. DMS prend en charge plusieurs types de bases de données source et cible telles qu’Oracle, MS SQL Server, MySQL, Postgres SQL, Amazon Aurora, AWS RDS, Redshift et S3, etc.
Observations lors de la migration des données
Nous avons travaillé sur la conception et la création d’un lac de données AWS S3 et d’un entrepôt de données dans AWS Redshift avec les sources de données provenant d’installations sur site pour Oracle, MS SQL Server, MySQL, Postgres SQL et MongoDB pour les bases de données relationnelles. Nous avons utilisé AWS DMS pour le chargement complet initial et le transfert de données incrémentiel quotidien à partir de ces sources vers AWS S3.
Avec cette série de messages, je souhaite expliquer les différents défis rencontrés lors de la migration des données réelles avec différentes bases de données relationnelles.
1. Date de modification non correctement renseignée à la source
AWS DMS est utilisé pour le chargement complet et la capture des données modifiées à partir des bases de données source. AWS DMS capture les enregistrements modifiés en fonction des journaux de transactions, mais une colonne de date de modification correctement mise à jour peut aider à appliquer une logique de déduplication et extraire l’enregistrement modifié le plus récent pour une ligne donnée sur la cible dans S3.
Dans le cas où les données modifiées ne sont pas disponibles pour une table ou ne sont pas mises à jour correctement, AWS DMS propose une option de règles de transformation pour ajouter une nouvelle colonne lors de l’extraction des données de la base de données source. Ici, le AR_H_CHANGE_SEQ en-tête aide à ajouter une nouvelle colonne avec une valeur comme un numéro unique incrémenté de la base de données source, qui se compose d’un horodatage et d’un numéro auto-incrémenté.
L’exemple de code ci-dessous ajoute une nouvelle colonne comme DMS_CHANGE_SEQ à la cible, qui a un numéro unique incrémenté de la source. Il s’agit d’un numéro unique de 35 chiffres avec les 16 premiers chiffres pour l’horodatage et les 19 chiffres suivants pour le numéro d’identification de l’enregistrement incrémenté par la base de données.
{
"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. Activation de la Journalisation Supplémentaire pour Oracle en tant que Source
Pour Oracle en tant que base de données source, afin de capturer les modifications en cours, AWS DMS nécessite un minimum de journalisation supplémentaire à activer sur la base de données source. En conséquence, cela inclura des informations supplémentaires et des colonnes dans les journaux de réexécution pour identifier les changements à la source.
La journalisation supplémentaire peut être activée pour les clés primaires, les clés uniques, des ensembles de colonnes ou toutes les colonnes. La journalisation supplémentaire pour toutes les colonnes capture toutes les colonnes des tables dans la base de données source et aide à écraser les enregistrements complets dans la couche cible AWS S3.
La journalisation supplémentaire de toutes les colonnes augmentera la taille des journaux de réexécution, car toutes les colonnes de la table sont enregistrées dans les journaux. Il est nécessaire de configurer les journaux de réexécution et d’archivage en conséquence pour prendre en compte des informations supplémentaires.
3. Bande passante réseau entre les bases de données source et cible
Le chargement complet initial à partir des sources sur site pour Oracle, MS SQL Server, etc., a bien fonctionné, tout comme la capture des données modifiées, la plupart du temps.
Il y avait un nombre modéré de transactions la plupart du temps dans une journée donnée d’un mois, sauf pour le processus de fin de journée, quotidien, post-minuit et les activités de fin de mois. Nous avons constaté que les tâches de migration de DMS étaient désynchronisées ou échouaient pendant cette période.
Nous avons examiné les métriques des sources, des cibles et des instances de réplication dans les journaux et avons fait les observations suivantes :
- CDCLatencySource – l’écart, en secondes, entre le dernier événement capturé depuis le point de terminaison source et l’horodatage système actuel de l’instance AWS DMS.
- CDCIncomingchanges – le nombre total d’événements de modification à un moment donné qui attendent d’être appliqués à la cible. Cela augmente de zéro à des milliers pendant les activités de rapprochement tôt le matin.
- CDCLatencySource – l’écart, en secondes, entre le dernier événement capturé à partir du point de terminaison source et l’horodatage actuel du système de l’instance AWS DMS. Cela augmente de zéro à quelques milliers jusqu’à 10-12 000 secondes pendant les activités de rapprochement quotidien post-minuit. Cette valeur était jusqu’à 40 000 pendant les activités de fin de mois.
Après une analyse plus approfondie des journaux et de l’examen d’autres mesures, nous avons observé que :
Les mesures AWS DMS NetworkReceiveThroughput permettent de comprendre le trafic entrant sur l’instance de réplication DMS pour les bases de données clients et le trafic DMS. Ces mesures permettent de comprendre les problèmes liés au réseau, le cas échéant, entre la base de données source et l’instance de réplication DMS.
Il a été observé que le débit de réception du réseau était jusqu’à 30 Mo/s, soit 250 Mb/s, en raison de la connexion VPN entre la source et AWS, qui était également partagée pour d’autres applications.
La conclusion finale à ce problème est que la connectivité entre les bases de données source et cible est essentielle pour une migration de données réussie. Vous devez vous assurer qu’une bande passante suffisante entre les bases de données source sur site ou d’autres bases de données source cloud et l’environnement AWS est configurée avant la migration effective des données.
- Un tunnel VPN tel que le VPN de site à site AWS ou le VPN de site à site Oracle Cloud Infrastructure (OCI) (Oracle AWS) peut fournir un débit pouvant atteindre 1,25 Gbit/s. Cela serait suffisant pour une migration de petites tables ou de tables avec moins de trafic DML de migration.
- Pour les grandes migrations de données avec de lourdes transactions par seconde sur les tables, vous devriez envisager AWS Direct Connect. Il offre une option pour créer une connexion privée dédiée avec une bande passante de 1 Gbps, 10 Gbps, etc.
Conclusion
Il s’agit de la Partie I de la série en plusieurs parties pour les migrations de bases de données relationnelles en utilisant AWS DMS et les solutions mises en œuvre. La plupart de ces défis mentionnés dans cette série pourraient survenir pendant le processus de migration de base de données et ces solutions peuvent être consultées.
Source:
https://dzone.com/articles/relational-databases-migration-to-aws-environment