Bonnes pratiques pour AWS Database Migration Service

Pour utiliser AWS Database Migration Service (AWS DMS) plus efficacement, consultez les recommandations de cette section sur la méthode de migration de données la plus efficace.

Planification de la migration pour AWS Database Migration Service

Lors de la planification d'une migration de base de données à l'aide de AWS Database Migration Service, tenez compte des éléments suivants :

• Pour connecter vos bases de données source et cible à une instance de réplication AWS DMS, vous devez configurer un réseau. Pour ce faire, il suffit de connecter deux ressources AWS dans le même cloud privé virtuel (VPC) que votre instance de réplication. Il peut s'agir de configurations plus complexes telles que la connexion d'une base de données sur site à une instance de base de données Amazon RDS via un réseau privé virtuel (VPN). Pour plus d’informations, consultez Configurations réseau pour la migration de base de données.

• Points de terminaison sources et cibles : vous devez connaître les informations et les tables de la base de données source qui doivent être migrées vers la base de données cible. AWS DMS prend en charge la migration de schéma de base, y compris la création des tables et des clés primaires. Toutefois, AWS DMS ne crée pas automatiquement d'index secondaires, de clés étrangères, de comptes d'utilisateur, etc., dans la base de données cible. Selon vos moteurs de base de données source et cible, vous devrez peut-être configurer une journalisation supplémentaire ou modifier d'autres paramètres pour une base de données source ou cible. Pour plus d’informations, consultez Sources pour la migration des données et Cibles pour la migration des données.

• Migration de schéma et de code : AWS DMS n'effectue pas de conversion de schéma ni de code. Vous pouvez utiliser des outils tels qu'Oracle SQL Developer, MySQL Workbench ou pgAdmin III pour convertir votre schéma. Pour convertir un schéma existant en un moteur de base de données différent, vous pouvez utiliser l'AWS Schema Conversion Tool (AWS SCT). Il peut créer un schéma cible et générer et créer un schéma entier : tables, index, vues, etc. Vous pouvez également utiliser cet outil pour convertir des formats PL/SQL ou TSQL en PgSQL et autres. Pour plus d'informations sur AWS SCT, consultez le Guide de l'utilisateur AWS SCT.

• Types de données non pris en charge : veillez à pouvoir convertir les types de données sources en types de données équivalents pour la base de données cible. Pour plus d'informations sur les types de données pris en charge, consultez la section relative à la source ou à la cible pour votre magasin de données.

• Résultats des scripts d'assistance au diagnostic : lorsque vous planifiez votre migration, nous vous recommandons d'exécuter des scripts d'assistance au diagnostic. Les résultats de ces scripts vous permettront de trouver des informations avancées sur les échecs potentiels de migration.

  Si un script d'assistance est disponible pour la base de données, téléchargez-le à l'aide du lien figurant dans la rubrique du script correspondant dans la section suivante. Après avoir vérifié et examiné le script, vous pouvez l'exécuter conformément à la procédure décrite dans la rubrique relative au script dans votre environnement local. Lorsque l'exécution du script est terminée, vous pouvez passer en revue les résultats. Nous vous recommandons d'exécuter ces scripts comme première étape de tout effort de résolution des problèmes. Les résultats peuvent être utiles lorsque vous travaillez avec une équipe AWS Support. Pour plus d’informations, consultez Utilisation de scripts d'aide au diagnostic dans AWS DMS.

• Évaluations de prémigration : une évaluation de prémigration évalue les composants spécifiques d'une tâche de migration de base de données et vous aidera à identifier les problèmes susceptibles d'empêcher une tâche de migration de s'exécuter comme prévu. Cette évaluation vous permet d'identifier les problèmes potentiels avant d'exécuter une tâche nouvelle ou modifiée. Pour plus d'informations sur l'utilisation des évaluations de prémigration, consultez Activation et utilisation des évaluations de prémigration pour une tâche.

Conversion de schémas

AWS DMS n'effectue pas de conversion de schéma ou de code. Si vous souhaitez convertir un schéma existant en un moteur de base de données différent, vous pouvez utiliserAWS SCT. AWS SCT convertit vos objets, tables, index, vues et déclencheurs sources, ainsi que d'autres objets système au format DDL (Data Definition Language) cible. Vous pouvez également utiliser AWS SCT pour convertir la majeure partie de votre code d'application, comme PL/SQL ou TSQL, vers le langage cible équivalent.

Vous pouvez obtenir AWS SCT en le téléchargeant gratuitement à partir d'AWS. Pour plus d'informations sur AWS SCT, consultez le Guide de l'utilisateur AWS SCT.

Si vos points de terminaison source et cible se trouvent sur le même moteur de base de données, vous pouvez utiliser des outils tels qu'Oracle SQL Developer, MySQL Workbench ou PgAdmin 4 pour déplacer votre schéma.

Examen de la documentation publique d'AWS DMS

Nous vous recommandons vivement de consulter les pages de la documentation publique d'AWS DMS pour vos points de terminaison sources et cibles avant votre première migration. Cette documentation peut vous aider à identifier les conditions préalables à la migration et à comprendre les limitations actuelles avant de commencer. Pour plus d’informations, consultez Utilisation des points de terminaison AWS DMS.

Pendant la migration, la documentation publique peut vous aider à résoudre les éventuels problèmes liés à AWS DMS. Les pages de la documentation portant sur la résolution des problèmes peuvent vous aider à résoudre les problèmes courants en utilisant à la fois AWS DMS et les bases de données de point de terminaison sélectionnées. Pour plus d’informations, consultez Résolution des problèmes de migration dans AWS Database Migration Service.

Exécution d'une preuve de concept

