Quelles sont les meilleures pratiques à suivre lors de la migration d’une base de données RDS MySQL source vers une base de données RDS MySQL cible à l’aide d’AWS DMS ?

Courte description

Grâce à AWS DMS, vous pouvez migrer les données d’une banque de données source vers une banque de données cible. Ces deux banques de données sont appelées points de terminaison. Vous pouvez migrer entre des points de terminaison source et cible qui utilisent le même moteur de base de données, par exemple d’une base de données MySQL vers une autre base de données MySQL.

Bien qu’AWS DMS crée les objets de schéma cibles, il ne crée que le minimum d’objets dont il a besoin pour migrer les données efficacement depuis la source. AWS DMS crée donc des tables, des clés primaires et, dans certains cas, des index uniques, mais il ne crée pas d’objets tels que des index secondaires, des contraintes de clé non primaires ou des valeurs par défaut des données. Pour plus d’informations sur ce qui est migré par AWS DMS, consultez Vue d’ensemble d’AWS DMS.

Pré-créer les tables sur la base de données cible avant la migration

Pour conserver les définitions de données par défaut, pré-créez les tables dans la base de données cible avant la migration. Utilisez l’une des approches suivantes, en fonction du type de migration que vous effectuez :

• Pour les migrations homogènes telles que MySQL vers MySQL, utilisez les utilitaires du moteur de base de données natifs tels que mysqldump pour exporter les définitions de table. Ensuite, importez ces définitions de table dans la cible sans les données. Une fois les définitions de table créées, utilisez la tâche AWS DMS avec le mode de préparation de la table cible défini comme TRUNCATE_BEFORE_LOAD pour charger les données.
• Pour les migrations entre différents moteurs de base de données, utilisez l’outil de conversion des schémas AWS (AWS SCT). Vous pouvez également utiliser cette méthode pour les bases de données homogènes. AWS SCT se connecte à vos bases de données source et cible, puis convertit le schéma de base de données existant d\’un moteur de base de données à l’autre. Vous pouvez utiliser AWS SCT pour pré-créer des tables sur la base de données cible sans que les définitions de données par défaut ne soient modifiées. Ensuite, utilisez la tâche AWS DMS avec le mode de préparation de la table cible défini comme TRUNCATE_BEFORE_LOAD pour charger les données. Pour plus d’informations, consultez Conversion de votre schéma à l’aide d’AWS SCT.

Solution

Suivez les bonnes pratiques pour la migration de MySQL vers MySQL AWS DMS

Utilisez ces bonnes pratiques lorsque vous migrez des données d’une base de données source MySQL vers une base de données cible MySQL.

• Désactivez les sauvegardes et les journaux spécifiques à la base de données (tels que bin, general et audit) sur la base de données cible pendant la migration. Si nécessaire, vous pouvez les réactiver pour résoudre d’éventuels problèmes.
• Désactivez les déclencheurs, les autres tâches cron et les planificateurs d’événements sur la base de données cible pendant la migration.
• Évitez d’utiliser Multi-AZ sur la base de données Amazon RDS cible lors de la migration AWS DMS.
• Évitez d’appliquer tout autre trafic client externe à la base de données cible lors de la migration.
• Prévoyez de donner à votre instance de réplication AWS DMS et aux bases de données source et cible le processeur, la mémoire, le stockage et les IOPS nécessaires pour éviter la contention de ressources pendant la migration.
• Configurez la base de données source avec les conditions requises pour l\’utilisation de la capture des données modifiées (CDC) d\’AWS DMS avant la migration.
• Utilisez des paramètres LOB optimisés tels que le LOB limité et le LOB en ligne pour la migration.
• Si la base de données source contient de nombreuses tables avec une charge de travail importante, répartissez les tables en plusieurs tâches. Divisez les tables en fonction de leur taille dans la base de données source, du modèle de trafic des applications et de la présence de colonnes LOB. Si la table comporte de nombreuses colonnes LOB (TEXT ou JSON) avec un trafic d’écriture élevé sur la source, créez une tâche distincte pour la table. La cohérence transactionnelle est maintenue au sein d\’une tâche, il est donc important que les tables de tâches distinctes ne participent pas à des transactions communes.
• Utilisez le mécanisme de chargement complet en parallèle pour les tables sources volumineuses pour réduire le temps de migration. Pour plus d’informations, consultez la section Utilisation du chargement parallèle pour des tables, des vues et des collections spécifiques.
• Désactivez les contraintes de clé étrangère sur la table cible lors de la migration à chargement complet.
• Ajoutez un index secondaire sur la base de données cible avant de démarrer la phase de réplication CDC.
• L’utilisateur principal Amazon RDS ne dispose pas de privilèges de suppression et de recréation sur les tables de schéma par défaut. Évitez donc de migrer des tables de base de données ou de schéma par défaut depuis la source avec AWS DMS.
• Consultez la documentation sur l’Utilisation d’AWS DMS pour migrer des données de MySQL vers MySQL pour plus d\’informations sur les types de données qu’AWS DMS peut migrer avec succès.
• Testez votre charge de travail à l’aide de la méthode d’application CDC transactionnelle par défaut avant d’utiliser la méthode d’application CDC par lots. Pour plus d’informations, consultez Comment utiliser la fonctionnalité d’application DMS par lots pour améliorer les performances de la réplication CDC ?
• Testez la migration en utilisant les mêmes données de production sur un autre environnement de base de données QA/DEV avant de commencer la migration de production. Assurez-vous d’utiliser la même configuration AWS DMS lorsque vous effectuez la migration de production.

