Bonnes pratiques relatives à AWS Database Migration Service - AWS Database Migration Service

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Bonnes pratiques relatives à 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 à unAWS DMSinstance de réplication, vous configurez un réseau. Cela peut être aussi simple que de connecter deuxAWSressources dans le même cloud privé virtuel (VPC) que votre instance de réplication. Il peut aller 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 source et cible— Vérifiez que vous savez quelles informations et tables de la base de données source doivent être migrées vers la base de données cible.AWS DMSprend en charge la migration de schéma de base, y compris la création de tables et de clés primaires. Cependant,AWS DMSne crée pas automatiquement d'index secondaires, de clés étrangères, de comptes utilisateur, etc., dans la base de données cible. Selon votre moteur de base de données source et cible, vous devrez peut-être configurer la 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 DMSn'effectue pas de conversion de schéma ou de code. Vous pouvez utiliser des outils tels qu'Oracle SQL Developer, MySQL Workbench et 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'outilAWS 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 leAWS SCT, voir leAWS SCTGuide de l'utilisateur.

  • Types de données non pris en charge— Assurez-vous que vous pouvez convertir les types de données source 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 source ou cible de votre magasin de données.

  • Résultats du script de prise en charge du— Lorsque vous planifiez votre migration, nous vous recommandons d'exécuter des scripts de prise en charge du diagnostic. Avec les résultats de ces scripts, vous pouvez trouver des informations préalables sur les échecs potentiels de migration.

    Si un script de support est disponible pour votre base de données, téléchargez-le à l'aide du lien de la rubrique de script correspondante 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 Script dans votre environnement local. Une fois l'exécution du script terminée, vous pouvez consulter les résultats. Nous vous recommandons d'exécuter ces scripts comme première étape de tout effort de dépannage. Les résultats peuvent être utiles lorsque vous travaillez avec unAWS Supportéquipe. Pour plus d'informations, consultez Utilisation des scripts de prise en charge du diagnostic dansAWS DMS.

  • Évaluations de prémigration— UNÉvaluation de prémigrationévalue les composants spécifiés d'une tâche de migration de base de données pour aider à identifier tout problème susceptible d'empêcher une tâche de migration de s'exécuter comme prévu. En utilisant cette évaluation, vous pouvez 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, consultezActivation 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 voulez convertir un schéma existant en un moteur de base de données différent, vous pouvez utiliser l'outilAWS SCT.AWS SCTconvertit vos objets, tables, index, vues, déclencheurs source et autres objets système au format DDL (Data Definition Language) cible. Vous pouvez également utiliserAWS SCTpour convertir la plupart de votre code d'application, comme PL/SQL ou TSQL, en langue cible équivalente.

Vous pouvez obtenirAWS SCTen téléchargement gratuit surAWS. Pour plus d'informations sur AWS SCT, consultez le Guide de l'utilisateur AWS SCT.

Si vos points de terminaison sources et cibles sont dans le même moteur de base de données, vous pouvez utiliser des outils tels qu'Oracle SQL Developer, MySQL Workbench ou PgAdmin4 pour déplacer votre schéma.

Examen duAWS DMSdocumentation publique

Nous vous recommandons fortement de passer par leAWS DMSpages de documentation publiques pour 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 limites actuelles avant de commencer. Pour plus d'informations, consultez Utilisation d'AWSPoints de terminaison DMS.

Lors de la migration, la documentation publique peut vous aider à résoudre tout problème lié àAWS DMS. Les pages de dépannage de la documentation peuvent vous aider à résoudre les problèmes courants à l'aide des deuxAWS DMSet des bases de données de points d'extrémité sélectionnées. Pour plus d'informations, consultez Résolution des problèmes liés aux tâches de migration AWS Database Migration Service.

Réalisation d'une démonstration de faisabilité