Pour mieux détecter les problèmes liés à votre environnement dans les premières phases de la migration de la base de données, nous vous recommandons d'effectuer un petit test de migration. Cela peut également vous aider à définir une chronologie de migration plus réaliste. En outre, vous devrez peut-être effectuer un test de migration complet pour mesurer si AWS DMS peut gérer le débit de la base de données sur votre réseau. Pendant ce temps, nous vous recommandons de comparer et d'optimiser votre chargement complet initial et la réplication continue. Cela peut vous aider à comprendre la latence de votre réseau et à évaluer les performances globales.

À ce stade, vous avez également la possibilité de comprendre votre profil de données et la taille de la base de données, notamment les éléments suivants :

• Combien de tables ont une taille élevée, moyenne et réduite.

• Comment AWS DMS gère les conversions de types de données et de jeux de caractères.

• Combien de tables comportent des colonnes d'objets volumineux (LOB).

• Le temps nécessaire pour effectuer un test de migration.

Améliorer les performances d'une migration AWS DMS

Un certain nombre de facteurs affectent les performances de votre migration AWS DMS :

• Disponibilité des ressources sur la source.

• Débit du réseau disponible.

• Capacité des ressources du serveur de réplication.

• Capacité de la cible à ingérer les modifications.

• Type et distribution des données sources.

• Nombre d'objets à migrer.

Vous pouvez améliorer les performances en utilisant tout ou partie des bonnes pratiques mentionnées ci-après. La possibilité ou non d'utiliser ces pratiques dépend de votre cas d'utilisation spécifique. Vous pouvez trouver certaines limitations ci-dessous :

Provisionnement d'un serveur de réplication approprié

AWS DMS est un service géré qui s'exécute sur une instance Amazon EC2. Ce service se connecte à la base de données source, lit les données sources, formate les données en vue de leur consommation par la base de données cible et charge les données dans la base de données cible.

La majeure partie de ce traitement se passe dans la mémoire. Cependant, les transactions importantes peuvent nécessiter une mise en mémoire tampon sur disque. Les transactions mises en cache et les fichiers journaux sont également écrits sur le disque. Vous découvrirez dans les sections suivantes les éléments à prendre en compte lorsque vous choisissez votre serveur de réplication.

CPU

AWS DMS a été conçu pour des migrations hétérogènes, mais il prend également en charge les migrations homogènes. Pour effectuer une migration homogène, convertissez d'abord chaque type de données source vers le type de données AWS DMS équivalent. Convertissez ensuite chaque type de données AWS DMS vers le type de données cible. Vous trouverez des références relatives à ces conversions pour chaque moteur de base de données dans le Guide de l'utilisateur AWS DMS.

Pour qu'AWS DMS effectue ces conversions de manière optimale, le CPU doit être disponible au moment des conversions. La surcharge du CPU et le manque de ressources de CPU peuvent ralentir les migrations, ce qui peut entraîner d'autres effets secondaires.

Classe d'instances de réplication

Certaines des plus petites classes d'instance sont suffisantes pour tester le service ou effectuer de petites migrations. Si votre migration implique un grand nombre de tables, ou si vous prévoyez d'exécuter plusieurs tâches de réplication simultanées, envisagez d'utiliser une des instances les plus grandes. Une instance plus grande peut être une bonne idée car le service consomme une quantité importante de mémoire et de CPU.

Les instances de type T2 ont été conçues pour offrir des performances de référence modérées et la possibilité d'émettre en rafale pour atteindre des performances nettement supérieures si votre charge de travail l'exige. Elles sont prévues pour des charges de travail qui n'utilisent pas souvent ou de manière continue l'intégralité de la capacité de CPU, mais qui ont parfois besoin d'émettre en rafale. Les instances T2 conviennent parfaitement aux charges de travail à usage général, telles que les serveurs web, les environnements de développement et les petites bases de données. Si vous résolvez les problèmes liés à une migration lente et que vous utilisez un type d'instance T2, vérifiez la métrique hôte d'utilisation de CPU. Elle peut vous indiquer si vous dépassez la référence de ce type d'instance.

Les classes d'instances C4 ont été conçues de façon à proposer le plus haut niveau de performances de processeur pour les charges de travail informatiques intensives. Elles offrent des performances nettement supérieures en termes de nombre de paquets par seconde (PPS), et réduisent l'instabilité et la latence réseau. AWS DMS peut nécessiter une utilisation intensive de CPU, en particulier lors de migrations et de réplications hétérogènes, telles que la migration d'Oracle vers PostgreSQL. Les instances C4 peuvent être un choix judicieux pour ces situations.

Les classes d'instances R4 sont optimisées pour la mémoire pour les charges de travail consommatrices de mémoire. Les migrations et réplications continues des systèmes de transactions à haut débit utilisant AWS DMS peuvent parfois consommer de grandes quantités de ressources de CPU et de mémoire. Les instances R4 incluent davantage de mémoire par vCPU.

Prise en charge d'AWS DMS pour les classes d'instances R5 et C5

Les classes d'instances R5 sont des instances à mémoire optimisée conçues pour fournir des performances rapides pour les charges de travail qui traitent des jeux de données volumineux en mémoire. Les migrations et réplications continues des systèmes de transactions à haut débit utilisant AWS DMS peuvent parfois consommer de grandes quantités de ressources de CPU et de mémoire. Les instances R5 fournissent 5 % de mémoire supplémentaire par vCPU par rapport aux instances R4, et les instances de plus grande taille fournissent 768 Gio de mémoire. En outre, les instances R5 offrent une amélioration de 10 % du prix par Gio et une augmentation d'environ 20 % des performances de CPU par rapport aux instances R4.

Les classes d'instances C5 sont optimisées pour les charges de travail intensives en termes de calcul et offrent des performances élevées et rentables à un faible ratio prix/calcul. Elles améliorent considérablement les performances du réseau. L'adaptateur réseau élastique (ENA) fournit aux instances C5 jusqu'à 25 Gbit/s de bande passante réseau et jusqu'à 14 Gbit/s de bande passante dédiée à Amazon EBS. AWS DMS peut nécessiter une utilisation intensive de CPU, en particulier lors de migrations et de réplications hétérogènes, telles que la migration d'Oracle vers PostgreSQL. Les instances C5 peuvent être un choix judicieux pour de telles situations.