Pour plus d’informations, consultez Améliorer les performances d’une migration AWS DMS.

Utilisez la configuration et les méthodes recommandées sur vos bases de données source et cible

1. Pré-créez manuellement la table DDL dans les bases de données MySQL/PostgreSQL cibles. Ensuite, créez une tâche AWS DMS avec le mode de préparation de la cible défini comme DO_DOTHING/TRUNCATE pour migrer uniquement les données.

Exécutez cette commande pour faire un dump sans données de la base de données MySQL source :

mysqldump -h yourhostnameorIP -u root -p --no-data --skip-triggers --single-transaction --dbname > schema.sql

Cette commande vide la structure DDL de la source sans aucune donnée.

Ensuite, exécutez cette commande pour restaurer la structure DDL sur la cible :

mysql -u user -p -h yourhostnameorIP  database_name < schema.sql

Vous pouvez également autoriser AWS DMS à créer les tables sur la cible en utilisant le mode de préparation de cible « DROP AND CREATE ». Passez ensuite à l’étape 3 pour modifier le tableau et ajouter les objets manquants comme les index secondaires avant de reprendre la tâche pour la phase CDC.

Remarque : par défaut, AWS DMS crée la table sur la cible avec uniquement la clé primaire ou la clé unique. Il ne migre aucun autre objet vers la base de données MySQL cible.

2. Pendant le chargement complet, AWS DMS n’identifie pas les tables relationnelles avec clés étrangères. Les données sont chargées de manière aléatoire, le chargement de la table peut donc échouer si la vérification de clé étrangère est activée dans la base de données cible. Utilisez cet attribut de connexion supplémentaire (ECA) sur le point de terminaison MySQL cible pour désactiver les vérifications de clés étrangères pour cette session AWS DMS.

initstmt=SET FOREIGN_KEY_CHECKS=0;

Pour plus d\’informations, consultez Attributs de connexion supplémentaires pour AWS DMS lors de l’utilisation d’une base de données cible compatible MySQL.

3. Dans les paramètres JSON, configurez « arrêtez la tâche avant d’appliquer les modifications en cache » sur vrai et « arrêtez la tâche après avoir appliqué les modifications en cache » sur vrai.

"FullLoadSettings": {
    "TargetTablePrepMode": "TRUNCATE_BEFORE_LOAD"
    "CreatePkAfterFullLoad": false,
    "TransactionConsistencyTimeout": 600,
    "MaxFullLoadSubTasks": 8,
    "StopTaskCachedChangesNotApplied": true,   <--- set this to true
    "StopTaskCachedChangesApplied": true,    <--- set this to true
    "CommitRate": 50000,
}

Une fois le chargement complet terminé et avant d’appliquer les modifications mises en cache, la tâche s’arrête. Lorsque la tâche est arrêtée, créez les index de clé primaire et les index secondaires sur la cible.

Ensuite, reprenez la tâche car elle s’arrête à nouveau après avoir appliqué les modifications mises en cache. Ensuite, vérifiez les données migrées à l’aide de la sortie de validation AWS DMS ou manuellement avant de reprendre la tâche pour la phase de réplication CDC. En ne négligeant pas cette étape, vous pouvez identifier les problèmes et les résoudre avant de reprendre la réplication CDC.

4.    Dans les paramètres de la tâche de chargement complet, ajustez le paramètre commitRate pour accélérer le taux d\’extraction des données à partir de la source. La valeur par défaut est 10 000, ajustez donc ce paramètre lorsque vous migrez une grande quantité de données depuis la table source.

CommitRate=50000

Remarque : l’augmentation de commitRate peut affecter les performances. Veillez donc à contrôler et à disposer de suffisamment de mémoire dans l’instance de réplication.

