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 pour AWS Database Migration Service

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

Planification de la migration pour AWS Database Migration Service

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

Conversion de schémas

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

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

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

Examen de la documentation publique d'AWS DMS

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

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

Exécution d'une preuve de concept

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

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

Améliorer les performances d'une migration AWS DMS

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

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 :

Utilisation de votre propre serveur de noms sur site

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

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

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

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

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

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

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

Utilisation d'Amazon Route 53 Resolver avec AWS DMS

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

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

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

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

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

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

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

Utilisation du mode LOB limité

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

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

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

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

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.

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

Amélioration des performances des objets LOB

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

Paramètres LOB par table

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

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

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

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

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

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

Paramètres LOB en ligne

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

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

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

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

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

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

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

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

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

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

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

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

la réplication continue.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Pour plus d'informations sur la surveillance des métriques, consultez Surveillance des tâches AWS DMS.

Événements et notifications

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

AWS publie régulièrement de nouvelles versions du logiciel de moteur de réplication AWS DMS avec de nouvelles fonctionnalités et améliorations des performances. Chaque version du logiciel de moteur de réplication a son propre numéro de version. Il est essentiel de tester la version existante de votre instance de réplication AWS DMS exécutant une charge de travail de production avant de mettre à niveau votre instance de réplication vers une version ultérieure. Pour plus d'informations sur les mises à niveau des versions disponibles, consultez AWS 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 AWS facilement, en toute sécurité et à moindre coût. Vous ne payez que pour vos instances de réplication et pour tout stockage de journaux supplémentaire. Chaque instance de migration de base de données inclut un espace de stockage suffisant pour l'espace d'échange, les journaux de réplication et le cache de données pour la plupart des réplications. De plus, le transfert de données entrantes est gratuit.

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

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