Stockage

En fonction de la classe d'instances, votre serveur de réplication est fourni avec un stockage de données de 50 Go ou 100 Go. Ce stockage est utilisé pour les fichiers journaux et toutes les modifications mises en cache collectées pendant le chargement. Si votre système source est occupé ou accepte des transactions importantes, vous devrez peut-être augmenter votre capacité de stockage. Si vous exécutez plusieurs tâches sur le serveur de réplication, vous pouvez également avoir besoin d'une augmentation de la capacité de stockage. Toutefois, la quantité par défaut est généralement suffisante.

Tous les volumes de stockage dans AWS DMS sont des disques durs à état solide (SSD) GP2 ou à usage général. Les volumes GP2 sont dotés d'une performance de base de trois opérations d'E/S par seconde (IOPS), avec la capacité d'émettre en rafale jusqu'à 3 000 IOPS sur la base de crédits. En règle générale, vérifiez les métriques ReadIOPS et WriteIOPS pour l'instance de réplication. Assurez-vous que la somme de ces valeurs ne dépasse pas les performances de base pour ce volume.

Multi-AZ

Le choix d'une instance multi-AZ peut protéger votre migration contre les défaillances de stockage. La plupart des migrations sont transitoires et ne sont pas destinées à s'exécuter pendant de longues périodes. Si vous utilisez AWS DMS à des fins de réplication continue, le choix d'une instance multi-AZ peut améliorer votre disponibilité en cas de problème de stockage.

Lorsque vous utilisez une seule instance de réplication AZ ou multi-AZ pendant un CHARGEMENT COMPLET et qu'un basculement ou un remplacement d'hôte se produit, la tâche de chargement complet est censée échouer. Vous pouvez redémarrer la tâche à partir du point de défaillance pour les tables restantes qui ne sont pas terminées ou qui présentent un état d'erreur.

Chargement de plusieurs tables en parallèle

Par défaut, AWS DMS charge huit tables à la fois. Vous pouvez voir une amélioration des performances en augmentant ce nombre légèrement lorsque vous utilisez un serveur de réplication très volumineux, par exemple un dms.c4.xlarge ou une instance plus grande. Cependant, à un moment donné, l'augmentation de ce parallélisme réduit les performances. Si votre serveur de réplication est relativement petit, comme un dms.t2.medium, nous vous recommandons de réduire le nombre de tables chargées en parallèle.

Pour modifier ce nombre dans la AWS Management Console, ouvrez la console, choisissez Tâches, choisissez de créer ou modifier une tâche, puis choisissez Paramètres avancés. Sous Tuning Settings (Paramètres de réglage), modifiez l'option Maximum number of tables to load in parallel (Nombre maximal de tables à charger en parallèle).

Pour modifier ce nombre à l'aide d'AWS CLI, modifiez le paramètre MaxFullLoadSubTasks sous TaskSettings.

Utilisation du chargement complet en parallèle

Vous pouvez utiliser un chargement parallèle à partir de sources Oracle, Microsoft SQL Server, MySQL, Sybase et IBM Db2 LUW sur la base de partitions et de sous-partitions. Cela peut réduire la durée globale du chargement complet. En outre, lors de l'exécution d'une tâche de migration AWS DMS, vous pouvez accélérer la migration de tables volumineuses ou partitionnées. Pour ce faire, divisez la table en segments et chargez les segments en parallèle dans la même tâche de migration.

Pour utiliser un chargement parallèle, créez une règle de mappage de tables de type table-settings avec l'option parallel-load. Dans la règle table-settings, spécifiez les critères de sélection de la ou des tables que vous souhaitez charger en parallèle. Pour spécifier les critères de sélection, définissez l'élément type pour parallel-load sur l'une des valeurs suivantes :

• partitions-auto

• subpartitions-auto

• partitions-list

• ranges

• none

Pour plus d'informations sur ces paramètres, consultez Règles des paramètres de table et de collection et opérations.

Utilisation d'index, de déclencheurs et de contraintes d'intégrité référentielle

Les index, les déclencheurs et les contraintes d'intégrité référentielle peuvent affecter vos performances de migration et provoquer l'échec de votre migration. La manière dont ces éléments affectent la migration dépend du fait que votre tâche de réplication soit une tâche de chargement complet ou une tâche de réplication continue (capture des données de modification ou CDC).

Pour une tâche de chargement complet, nous vous recommandons de supprimer les index de clé primaire, les index secondaires, les contraintes d'intégrité référentielle et les déclencheurs DML (Data Manipulation Language). Vous pouvez aussi retarder leur création jusqu'à ce que les tâches de chargement complet soient terminées. Vous n'avez pas besoin des index au cours d'une tâche de chargement complet et les index occasionnent des frais de maintenance s'ils sont présents. Étant donné que la tâche de chargement complet charge des groupes de tables en une seule fois, les contraintes d'intégrité référentielle sont violées. De même, l'insertion, la mise à jour et la suppression de déclencheurs peuvent entraîner des erreurs, par exemple, si une insertion de ligne est déclenchée pour une table préalablement chargée en bloc. D'autres types de déclencheurs affectent également les performances en raison du traitement supplémentaire qu'ils entraînent.

Si vos volumes de données sont relativement petits et si le temps de migration supplémentaire ne vous pose pas de problème, vous pouvez créer des index de clé primaire et des index secondaires avant une tâche de chargement complet. Désactivez toujours les contraintes d'intégrité référentielle et les déclencheurs.