5.    Ajoutez cet ECA sur le point de terminaison cible pour spécifier la taille maximale (en Ko) de tout fichier .csv utilisé pour transférer des données vers la base MySQL cible. La valeur par défaut est 32 768 Ko (32 Mo) et les valeurs possibles vont de 1 à 1 048 576 Ko (jusqu’à 1,1 Go).

maxFileSize=250000;

Remarque : lorsque vous utilisez une instance cible telle que MySQL, Aurora ou MariaDB pour le chargement complet, utilisez cette option pour permettre à AWS DMS de créer un fichier .csv en arrière-plan pour charger les données dans l’instance cible. Utilisez une valeur comprise entre 32 Mo et 1 Go. Mais pensez aussi à ce que votre instance cible peut gérer. Si plusieurs tâches chargent 1 Go de fichier .csv, cela peut entraîner une surcharge sur votre instance cible. Assurez-vous de disposer d’une instance dotée d’une puissance de calcul élevée sur la cible.

6.    Utilisez les paramètres LOB limités ou en ligne pour de meilleures performances.

Mode LOB limité : lorsque vous utilisez le mode LOB limité, vous spécifiez la taille maximale des données des colonnes LOB. Ceci permet à AWS DMS de pré-attribuer des ressources et d’appliquer les LOB en masse. Si la taille des colonnes LOB dépasse la taille que vous avez spécifiée dans la tâche, AWS DMS tronque les données. AWS DMS envoie ensuite des avertissements au fichier journal AWS DMS. L’utilisation du mode LOB limité améliore les performances, mais avant d’exécuter la tâche, vous devez identifier la taille maximale LOB des données dans la source. Ensuite, renseignez le paramètre Taille maximale LOB. Il est recommandé de vérifier que l’instance de réplication dispose d’une quantité de mémoire suffisante pour gérer la tâche.

Mode LOB en ligne : Lorsque vous utilisez le mode LOB en ligne, vous pouvez migrer les LOB sans tronquer les données ni ralentir les performances de votre tâche en répliquant les LOB de petite taille et ceux de grande taille. Tout d’abord, renseignez une valeur pour le paramètre InlineLobMaxSize qui est disponible uniquement lorsque Mode LOB complet est configuré sur vrai. La tâche AWS DMS transfère les LOB de petite taille en ligne, ce qui est plus efficace. Ensuite, AWS DMS migre les LOB dont la taille est supérieure à la taille spécifiée en mode LOB complet en effectuant une recherche à partir de la table source. Toutefois, le mode LOB en ligne fonctionne uniquement pendant la phase de chargement complet.

Important : vous devez renseigner InlineLobMaxSize lorsque vous spécifiez les paramètres de tâche de votre tâche.

Exécutez ces requêtes pour vérifier la taille du LOB, puis renseignez la taille maximale du LOB.

Répertoriez les tables contenant des colonnes LOB :

select tab.table_name,
count(*) as columns
from information_schema.tables as tab
inner join information_schema.columns as col
on col.table_schema = tab.table_schema
and col.table_name = tab.table_name
and col.data_type in ('blob', 'mediumblob', 'longblob',
'text', 'mediumtext', 'longtext')
where tab.table_schema = 'your database name'.  <---- enter database name here
and tab.table_type = 'BASE TABLE'
group by tab.table_name
order by tab.table_name;

Vérifiez la taille de la colonne LOB :

Select (max(length (<COL_NAME>))/(1024)) as “size in KB” from <TABLE_NAME>;

Vérifiez la taille des colonnes LOB de toutes les tables, puis renseignez la taille maximale dans Taille maximale LOB (K).

L’utilisation de l’option Taille maximale LOB (K) avec une valeur supérieure à 63 Ko affecte les performances d’un chargement complet configuré pour s’exécuter en mode LOB limité. Lors d’un chargement complet, AWS DMS alloue la mémoire en multipliant la valeur Taille maximale LOB (k) par le taux de validation. Ensuite, ce produit est multiplié par le nombre de colonnes LOB.

Lorsqu’AWS DMS ne peut pas pré-allouer cette mémoire, AWS DMS commence à consommer de la mémoire SWAP. Cela affecte les performances d’un chargement complet. Ainsi, si vous rencontrez des problèmes de performance lorsque vous utilisez le mode LOB limité, réduisez le taux de validation jusqu’à atteindre un niveau de performance acceptable. Vous pouvez également envisager d’utiliser le mode LOB en ligne pour les points de terminaison pris en charge après avoir vérifié la distribution LOB de la table.

Pour en savoir plus, consultez la section Configurer la prise en charge LOB pour les bases de données sources dans une tâche AWS DMS.

---

Informations connexes

Faire une migration de MySQL vers Amazon RDS avec AWS DMS

Procédure étape par étape pour la migration de base de données