Les meilleures pratiques pour AWS Database Migration Service

Pour utiliser AWS Database Migration Service (AWS DMS) le plus efficacement possible, consultez les recommandations de cette section sur le moyen le plus efficace de migrer vos données.

Planification de la migration pour AWS Database Migration Service

Lorsque vous planifiez une migration de base de données à l'aide de AWS Database Migration Service, tenez compte des points suivants :

• Pour connecter vos bases de données source et cible à une instance de AWS DMS réplication, 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 de plus amples informations, veuillez consulter Configurations réseau pour la migration de base de données.

• Points de terminaison source et cible : assurez-vous de savoir quelles informations et quelles tables de la base de données source 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 de tables et de clés primaires. Cependant, AWS DMS ne crée pas automatiquement d'index secondaires, de clés étrangères, de comptes 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 ou 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 vers un autre moteur de base de données, vous pouvez utiliser le 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 le AWS SCT, consultez le guide de AWS SCT l'utilisateur.

• 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 de plus amples informations, veuillez consulter 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 vers un autre moteur de base de données, vous pouvez utiliser AWS SCT. AWS SCT convertit vos objets source, tables, index, vues, déclencheurs et autres objets système au format DDL (Target Data Definition Language). Vous pouvez également l'utiliser AWS SCT pour convertir la majeure partie du code de votre application, tel que PL/SQL ou TSQL, dans le langage cible équivalent.

Vous pouvez l'obtenir AWS SCT en téléchargement gratuit sur AWS. Pour plus d'informations AWS SCT, consultez le guide de AWS SCT l'utilisateur.

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.

Révision de la documentation AWS DMS publique

Nous vous recommandons vivement de consulter les pages de documentation AWS DMS publiques de vos points de terminaison source et cible 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 de plus amples informations, veuillez consulter Utilisation des points de AWS terminaison DMS.

Pendant la migration, la documentation publique peut vous aider à résoudre les éventuels problèmes liés à AWS DMS. Les pages de résolution des problèmes de la documentation peuvent vous aider à résoudre les problèmes courants en utilisant à la fois les bases de données de points de terminaison AWS DMS et certaines bases de données sélectionnées. Pour de plus amples informations, veuillez consulter 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 exécuter un test de migration à grande échelle pour déterminer si vous AWS DMS pouvez gérer le débit de votre 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 par type de données et par jeu 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 AWS DMS migration

Plusieurs facteurs influent sur les performances de votre AWS DMS migration :

• 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 EC2 instance Amazon. 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 est conçu pour les 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 en un type de AWS DMS données é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 .

AWS DMS Pour effectuer ces conversions de manière optimale, le processeur 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. Ils permettent d'obtenir des performances de paquets par seconde (PPS) nettement supérieures, de réduire l'instabilité du réseau et de réduire la latence du réseau. AWS DMS peut nécessiter une utilisation intensive du processeur, 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 ou réplications continues de systèmes de transaction à haut débit AWS DMS peuvent parfois consommer de grandes quantités de processeur et de mémoire. Les instances R4 incluent davantage de mémoire par vCPU.

AWS DMS prise en charge des classes d'instance 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 ou réplications continues de systèmes de transaction à haut débit AWS DMS peuvent parfois consommer de grandes quantités de processeur 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. Elastic Network Adapter (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 du processeur, 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 contenus AWS DMS sont GP2 des disques SSD à usage général (). SSDs GP2 les volumes sont dotés d'une performance de base de trois opérations d'E/S par seconde (IOPS), avec la capacité d'atteindre 3 000 IOPS sur une base de crédit. 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 l'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 le AWS Management Console, ouvrez la console, choisissez Tâches, choisissez de créer ou de 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 du AWS CLI, modifiez le MaxFullLoadSubTasks paramètre sousTaskSettings.

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. Dans la mesure où elle AWS DMS utilise la réplication logique, assurez-vous que les index secondaires prenant en charge les opérations DML sont en place pour empêcher l'analyse complète des tables. 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 les processus changent en mode transactionnel, ce qui préserve l'intégrité des transactions. 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 AWS DMS réplication utilise le résolveur DNS (Domain Name System) d'une EC2 instance Amazon pour résoudre les points de terminaison du 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. Avec cet outil, vous pouvez 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 AWS les domaines hébergés. 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 approvisionner une section du cloud isolée de manière logique. AWS À partir de cette section isolée de manière logique, vous pouvez lancer AWS des ressources 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 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 résoudre les points de terminaison AWS DMS à l'aide de. Amazon Route 53 Resolver

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

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