Pour une tâche de chargement complet + CDC, nous vous recommandons d'ajouter les index secondaires avant la phase CDC. Comme AWS DMS utilise la réplication logique, veillez à ce que les index secondaires qui prennent en charge les opérations DML soient en place pour empêcher les analyses de tables complètes. Vous pouvez suspendre la tâche de réplication avant la phase CDC afin de construire des index et de créer des contraintes d'intégrité référentielle avant de redémarrer la tâche.

Vous devez activer les déclencheurs juste avant le basculement.

Désactivation des sauvegardes et de la journalisation des transactions

Lors de la migration vers une base de données Amazon RDS, il est judicieux de désactiver les sauvegardes et Multi-AZ sur la cible jusqu'à ce que vous soyez prêt à effectuer le basculement. De même, lors de la migration vers des systèmes autres qu'Amazon RDS, il est généralement judicieux de désactiver la journalisation sur la cible jusqu'à ce que le basculement soit terminé.

Utilisation de plusieurs tâches

L'utilisation de plusieurs tâches pour une seule migration peut permettre d'améliorer les performances. Si vous avez des ensembles de tables qui n'interviennent pas dans des transactions communes, vous pouvez peut-être diviser votre migration en plusieurs tâches. La cohérence transactionnelle est maintenue au sein d'une tâche. Il est donc important que les tables de tâches distinctes n'interviennent pas dans des transactions communes. De plus, chaque tâche lisant indépendamment le flux de transactions, veillez à ne pas trop utiliser la base de données source.

Vous pouvez utiliser plusieurs tâches pour créer des flux de réplication distincts. Vous pouvez ainsi paralléliser les lectures sur la source, les processus sur l'instance de réplication et les écritures dans la base de données cible.

Optimisation du traitement des modifications

Par défaut, AWS DMS traite les modifications en mode transactionnel, ce qui préserve l'intégrité transactionnelle. Si vous pouvez vous permettre des écarts temporaires dans l'intégrité transactionnelle, vous pouvez utiliser l'option d'application par lots optimisée à la place. Cette option regroupe efficacement les transactions et les applique par lots pour plus d'efficacité. L'utilisation de l'option d'application optimisée par lots enfreint presque toujours les contraintes d'intégrité référentielle. Nous vous recommandons donc de désactiver ces contraintes pendant le processus de migration et de les réactiver dans le cadre du processus de basculement.

Utilisation de votre propre serveur de noms sur site

Généralement, une instance de réplication AWS DMS utilise le résolveur DNS (Domain Name System) dans une instance Amazon EC2 pour résoudre les points de terminaison de domaine. Toutefois, vous pouvez utiliser votre propre serveur de noms sur site pour résoudre certains points de terminaison si vous utilisez Amazon Route 53 Resolver. Cet outil vous permet d'effectuer des requêtes entre des sites locaux et AWS en utilisant des points de terminaison entrants et sortants, des règles de transfert et une connexion privée. Les avantages de l'utilisation d'un serveur de noms sur site incluent une sécurité améliorée et une facilité d'utilisation derrière un pare-feu.

Si vous avez des points de terminaison entrants, vous pouvez utiliser des requêtes DNS provenant de sites locaux pour résoudre les domaines hébergés par AWS. Pour configurer les points de terminaison, attribuez des adresses IP dans chaque sous-réseau auquel vous souhaitez fournir un résolveur. Pour établir une connectivité entre votre infrastructure DNS sur site et AWS, utilisez AWS Direct Connect ou un réseau privé virtuel (VPN).

Les points de terminaison sortants se connectent à votre serveur de noms sur site. Le serveur de noms n'accorde l'accès qu'aux adresses IP incluses dans une liste d'autorisation et définies pour un point de terminaison sortant. L'adresse IP de votre serveur de noms est l'adresse IP cible. Lorsque vous choisissez un groupe de sécurité pour un point de terminaison sortant, choisissez le même groupe de sécurité que celui utilisé par l'instance de réplication.

Pour transférer des domaines sélectionnés vers le serveur de noms, utilisez des règles de transfert. Un point de terminaison sortant peut gérer plusieurs règles de transfert. La portée de la règle de transfert est votre cloud privé virtuel (VPC). En utilisant une règle de transfert associée à un VPC, vous pouvez provisionner une section logiquement isolée du Cloud AWS. À partir de cette section logiquement isolée, vous pouvez lancer des ressources AWS dans un réseau virtuel.

Vous pouvez configurer les domaines hébergés au sein de votre infrastructure DNS sur site en tant que règles de transfert conditionnel configurant des requêtes DNS sortantes. Lorsqu'une requête est effectuée sur l'un de ces domaines, les règles déclenchent une tentative de transfert des demandes DNS vers les serveurs qui ont été configurés avec ces règles. Encore une fois, une connexion privée via AWS Direct Connect ou un VPN est nécessaire.

Le schéma suivant illustre l'architecture de Route 53 Resolver.

Pour plus d'informations sur le résolveur DNS de Route 53, consultez Mise en route avec Route 53 Resolver dans le Guide du développeur Amazon Route 53.

Utilisation d'Amazon Route 53 Resolver avec AWS DMS

Vous pouvez créer un serveur de noms sur site pour permettre à AWS DMS de résoudre les points de terminaison à l'aide d'Amazon Route 53 Resolver.

Pour créer un serveur de noms sur site pour AWS DMS basé sur Route 53

1. Connectez-vous à AWS Management Console et ouvrez la console Route 53 à l'adresse https://console.aws.amazon.com/route53/.

2. Dans la console Route 53, choisissez la région AWS dans laquelle vous souhaitez configurer votre résolveur Route 53. Le résolveur Route 53 est spécifique à une région.

3. Choisissez le sens de requête : entrant, sortant ou les deux.