Pour vous aider à découvrir les problèmes liés à votre environnement lors des premières phases de la migration de votre base de données, nous vous recommandons d'effectuer une petite migration de test. Cela peut également vous aider à définir un calendrier de migration plus réaliste. En outre, vous devrez peut-être exécuter une migration de test à grande échelle pour déterminer siAWS DMSpeut 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 charge initiale complète 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 votre base de données, y compris les éléments suivants :

  • Combien de tables sont grandes, moyennes et petites.

  • CommentAWS DMSgère les conversions de types de données et de jeux de caractères.

  • Combien de tables comportent des colonnes LOB.

  • Combien de temps prennent le temps d'exécuter une migration de test.

Améliorer les performances d'une migration AWS DMS

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

  • les ressources disponibles sur la source.

  • le débit du réseau disponible.

  • la capacité des ressources du serveur de réplication.

  • la capacité de la cible à intégrer des modifications.

  • Type et distribution des données source.

  • 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é d'utiliser ces pratiques dépend de votre cas d'utilisation spécifique. Vous trouverez quelques limitations suivantes :

Provisionnement d'un serveur de réplication approprié

AWS DMSest 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 source, met en forme les données en vue de leur utilisation 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. Dans les sections suivantes, vous découvrirez ce que vous devez prendre en compte lorsque vous choisissez votre serveur de réplication.

CPU

AWS DMSest conçu pour les migrations hétérogènes, mais il soutient également des migrations homogènes. Pour effectuer une migration homogène, commencez par convertir chaque type de données source en son équivalentAWS DMSType de données. Convertissez ensuite chaqueAWS DMSsaisissez les données sur le type de données cible. Vous pouvez trouver des références pour ces conversions pour chaque moteur de base de données dans leAWS DMSGuide de l'utilisateur.

PourAWS DMSpour effectuer ces conversions de manière optimale, le processeur doit être disponible lorsque les conversions se produisent. La surcharge du processeur et le manque de ressources CPU peuvent entraîner des migrations lentes, ce qui peut également entraîner d'autres effets secondaires.

Classe d'instance 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 plus grandes. Une instance plus volumineuse peut être une bonne idée car le service consomme beaucoup de mémoire et de processeur.

Les instances de type T2 sont conçues pour offrir des performances de base modérées et la possibilité d'émettre en rafale pour atteindre des performances nettement supérieures, si votre charge de travail l'exige. Ils sont destinés aux charges de travail qui n'utilisent pas souvent ou de manière continue l'intégralité du processeur, mais qui ont parfois besoin d'émettre en rafale. Les instances T2 conviennent parfaitement aux charges de travail générales telles que les serveurs web, les environnements de développement et les petites bases de données. Si vous dépannez une migration lente et que vous utilisez un type d'instance T2, vérifiez la mesure de l'hôte d'utilisation du processeur. Il peut vous indiquer si vous dépassez la ligne de base pour 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 de paquet par seconde (PPS) nettement plus élevées, ainsi qu'une instabilité et une latence réseau réduites.AWS DMSpeut être très consommateur d'UC, 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. Migrations ou réplications continues de systèmes de transactions à haut débit utilisantAWS DMSpeuvent parfois consommer de grandes quantités de ressources d'UC et de mémoire. Les instances R4 incluent davantage de mémoire par vCPU.

AWS DMSprise en charge des classes d'instances R5 et C5

Les classes d'instance R5 sont des instances à mémoire optimisée, conçues pour garantir des performances rapides pour les charges de travail qui traitent de larges volumes de données en mémoire. Migrations ou réplications continues de systèmes de transactions à haut débit utilisantAWS DMSpeuvent parfois consommer de grandes quantités de ressources d'UC et de mémoire. Les instances R5 fournissent 5 % de mémoire supplémentaire par vCPU par rapport à R4 et la plus grande taille fournit 768 GiB de mémoire. En outre, les instances R5 offrent une amélioration du prix de 10 % par GiB et une performance CPU d'environ 20 % supérieure à celle de R4.

Les classes d'instances C5 sont optimisées pour les charges de travail exigeantes en calcul et offrent des performances élevées rentables à un faible rapport prix par calcul. Ils permettent d'obtenir des performances réseau nettement supérieures. Elastic Network Adapter (ENA) fournit des instances C5 avec une bande passante réseau allant jusqu'à 25 Gbit/s et jusqu'à 14 Gbit/s de bande passante dédiée à Amazon EBS.AWS DMSpeut être très consommateur d'UC, 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 ces situations.