2. Sur la console Route 53, choisissez la AWS région 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 d'objets binaires volumineux () LOBs

En général, la AWS DMS migration des données LOB se fait en deux phases :

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

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

Ce processus de migration LOBs nécessite que, pendant la migration, toutes les colonnes LOB de la table cible soient nullables. Il en est ainsi même si les colonnes LOB n'autorisent pas les valeurs Null dans la table source. S'il AWS DMS crée les tables cibles, il définit les colonnes LOB comme nullables 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 vous pouvez créer les colonnes LOB de la table cible avec des contraintes non nullables, si nécessaire.

Utilisation du mode LOB limité

AWS DMS utilise deux méthodes qui offrent 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 , traitent les types de données JSON comme. LOBs 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 fournit un support complet pour l'utilisation de types de données d'objets volumineux (BLOBs CLOBs,, et NCLOBs). 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 AWS DMS tâche est créée avecFullLobMode : true, les paramètres LOB par table indiquent de AWS DMS tronquer les données LOB de cette table en particulier à 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 AWS DMS tâche, le mode LOB détermine la manière dont elle LOBs est traitée.

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 intégré lorsque vous devez répliquer à la fois des fichiers petits et grands LOBs, et que la plupart d'entre eux sont de petite taille. LOBs Lorsque vous choisissez cette option, pendant le chargement complet, la AWS DMS tâche transfère le petit LOBs en ligne, ce qui est plus efficace. La AWS DMS tâche transfère le fichier volumineux LOBs en effectuant une recherche dans la table source.

Pendant le traitement des modifications, les modifications de petite et de grande envergure LOBs sont répliquées en effectuant une recherche dans la table source.

Lorsque vous utilisez le mode LOB en ligne, la AWS DMS tâche vérifie toutes les tailles de LOB pour déterminer celles à transférer en ligne. LOBs les tailles supérieures à la taille spécifiée sont répliquées en mode LOB complet. Par conséquent, si vous savez que la plupart d' LOBs entre eux 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 AWS DMS tâche suivants. Dans ce cas, le réglage InlineLobMaxSize sur une valeur de 5 entraîne le transfert en ligne de tous les fichiers LOBs inférieurs ou égaux à 5 KiB (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 le 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 ou un index unique à colonne unique, vous pouvez demander à votre AWS DMS tâche de segmenter la table en utilisant un chargement parallèle du type ranges pour charger les données en parallèle. Pour de plus amples informations, veuillez consulter Règles des paramètres de table et de collection et opérations.

la réplication continue.

AWS DMS assure la réplication continue des données, en synchronisant 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 en cours, il est essentiel d'identifier la bande passante réseau entre votre système de base de données source et votre instance de AWS DMS réplication. 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 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. AWS DMS Pour exécuter le CDC pour certaines sources, telles qu'Oracle, vous devrez peut-être 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 source et cible immédiatement après le chargement complet d'une table.

La validation des données fonctionne avec les bases de données suivantes partout où elles sont AWS DMS prises 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 de plus amples informations, veuillez consulter AWS Validation des données DMS.

Surveillance de vos AWS DMS tâches à 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 Surveillance des AWS tâches DMS.

Événements et notifications

AWS DMS utilise Amazon SNS pour fournir des notifications lorsqu'un AWS DMS événement 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 AWS région. Il peut s’agir d’e-mails, de messages texte ou d’appels vers un point de terminaison HTTP.

Pour de plus amples informations, veuillez consulter 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 vous pouvez rencontrer des problèmes pour lesquels des avertissements ou des messages d'erreur apparaissent 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 AWS DMS migration, vous pouvez utiliser Time Travel. 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 Surveillance des AWS tâches DMS.

• 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

Lorsque vous utilisez Oracle comme cible, AWS DMS migre les données vers le schéma appartenant à 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 comme cible, AWS DMS migre toutes les tables et tous les index vers le tablespace 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 de plus amples informations, veuillez consulter 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 du moteur de AWS DMS réplication, avec de nouvelles fonctionnalités et des améliorations de 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 Notes de mise à jour du DMS.

Comprendre vos coûts de migration

AWS Database Migration Service vous permet de migrer des bases de données vers des bases de données AWS facilement et en toute sécurité à faible 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 :

• AWS Database Migration Service tarification

• AWS Calculateur de prix