4. Fournissez votre configuration de requête entrante :

   1. Entrez un nom de point de terminaison et choisissez un VPC.

   2. Affectez un ou plusieurs sous-réseaux à partir du VPC (par exemple, choisissez-en deux pour assurer la disponibilité).

   3. Attribuez des adresses IP spécifiques à utiliser comme points de terminaison ou laissez le résolveur Route 53 les attribuer automatiquement.

5. Créez une règle pour votre domaine local afin que les charges de travail à l'intérieur du VPC puissent router les requêtes DNS vers votre infrastructure DNS.

6. Entrez une ou plusieurs adresses IP pour vos serveurs DNS sur site.

7. Soumettez votre règle.

Quand tout est créé, votre VPC est associé à vos règles entrantes et sortantes et peut commencer à router le trafic.

Pour plus d'informations sur le résolveur Route 53, consultez Mise en route avec Route 53 Resolver dans le Guide du développeur Amazon Route 53.

Migration des objets binaires volumineux (Large Binary Object, LOB)

En général, AWS DMS migre les données LOB en deux phases :

1. AWS DMS crée une nouvelle ligne dans la table cible et remplit cette ligne avec toutes les données à l'exception de la valeur LOB associée.

2. AWS DMS met à jour la ligne dans la table cible avec les données LOB.

Ce processus de migration pour les objets LOB exige pendant la migration que toutes les colonnes LOB de la table cible autorisent les valeurs Null. Il en est ainsi même si les colonnes LOB n'autorisent pas les valeurs Null dans la table source. Si AWS DMS crée les tables cible, elle définit les colonnes LOB sur le type nullable par défaut. Dans certains cas, vous pouvez créer les tables cibles à l'aide d'un autre mécanisme, tel que l'importation ou l'exportation. Dans ce cas, assurez-vous que les colonnes LOB autorisent les valeurs Null avant de commencer la tâche de migration.

Cette exigence n'a qu'une exception. Supposons que vous effectuez une migration homogène d'une source Oracle vers une cible Oracle et que vous choisissez Limited Lob mode (Mode LOB limité). Dans ce cas, la ligne entière est remplie en une seule fois, y compris les valeurs LOB. Dans ce cas, AWS DMS peut créer les colonnes LOB de la table cible avec des contraintes n'autorisant pas la valeur Null, si nécessaire.

Utilisation du mode LOB limité

AWS DMS utilise deux méthodes qui assurent un équilibre entre performances et commodité lorsque votre migration contient des valeurs LOB :

1. Le paramètre Limited LOB mode (Mode LOB limité) permet de migrer toutes les valeurs LOB jusqu'à une taille limite spécifiée par l'utilisateur (la valeur par défaut est 32 Ko). Les valeurs LOB supérieures à la taille limite doivent être migrées manuellement. Le paramètre Limited LOB mode (Mode LOB limité) (paramètre par défaut pour toutes les tâches de migration) offre généralement les meilleures performances. Toutefois, vous devez vous assurer que le paramètre Taille de LOB maximale est correctement défini. Définissez ce paramètre sur la plus grande taille de LOB pour toutes vos tables.

2. Le paramètre Full LOB mode (Mode LOB complet) migre toutes les données LOB de vos tables, quelle que soit leur taille. Le paramètre Full LOB mode (Mode LOB complet) permet de déplacer toutes les données LOB de vos tables, mais le processus peut avoir un impact significatif sur les performances.

Pour certains moteurs de base de données, tels que PostgreSQL, AWS DMS traite les types de données JSON comme des données LOB. Si vous avez choisi Mode LOB limité, assurez-vous que l'option Taille de LOB maximale est définie sur une valeur qui n'entraîne pas la troncation des données JSON.

AWS DMS prend en charge intégralement l'utilisation des types de données LOB (BLOB, CLOB et NCLOB). Les points de terminaison sources suivants prennent en charge intégralement les LOB :

• Oracle

• Microsoft SQL Server

• ODBC

Les points de terminaison cibles suivants prennent en charge intégralement les LOB :

• Oracle

• Microsoft SQL Server

Le point de terminaison cible suivant offre une prise en charge limitée des LOB. Vous ne pouvez pas utiliser une taille LOB illimitée pour ce point de terminaison cible.

• Amazon Redshift

• Amazon S3

Pour les points de terminaison prennent en charge les LOB intégralement, vous pouvez également définir une limite de taille pour les types de données LOB.

Amélioration des performances des objets LOB

Lors de la migration de données LOB, vous pouvez spécifier les différents paramètres d'optimisation LOB suivants.

Paramètres LOB par table

Les paramètres LOB par table vous permettent de remplacer les paramètres LOB au niveau d'une tâche pour une partie ou la totalité de vos tables. Pour ce faire, définissez lob-settings dans votre règle table-settings. Voici un exemple de table qui inclut des valeurs LOB élevées.

SET SERVEROUTPUT ON
CREATE TABLE TEST_CLOB
(
ID NUMBER,
C1 CLOB,
C2 VARCHAR2(4000)
);
DECLARE
bigtextstring CLOB := '123';
iINT;
BEGIN
WHILE Length(bigtextstring) <= 60000 LOOP
bigtextstring := bigtextstring || '000000000000000000000000000000000';
END LOOP;
INSERT INTO TEST_CLOB (ID, C1, C2) VALUES (0, bigtextstring,'AnyValue');
END;
/
SELECT * FROM TEST_CLOB;
COMMIT

Créez ensuite une tâche de migration et modifiez le traitement des objets LOB pour votre table à l'aide de la nouvelle règle lob-settings. La valeur bulk-max-siz détermine la taille de LOB maximale (Ko). Il est tronqué s'il dépasse la taille spécifiée.