Stockage

En fonction de la classe d'instance, 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 effectue des transactions importantes, vous devrez peut-être augmenter votre stockage. Si vous exécutez plusieurs tâches sur le serveur de réplication, vous devrez peut-être également augmenter le stockage. Toutefois, le montant par défaut est généralement suffisant.

Tous les volumes de stockage dansAWS DMSsont des disques SSD (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 des capacités pouvant atteindre 3 000 IOPS sur une base de crédit. En règle générale, vérifiez laReadIOPSetWriteIOPSmesures pour l'instance de réplication. Assurez-vous que la somme de ces valeurs ne dépasse pas les performances de base de 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 prévues pour durer de longues périodes. Si vous utilisezAWS 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 instance de réplication AZ ou multi-AZ unique pendant un chargement complet et qu'un basculement ou un remplacement d'hôte se produit, la tâche de chargement complet devrait échouer. Vous pouvez redémarrer la tâche à partir du point d'échec des tables restantes qui ne se sont pas terminées ou sont en état d'erreur.

Chargement de plusieurs tables en parallel

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 numéro dans leAWS Management Console, ouvrez la console, choisissezTâches, choisissez de créer ou de modifier une tâche, puis choisissezParamè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 numéro à l'aide duAWS CLI, modifiez laMaxFullLoadSubTasksparamètre sousTaskSettings.

Utilisation de la charge complète en parallel

Vous pouvez utiliser une charge parallel à partir de sources LUW Oracle, Microsoft SQL Server, MySQL, Sybase et IBM Db2 en fonction de partitions et de sous-partitions. Cela peut améliorer la durée globale de la charge complète. En outre, lors de l'exécution d'unAWS DMStâche de migration, 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 parallel dans la même tâche de migration.

Pour utiliser une charge parallel, créez une règle de mappage de table de type.table-settingsavec leparallel-loadoption. Au sein dutable-settings, spécifiez les critères de sélection de la ou des tables que vous souhaitez charger en parallel. Pour spécifier les critères de sélection, définissez latypeélément pourparallel-loadà l'un des paramètres suivants :

  • partitions-auto

  • subpartitions-auto

  • partitions-list

  • ranges

  • none

Pour plus d'informations sur ces paramètres, consultez la pageRègles et opérations relatives aux paramètres des tables et des collections.

Utilisation des index, des déclencheurs et des 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 de 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 masse. 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 et CDC, nous vous recommandons d'ajouter des index secondaires avant la phase CDC. Etant donné queAWS DMSutilise la réplication logique, vérifiez que les index secondaires qui prennent en charge les opérations DML sont en place pour empêcher les analyses complètes 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 la coupure.

Désactivation des sauvegardes et de la journalisation des transactions

Lors de la migration d'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 la transition. De même, lors de la migration de systèmes autres qu'Amazon RDS, il est généralement judicieux de désactiver la journalisation sur la cible jusqu'à la transition.

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 ne participent aux transactions communes, vous pouvez peut-être diviser votre migration en plusieurs tâches.  La cohérence transactionnelle est préservée au sein d'une tâche, il est donc important que les tables de tâches distinctes ne participent pas aux transactions commues. En outre, chaque tâche lisant indépendamment le flux de transactions, veillez à ne pas trop utiliser stress 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 sur 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 viole 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 coupure.

Utilisation de votre propre serveur de noms sur site

Généralement, unAWS DMSL'instance de réplication 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 le résolveur Amazon Route 53. Avec cet outil, vous pouvez effectuer des requêtes entre sur site etAWSà l'aide de points de terminaison entrants et sortants, de règles de transfert et d'une connexion privée. Les avantages de l'utilisation d'un serveur de noms sur site incluent une sécurité accrue et une facilité d'utilisation derrière un pare-feu.

Si vous avez des points de terminaison entrants, vous pouvez utiliser les requêtes DNS qui proviennent de points de terminaison entrants pour résoudre les problèmes.AWS-domaines hébergés. Pour configurer les points de terminaison, affectez des adresses IP à chaque sous-réseau auquel vous souhaitez fournir un résolveur. Pour établir la connectivité entre votre infrastructure DNS sur site etAWS, utilisezAWS Direct Connectou d'un réseau privé virtuel (VPN).

Les points de terminaison sortants se connectent à votre serveur de noms sur site. Le serveur de noms accorde uniquement l'accès aux adresses IP incluses dans une liste d'autorisation et définies dans 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é utilisé par l'instance de réplication.

Pour transférer certains domaines 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 duAWSCloud. À partir de cette section logiquement isolée, vous pouvez lancerAWSressources d'un réseau virtuel.

Vous pouvez configurer les domaines hébergés au sein de votre infrastructure DNS locale en tant que règles de transfert conditionnel permettant de configurer les 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 surAWS Direct Connectou un VPN est requis.

Le schéma suivant illustre l'architecture du résolveur Route 53.


                Résolveur Route 53

Pour plus d'informations sur Route 53 DNS Resolver, consultezMise en route avec Route 53 Resolverdans leGuide du développeur Amazon Route 53.

Utilisation d'Amazon Route 53 Resolver avecAWS DMS

Vous pouvez créer un serveur de noms sur site pourAWS DMSpour résoudre les points de terminaison en utilisantAmazon Route 53 Resolver.

Pour créer un serveur de noms sur site pourAWS DMSBasé sur Route 53

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

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

  3. Choisissez la direction de la requête (entrant, sortant ou les deux.

  4. Indiquez la configuration de votre 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 demandez à ce que le résolveur Route 53 les attribue 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 locaux.

  7. Soumettez votre règle.

Lorsque tout est créé, votre VPC est associé à vos règles entrantes et sortantes et peut démarrer le routage du trafic.

Pour plus d'informations sur Route 53 Resolver, consultezMise en route avec Route 53 Resolverdans leGuide du développeur Amazon Route 53.

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

En général,AWS DMSmigre 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 cible à l'aide d'un autre mécanisme, tel que l'importation ou l'exportation. Dans ce cas, assurez-vous que les colonnes LOB sont de type nullable avant de démarrer 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 DMSutilise 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. Assurez-vous toutefois que laTaille maximale du LOBle réglage des paramètres est correct. Définissez ce paramètre sur la plus grande taille de LOB la plus élevée 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. Assurez-vous que si vous avez choisiMode LOB limité, leTaille maximale du LOBest définie sur une valeur qui n'entraîne pas la troncature 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

  • Simple Storage Service (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 LOB

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

Paramètres LOB par table

En utilisant les paramètres LOB par table, vous pouvez remplacer les paramètres LOB au niveau des tâches pour une partie ou la totalité de vos tables. Pour ce faire, définissez lalob-settingsdans votretable-settingsrègle. Voici un exemple de tableau qui inclut des valeurs LOB importantes.

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

Ensuite, créez une tâche de migration et modifiez la gestion des LOB de votre table à l'aide du nouveaulob-settingsrègle. Lebulk-max-sizdétermine la taille maximale du LOB (Ko). Il est tronqué s'il est plus grand que 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 cela estAWS DMSest créé avecFullLobMode : true, les paramètres LOB par table directementAWS DMSpour tronquer les données LOB de ce tableau particulier à 16 000. Vous pouvez consulter les journaux des tâches pour confirmer cela.

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 unAWS DMS, le mode LOB détermine la façon dont les objets LOB sont gérés.

Avec le mode LOB complet et le mode LOB limité, chacun a ses propres avantages et inconvénients. 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 les LOB de petite taille et que la plupart des LOB sont petits. Lorsque vous choisissez cette option, pendant le chargement complet, leAWS DMStransfère les petites LOB en ligne, ce qui est plus efficace. LeAWS DMStransfère les grands LOB en effectuant une recherche à partir de la table source.

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

Lorsque vous utilisez le mode LOB en ligne, leAWS DMSvérifie toutes les tailles de LOB pour déterminer celles à transférer en ligne. Les 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 LOB sont supérieurs au paramètre spécifié, il est préférable de ne pas utiliser cette option. Au lieu de cela, autorisez 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 lorsqueFullLobModea la valeurtrue. La valeur par défaut deInlineLobMaxSizeest 0. La plage est comprise entre 1 ko et 2 Go.

Par exemple, vous pouvez utiliser les éléments suivantsAWS DMSparamètres de tâche. Ici, réglageInlineLobMaxSizeà une valeur de 5, tous les LOB inférieurs ou égaux à 5 000 sont transférés en ligne.

{ "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

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, procédez comme suit :

  1. Ouvrez l'AWS Management Console.

  2. ChoisissezTâches, et créez une nouvelle tâche.

  3. Cliquez sur l'ongletMappage de tableet développezRègles de sélection.

  4. ChoisissezAjout d'une règle de sélection. Vous pouvez désormais ajouter un filtre de colonne avec un opérateur inférieur ou égal à, supérieur ou égal à, égal à ou une condition de plage entre deux valeurs. Pour plus d'informations sur le filtrage des colonnes, consultez Spécifier les règles de sélection et de transformation des tables depuis la console.

Si vous disposez d'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 plus CDC pour la partition actuellement mise à jour.

Si votre table comporte une clé primaire à une colonne ou un index unique, vous pouvez avoir votreAWS DMSsegmentez la table en utilisant une charge parallel du type de plages pour charger les données en parallel. Pour plus d'informations, consultez Règles et opérations relatives aux paramètres des tables et des collections.

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 DDL (langage de définition de données).AWS DMSne propage pas les éléments tels que les index, les utilisateurs, les privilèges, les procédures stockées et autres modifications apportées à la base de données qui ne soient pas directement liées aux données de la table.

Si vous envisagez d'utiliser la réplication en cours, définissez le paramètreMulti-AZlorsque vous créez votre instance de réplication. En choisissantMulti-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 peut ralentir la réplication lors de l'application des modifications au système cible.

Avant de mettre à niveau vos bases de données source ou cible, nous vous recommandons d'arrêter toutAWS DMSles tâches qui s'exécutent sur ces bases de données. Reprenez les tâches une fois vos mises à niveau terminées.

Lors de la réplication continue, il est essentiel d'identifier la bande passante réseau entre votre système de base de données source et votreAWS DMSinstance de réplication. Assurez-vous que le réseau ne cause aucun goulot d'étranglement pendant la réplication en cours.

Il est également important d'identifier le taux de modification et de génération de journaux d'archivage par heure sur votre système de base de données source. Cela peut vous aider à comprendre le débit que vous pourriez obtenir pendant la réplication en cours.

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 votre 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éduire les goulots d'étranglement sur votre base de données cible

Pendant la migration, essayez de supprimer tous les processus en concurrence pour les ressources d'écriture de votre base de données cible :

  • Désactivez les déclencheurs inutiles.

  • Désactivez les index secondaires pendant le chargement initial et rallumez-les ultérieurement pendant la réplication en cours.

  • Avec les bases de données Amazon RDS, il est judicieux de désactiver les sauvegardes et Multi-AZ jusqu'à la transition.

  • Lors de la migration des systèmes autres que RDS, il est judicieux de désactiver toute journalisation sur la cible jusqu'à la transition.

Utilisation de la validation des données pendant la migration

Pour vérifier 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 DMScommence à comparer les données source et cible immédiatement après l'exécution d'un chargement complet d'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

Pour plus d'informations, consultez AWSValidation des données DMS.

Surveillance de votreAWS DMStâches utilisant les métriques

Vous disposez de plusieurs options pour surveiller les mesures de vos tâches à l'aide de l'outilAWS DMSConsole  :

Métriques d'hôte

Vous pouvez trouver les mesures de l'hôte sur leMétriques CloudWatchpour chaque instance de réplication particulière. Ici, vous pouvez vérifier si votre instance de réplication est dimensionnée de manière appropriée.

Métriques de tâches de réplication

Les mesures relatives aux tâches de réplication, notamment les modifications entrantes et validées, ainsi que la latence entre l'hôte de réplication et les bases de données source/cible peuvent être trouvées sur leMétriques CloudWatchpour chaque tâche particulière.

Mesures de table

Vous pouvez trouver des mesures de table individuelles sur leStatistiques de tablepour chaque tâche individuelle. Ces mesures incluent les chiffres suivants :

  • Lignes chargées pendant le chargement complet.

  • Insère, met à jour et supprime 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, consultezSurveillanceAWSTâches.

Événements et notifications

AWS DMSutilise Amazon SNS pour fournir des notifications lorsqu'unAWS DMSse 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 unAWSRégion . Il peut s'agir de messages électroniques, 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 dansAWS 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 afficher le journal des tâches, configurez Amazon CloudWatch dans le cadre de la création de tâches.

Pour de plus amples informations, veuillez consulterSurveillance des tâches de réplication à l'aide d'Amazon CloudWatch.

Dépannage des tâches de réplication avec Time Travel

Pour résoudre les problèmes relatifs àAWS DMSproblèmes de migration, vous pouvez travailler avec Time Travel. Pour plus d'informations sur le voyage dans le temps, consultezParamètres Time Travel.

Lorsque vous travaillez avec Time Travel, tenez compte des considérations suivantes :

  • Pour éviter les surcharges sur une instance de réplication DMS, activez Travel temporel uniquement pour les tâches nécessitant un débogage.

  • Lorsque vous utilisez Travel dans le temps pour résoudre les problèmes de tâches de réplication qui peuvent s'exécuter pendant plusieurs jours, surveillez les mesures d'instance de réplication pour détecter les frais généraux de ressources. Cette approche s'applique en particulier dans les cas où des charges de transactions élevées s'exécutent sur des bases de données sources pendant de longues périodes. Pour en savoir plus, consultez SurveillanceAWSTâches.

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

  • Actuellement, vous pouvez activer Travel dans le temps uniquement au niveau des tâches. Les modifications apportées à toutes les tables sont consignées dans les journaux de voyage temporel. Si vous effectuez un dépannage pour des tables spécifiques dans une base de données avec 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 DMSmigre 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éPERFDATAvers un point de terminaison cible Oracle, et que le nom d'utilisateur du point de terminaison cible estMASTER.AWS DMSse connecte à la cible Oracle en tant queMASTERet remplit leMASTERschéma avec des objets de base de données dePERFDATA.

Pour remplacer ce comportement, fournissez une transformation de schéma. Par exemple, pour migrer lePERFDATAobjets de schéma vers unPERFDATAschéma 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 et de transformation des tables à l'.

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

Lorsque vous utilisez Oracle comme cible,AWS DMSmigre toutes les tables et tous les index vers l'espace disque logique 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 cible 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 de la source est nomméINVENTORYet les espaces de table de table et d'index correspondants dans la cible sont nommésINVENTORYTBLetINVENTORYIDX.

{ "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 et de transformation des tables à l'.

Si Oracle est à la fois source et cible, vous pouvez conserver les affectations d'espace de table de table ou d'index existantes en définissant l'attribut de connexion supplémentaire source Oracle.enableHomogenousTablespace=true. Pour plus d'informations, consultez Attributs de connexion supplémentaires lors de l'utilisation d'Oracle comme source pour AWS DMS.

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

AWSpublie régulièrement de nouvelles versions duAWS DMSLogiciel de moteur de réplication avec de nouvelles fonctions et des performances améliorées. Chaque version du moteur de réplication a son propre numéro de version. Il est essentiel de tester la version existante de votreAWS DMSinstance de réplication 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, consultezAWSNotes de mise à jour DMS.

Comprendre vos coûts de migration

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

Il se peut que vous ayez besoin de ressources supplémentaires pendant le chargement initial ou pendant le temps de pointe. Vous pouvez surveiller de près l'utilisation des ressources des instances de réplication à l'aide des mesures Cloud Watch. Vous pouvez ensuite augmenter et réduire la taille de l'instance de réplication en fonction de l'utilisation.

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