{
	"rules": [{
			"rule-type": "selection",
			"rule-id": "1",
			"rule-name": "1",
			"object-locator": {
				"schema-name": "HR",
				"table-name": "TEST_CLOB"
			},
			"rule-action": "include"
		},
		{
			"rule-type": "table-settings",
			"rule-id": "2",
			"rule-name": "2",
			"object-locator": {
				"schema-name": "HR",
				"table-name": "TEST_CLOB"
			},
			"lob-settings": {
				"mode": "limited",
				"bulk-max-size": "16"
			}
		}
	]
}

Même si cette tâche AWS DMS est créée avec FullLobMode : true, les paramètres LOB par table indiquent à AWS DMS de tronquer les données LOB dans cette table particulière à 16 000. Vous pouvez examiner les journaux de tâches pour le confirmer.

721331968: 2018-09-11T19:48:46:979532 [SOURCE_UNLOAD] W: The value of column 'C' in table
'HR.TEST_CLOB' was truncated to length 16384

Paramètres LOB en ligne

Lorsque vous créez une tâche AWS DMS, le mode LOB détermine la manière de traiter les objets LOB.

Avec le mode LOB complet et le mode LOB limité, chacun a ses avantages et ses inconvénients propres. Le mode LOB en ligne combine les avantages du mode LOB complet et du mode LOB limité.

Vous pouvez utiliser le mode LOB en ligne lorsque vous devez répliquer des objets LOB de petite taille et d'autres de grande taille, et que la plupart des objets LOB sont de petite taille. Lorsque vous choisissez cette option, pendant le chargement complet, la tâche AWS DMS transfère les petits objets LOB en ligne, ce qui est plus efficace. La tâche AWS DMS transfère les objets LOB volumineux en effectuant une recherche à partir de la table source.

Pendant le traitement des modifications, les objets LOB de petite et de grande taille sont répliqués en effectuant une recherche à partir de la table source.

Lorsque vous utilisez le mode LOB en ligne, la tâche AWS DMS vérifie toutes les tailles de LOB pour déterminer celles à transférer en ligne. Les objets LOB supérieurs à la taille spécifiée sont répliqués en mode LOB complet. Par conséquent, si vous savez que la plupart des objets LOB sont supérieurs au paramètre spécifié, il est préférable de ne pas utiliser cette option. Autorisez plutôt une taille de LOB illimitée.

Vous configurez cette option à l'aide d'un attribut dans les paramètres des tâches, InlineLobMaxSize, qui est disponible uniquement quand FullLobMode a pour valeur true. La valeur par défaut pour InlineLobMaxSize est 0 et la plage est de 1 à 102 400 kilo-octets (100 Mo).

Par exemple, vous pouvez utiliser les paramètres de tâche AWS DMS suivants. Dans ce cas, affecter à InlineLobMaxSize la valeur 5 entraîne le transfert en ligne de tous les objets LOB inférieurs ou égaux à 5 Kio (5 120 octets).

{
  "TargetMetadata": {
  "TargetSchema": "",
  "SupportLobs": true,
  "FullLobMode": true,
  "LobChunkSize": 64,
  "LimitedSizeLobMode": false,
  "LobMaxSize": 32,
  "InlineLobMaxSize": 5,
  "LoadMaxFileSize": 0,
  "ParallelLoadThreads": 0,
  "ParallelLoadBufferSize":0,
  "BatchApplyEnabled": false,
  "TaskRecoveryTableEnabled": false},
  . . .
}

Amélioration des performances en cas de migration de tables volumineuses à l'aide du filtrage des lignes

Pour améliorer les performances lors de la migration d'une table volumineuse, divisez la migration en plusieurs tâches. Pour diviser la migration en plusieurs tâches à l'aide du filtrage des lignes, utilisez une clé ou une clé de partition. Par exemple, si vous avez un ID de clé primaire entier compris entre 1 et 8 000 000, vous pouvez créer huit tâches à l'aide du filtrage de lignes et migrer 1 million d'enregistrements dans chacune des tâches.

Pour appliquer le filtrage des lignes dans la console :

1. Ouvrez la AWS Management Console.

2. Choisissez Tâches et créez une nouvelle tâche.

3. Choisissez l'onglet Mappages de table, puis développez Règles de sélection.

4. Choisissez Ajouter une nouvelle règle de sélection. Vous pouvez désormais ajouter un filtre de colonnes avec une condition d'infériorité ou d'égalité, de supériorité ou d'égalité, d'égalité, ou de plage entre deux valeurs. Pour plus d'informations sur le filtrage des colonnes, consultez Spécification des règles de sélection de table et de transformation à partir de la console.

Si vous avez une table partitionnée de grande taille qui est partitionnée par date, vous pouvez migrer les données en fonction de la date. Par exemple, supposons que vous avez une table partitionnée par mois, et que seules les données du mois en cours sont mises à jour. Dans ce cas, vous pouvez créer une tâche de chargement complet pour chaque partition mensuelle statique et créer une tâche de chargement complet + CDC pour la partition actuellement mise à jour.

Si votre table possède une clé primaire à colonne unique ou un index unique, vous pouvez demander à votre tâche AWS DMS de segmenter la table en utilisant un chargement parallèle de type plage pour charger les données en parallèle. Pour plus d’informations, consultez Règles des paramètres de table et de collection et opérations.

la réplication continue.

AWS DMS permet la réplication continue des données, en maintenant la synchronisation entre les bases de données source et cible. Il réplique uniquement une quantité limitée d'instructions de langage de définition de données (DDL). AWS DMS ne propage pas les éléments tels que les index, les utilisateurs, les privilèges, les procédures stockées et les autres modifications de base de données qui ne sont pas directement liées aux données de table.

Si vous envisagez d'utiliser la réplication continue, définissez l'option Multi-AZ quand vous créez votre instance de réplication. En choisissant Multi-AZ, vous obtenez la prise en charge de la haute disponibilité et du basculement pour l'instance de réplication. Toutefois, cette option peut avoir un impact sur les performances et ralentir la réplication lors de l'application des modifications au système cible.

Avant de mettre à niveau vos bases de données source et cible, nous vous recommandons d'arrêter toutes les tâches AWS DMS en cours d'exécution sur ces bases de données. Reprenez ces tâches une fois les mises à niveau terminées.

Au cours de la réplication continue, il est essentiel d'identifier la bande passante du réseau entre votre système de base de données source et votre instance de réplication AWS DMS. Assurez-vous que le réseau n'est pas à l'origine de goulots d'étranglement lors de la réplication continue.

Il est également important d'identifier le taux de génération de journaux de modifications et d'archivage par heure sur votre système de base de données source. Cela peut vous aider à comprendre le débit que vous pouvez obtenir lors d'une réplication continue.

Réduction de la charge sur votre base de données source

AWS DMS utilise certaines des ressources de votre base de données source. Lors d'une tâche de chargement complet, AWS DMS effectue une analyse complète de la table source pour chaque table traitée en parallèle. De plus, chaque tâche que vous créez dans le cadre d'une migration interroge la source pour connaître les modifications apportées dans le cadre du processus CDC. Pour qu'AWS DMS puisse effectuer le processus CDC pour certaines sources, telles qu'Oracle, vous pouvez être amené à augmenter la quantité de données écrites dans le journal des modifications de votre base de données.

Si vous constatez que vous surchargez la base de données source, réduisez le nombre de tâches ou de tables pour chaque tâche de la migration. Chaque tâche récupère les modifications source de manière indépendante et, par conséquent, le regroupement des tâches peut diminuer la charge de travail de capture des modifications.

Réduction des goulots d'étranglement sur la base de données cible

Pendant la migration, essayez de supprimer tous les processus qui se disputent les ressources d'écriture sur la base de données cible :

• Désactivez les déclencheurs inutiles.

• Désactivez les index secondaires lors du chargement initial et réactivez-les ultérieurement pendant la réplication continue.

• Avec les bases de données Amazon RDS, il est conseillé de désactiver les sauvegardes et le mode multi-AZ jusqu'au basculement.

• Lors de la migration vers des systèmes non-RDS, il est judicieux de désactiver toute journalisation sur la cible jusqu'au basculement.

Utilisation de la validation des données lors de la migration

Pour garantir que vos données ont été migrées avec précision de la source vers la cible, nous vous recommandons vivement d'utiliser la validation des données. Si vous activez la validation des données pour une tâche, AWS DMS commence à comparer les données de la source et celles de la cible immédiatement après la réalisation d'un chargement complet pour une table.

La validation de données fonctionne avec les bases de données suivantes lorsque AWS DMS les prend en charge en tant que points de terminaison source et cible :

• Oracle

• PostgreSQL

• MySQL

• MariaDB

• Microsoft SQL Server

• Amazon Aurora MySQL-Compatible Edition

• Amazon Aurora PostgreSQL-Compatible Edition

• IBM Db2 LUW

• Amazon Redshift

Pour plus d’informations, consultez AWS Validation des données DMS.

Surveillance de vos tâches AWS DMS à l'aide de métriques

Plusieurs options s'offrent à vous pour surveiller les métriques relatives à vos tâches à l'aide de la console AWS DMS :

Métriques d'hôte

Vous pouvez trouver les métriques d'hôte dans l'onglet CloudWatch Metrics pour chaque instance de réplication spécifique. Vous pouvez y surveillez si le dimensionnement de votre instance de réplication est approprié.

Métriques de tâches de réplication

Les métriques relatives aux tâches de réplication, y compris les modifications entrantes et validées, ainsi que le temps de latence entre l'hôte de réplication et les bases de données source/cible sont disponibles dans l'onglet CloudWatch des métriques pour chaque tâche en particulier.

Métriques de table

Vous pouvez trouver des métriques de table individuelles dans l'onglet Statistiques de table pour chaque tâche individuelle. Ces métriques incluent les nombres suivants :

• Lignes chargées au cours du chargement complet.

• Insertions, mises à jour et suppressions depuis le début de la tâche.

• Opérations DDL depuis le début de la tâche.

Pour plus d'informations sur la surveillance des métriques, consultez AWS DMSTâches de surveillance.

Événements et notifications

AWS DMS utilise Amazon SNS pour fournir des notifications lorsqu'un événement AWS DMS se produit, par exemple la création ou la suppression d'une instance de réplication. Vous pouvez utiliser ces notifications sous n'importe quelle forme prise en charge par Amazon SNS pour une région AWS. Il peut s'agir d'e-mails, de messages texte ou d'appels vers un point de terminaison HTTP.

Pour plus d’informations, consultez Utilisation des événements et des notifications Amazon SNS dans AWS Database Migration Service.

Utilisation du journal des tâches pour résoudre des problèmes de migration

Dans certains cas, AWS DMS peut rencontrer des problèmes pour lesquels des avertissements ou des messages d'erreur s'affichent uniquement dans le journal des tâches. En particulier, les problèmes de troncature des données ou de rejet de lignes en raison de violations de clé étrangère sont écrits uniquement dans le journal des tâches. Par conséquent, veillez à examiner le journal des tâches lorsque vous migrez une base de données. Pour consulter le journal des tâches, configurez Amazon dans CloudWatch le cadre de la création des tâches.

Pour plus d'informations, consultez la section Surveillance des tâches de réplication à l'aide d'Amazon CloudWatch.

Résolution des problèmes liés aux tâches de réplication à l'aide du voyage dans le temps

Pour résoudre les problèmes de migration AWS DMS, vous pouvez utiliser le voyage dans le temps. Pour plus d'informations sur le voyage dans le temps, consultez Paramètres de tâche de voyage dans le temps.

Lorsque vous utilisez le voyage dans le temps, tenez compte des considérations suivantes :

• Pour éviter de surcharger une instance de réplication DMS, activez le voyage dans le temps uniquement pour les tâches nécessitant un débogage.

• Lorsque vous utilisez le voyage dans le temps pour résoudre des problèmes liés à des tâches de réplication susceptibles de s'exécuter pendant plusieurs jours, surveillez les métriques des instances de réplication pour détecter les surcharges de ressources. Cette approche s'applique particulièrement dans les cas où des charges de transactions élevées s'exécutent sur les bases de données sources pendant de longues périodes. Pour en savoir plus, consultez AWS DMSTâches de surveillance.

• Lorsque le paramètre de tâche de voyage dans le temps EnableRawData a pour valeur true, l'utilisation de la mémoire des tâches pendant la réplication DMS peut être plus élevée que lorsque le voyage dans le temps n'est pas activé. Si vous activez le voyage dans le temps pendant de longues périodes, surveillez votre tâche.

• À l'heure actuelle, vous pouvez activer le voyage dans le temps seulement au niveau d'une tâche. Les modifications apportées à toutes les tables sont enregistrées dans les journaux de voyage dans le temps. Pour résoudre les problèmes liés à des tables spécifiques dans une base de données présentant un volume de transactions élevé, créez une tâche distincte.

Modification de l'utilisateur et du schéma pour une cible Oracle

Quand vous utilisez Oracle en tant que cible, AWS DMS migre les données vers le schéma détenu par l'utilisateur du point de terminaison cible.

Par exemple, supposons que vous migrez un schéma nommé PERFDATA vers un point de terminaison cible Oracle, et que le nom de l'utilisateur du point de terminaison cible est MASTER. AWS DMS se connecte à la cible Oracle en tant que MASTER et remplit le schéma MASTER avec les objets de base de données provenant de PERFDATA.

Pour remplacer ce comportement, fournissez une transformation de schéma. Par exemple, pour migrer les objets du schéma PERFDATA vers un schéma PERFDATA au niveau du point de terminaison cible, utilisez la transformation suivante.

{
    "rule-type": "transformation",
    "rule-id": "2",
    "rule-name": "2",
    "object-locator": {
        "schema-name": "PERFDATA"
    },
    "rule-target": "schema",
    "rule-action": "rename",
    "value": "PERFDATA"
}

Pour plus d'informations sur les transformations, consultez Spécification des règles de sélection de table et de transformation à l’aide de JSON.

Modification des espaces de table d'index et de table pour une cible Oracle

Lorsque vous utilisez Oracle en tant que cible, AWS DMS migre toutes les tables et tous les index vers l'espace de table par défaut de la cible. Par exemple, supposons que votre source est un moteur de base de données autre qu'Oracle. Toutes les tables et tous les index cibles sont migrés vers le même espace de table par défaut.

Pour remplacer ce comportement, fournissez les transformations d'espace de table correspondantes. Par exemple, supposons que vous souhaitez migrer des tables et des index vers des espaces de table de table et d'index dans la cible Oracle qui sont nommés après le schéma dans la source. Dans ce cas, vous pouvez utiliser des transformations similaires à ce qui suit : Ici, le schéma dans la source est nommé INVENTORY et les espaces de table d'index et de table correspondants dans la cible sont nommés INVENTORYTBL et INVENTORYIDX.

{
   "rule-type": "transformation",
   "rule-id": "3",
   "rule-name": "3",
   "rule-action": "rename",
   "rule-target": "table-tablespace",
   "object-locator": {
      "schema-name": "INVENTORY",
      "table-name": "%",
      "table-tablespace-name": "%"
   },
   "value": "INVENTORYTBL"
},
{
   "rule-type": "transformation",
   "rule-id": "4
   "rule-name": "4",
   "rule-action": "rename",
   "rule-target": "index-tablespace",
   "object-locator": {
      "schema-name": "INVENTORY",
      "table-name": "%",
      "index-tablespace-name": "%"
   },
   "value": "INVENTORYIDX"
}

Pour plus d'informations sur les transformations, consultez Spécification des règles de sélection de table et de transformation à l’aide de JSON.

Si Oracle est à la fois source et cible, vous pouvez conserver les affectations d'espaces de table d'index et de table existantes en définissant l'attribut de connexion supplémentaire de la source Oracle, enableHomogenousTablespace=true. Pour plus d’informations, consultez Paramètres du point de terminaison lors de l'utilisation d'Oracle comme source pour AWS DMS.

Mise à niveau d'une version d'instance de réplication

AWS publie régulièrement de nouvelles versions du logiciel de moteur de réplication AWS DMS avec de nouvelles fonctionnalités et améliorations des performances. Chaque version du logiciel de moteur de réplication a son propre numéro de version. Il est essentiel de tester la version existante de votre instance de réplication AWS DMS exécutant une charge de travail de production avant de mettre à niveau votre instance de réplication vers une version ultérieure. Pour plus d'informations sur les mises à niveau des versions disponibles, consultez AWS DMSnotes de mise à jour.

Comprendre vos coûts de migration

AWS Database Migration Service vous permet de migrer des bases de données vers AWS facilement, en toute sécurité et à moindre coût. Vous ne payez que pour vos instances de réplication et pour tout stockage de journaux supplémentaire. Chaque instance de migration de base de données inclut un espace de stockage suffisant pour l'espace d'échange, les journaux de réplication et le cache de données pour la plupart des réplications. De plus, le transfert de données entrantes est gratuit.

Il se peut que vous ayez besoin de plus de ressources lors du chargement initial ou lors d'un pic de chargement. Vous pouvez surveiller de près l'utilisation des ressources des instances de réplication à l'aide des métriques CloudWatch. Vous pouvez ensuite augmenter ou réduire la taille des instances de réplication en fonction de l'utilisation.

Pour plus d'informations sur l'estimation de vos coûts de migration, consultez :

• Tarification AWS Database Migration Service

• AWS Pricing Calculator