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.
# Utilisation d'une instance AWS DMS de réplication
Lorsque vous créez une instance de AWS DMS réplication, AWS DMS créez-la sur une instance Amazon EC2 dans un cloud privé virtuel (VPC) basé sur le service Amazon VPC. Cette instance de réplication vous permet de réaliser votre migration de base de données. L’utilisation d’une instance de réplication vous permet de bénéficier d’une haute disponibilité et de la prise en charge du basculement avec un déploiement multi-AZ lorsque vous choisissez l’option **Multi-AZ**.
Dans un déploiement multi-AZ, provisionne et gère AWS DMS automatiquement une réplique de secours synchrone de l'instance de réplication dans une autre zone de disponibilité. L'instance de réplication principale est répliquée de manière synchrone entre les Zones de Disponibilité vers le réplica de secours. Cette approche assure la redondance des données, élimine les I/O blocages et minimise les pics de latence.
![\[AWS Instance de réplication du Service de Migration de base de données\]](http://docs.aws.amazon.com/fr_fr/dms/latest/userguide/images/datarep-conceptual2.png)
AWS DMS utilise une instance de réplication pour se connecter à votre magasin de données source, lire les données sources et formater les données pour qu'elles soient consommées par le magasin de données cible. Une instance de réplication charge également les données dans le magasin 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 pouvez créer une instance de AWS DMS réplication dans les AWS régions suivantes.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/dms/latest/userguide/CHAP_ReplicationInstance.html)
AWS DMS prend en charge une AWS région spéciale appelée AWS GovCloud (US) , conçue pour permettre aux agences gouvernementales et aux clients américains de transférer des charges de travail sensibles vers le cloud. AWS GovCloud (US) répond aux exigences réglementaires et de conformité spécifiques du gouvernement américain. Pour plus d'informations AWS GovCloud (US), voir [Qu'est-ce que AWS GovCloud (États-Unis) ?](https://docs.aws.amazon.com/govcloud-us/latest/UserGuide/whatis.html)
Ci-dessous, vous trouverez plus d'informations sur les instances de réplication.
**Topics**
+ [Choisir l'instance de réplication AWS DMS adaptée à votre migration](CHAP_ReplicationInstance.Types.md)
+ [Sélection de la meilleure taille pour une instance de réplication](CHAP_BestPractices.SizingReplicationInstance.md)
+ [Utilisation des versions du moteur de réplication](CHAP_ReplicationInstance.EngineVersions.md)
+ [Instances de réplication publiques et privées](CHAP_ReplicationInstance.PublicPrivate.md)
+ [Adressage IP et types de réseau](CHAP_ReplicationInstance.IPAddressing.md)
+ [Configuration d'un réseau pour une instance de réplication](CHAP_ReplicationInstance.VPC.md)
+ [Définition d'une clé de chiffrement pour une instance de réplication](CHAP_ReplicationInstance.EncryptionKey.md)
+ [Création d'une instance de réplication](CHAP_ReplicationInstance.Creating.md)
+ [Modification d'une instance de réplication](CHAP_ReplicationInstance.Modifying.md)
+ [redémarrage d'une instance de réplication.](CHAP_ReplicationInstance.Rebooting.md)
+ [Supprimez une instance de réplication.](CHAP_ReplicationInstance.Deleting.md)
+ [Utilisation de la fenêtre AWS DMS de maintenance](CHAP_ReplicationInstance.MaintenanceWindow.md)
# Choisir l'instance de réplication AWS DMS adaptée à votre migration
AWS DMS crée l'instance de réplication sur une instance Amazon EC2. AWS DMS prend actuellement en charge les classes d'instances Amazon EC2 T3, C5, C6i, R5 et R6i pour les instances de réplication :
+ Les instances T3 constituent le type d’instance à usage général extensible de nouvelle génération. Ce type fournit un niveau de référence de performances de CPU avec la possibilité d’étendre l’utilisation de CPU à tout moment et aussi longtemps que nécessaire. Les instances T3 offrent un équilibre entre les ressources de calcul, de mémoire et de réseau, et sont conçues pour les applications dont l’utilisation de CPU est modérée et qui connaissent des pics d’utilisation temporaires. Les instances T3 accumulent des crédits de CPU quand une charge de travail fonctionne en dessous du seuil de référence. Chaque crédit CPU obtenu donne à l’instance T3 l’occasion de bénéficier des performances d’un cœur de CPU complet pendant une minute en cas de besoin.
Les instances T3 peuvent émettre en rafales à tout moment et aussi longtemps que nécessaire en mode `unlimited`. Pour plus d’informations sur le mode `unlimited`, consultez [Utilisation du mode illimité pour les instances à performances extensibles](#CHAP_ReplicationInstance.Types.UnlimitedMode).
+ Les instances C5 constituent le type d’instance de nouvelle génération qui fournit des performances élevées et économiques à un faible rapport prix/calcul pour l’exécution de charges de travail avancées gourmandes en calcul. Cela inclut des charges de travail telles que les serveurs Web hautes performances, le calcul haute performance (HPC), le traitement par lots, la diffusion de publicités, les jeux multijoueurs hautement évolutifs et l’encodage vidéo. Les autres charges de travail pour lesquelles les instances C5 sont adaptées incluent la modélisation scientifique, les analyses distribuées et l’inférence par machine learning et deep learning. Les instances C5 sont disponibles avec un choix de processeurs Intel et AMD.
+ Les instances C6i offrent un rapport prix-performance de calcul jusqu’à 15 % supérieur à celui des instances Gen5 comparables pour une grande variété de charges de travail, ainsi qu’un chiffrement de mémoire permanent. Les instances C6 conviennent parfaitement aux charges de travail gourmandes en calcul, telles que le traitement par lots, l’analytique distribuée, le calcul haute performance (HPC), la diffusion de publicités, les jeux multijoueurs hautement évolutifs et l’encodage vidéo.
+ Les instances R5 appartiennent à la nouvelle génération de types d’instances à mémoire optimisée pour Amazon EC2. Les instances R5 conviennent aux applications gourmandes en mémoire, telles que les bases de données à hautes performances, les caches en mémoire distribués à l’échelle du web, les bases de données en mémoire de taille moyenne, l’analytique du big data en temps réel et les autres applications d’entreprise. Les migrations ou réplications continues de systèmes de transaction à haut débit AWS DMS peuvent également consommer de grandes quantités de processeur et de mémoire.
+ Les instances R6i offrent un rapport prix-performance de calcul jusqu’à 15 % supérieur à celui des instances Gen5 comparables pour une grande variété de charges de travail, ainsi qu’un chiffrement de mémoire permanent. Les instances R6i sont certifiées SAP et sont idéales pour les charges de travail telles que les bases de données SQL et NoSQL, les caches en mémoire distribués à l'échelle du Web tels que Memcached et Redis OSS, les bases de données en mémoire comme SAP HANA et les analyses de mégadonnées en temps réel comme les clusters Hadoop et Spark.
+ Les instances C7i offrent de meilleures performances de calcul par rapport aux instances comparables de la génération précédente. En ce qui AWS DMS concerne les charges de travail, les instances C7i excellent dans l'accélération des processus de transformation des données, la gestion des conversions de schémas gourmandes en ressources informatiques et le maintien d'un débit constant lors de tâches de migration à volume élevé. Ces instances fournissent un équilibre idéal entre les performances de calcul qui nécessitent des performances soutenues du processeur.
+ Les instances R7i offrent de meilleures performances de calcul par rapport aux instances comparables de génération précédente, associées à une capacité de mémoire élevée pour les charges de travail gourmandes en mémoire. Pour les AWS DMS charges de travail, les instances R7i sont particulièrement adaptées aux tâches impliquant de grandes bases de données traitant de gros volumes de transactions de base de données simultanées, ce qui permet de gérer efficacement les scénarios de réplication gourmands en mémoire et les processus de validation de données complexes qui nécessitent des mémoires tampons importantes.
Chaque instance de réplication a une configuration spécifique de la mémoire et des processeurs virtuels. Le tableau suivant présente la configuration pour chaque type d'instance de réplication. Pour obtenir des informations sur la tarification, consultez la [page de tarification du service AWS Database Migration Service](https://aws.amazon.com/dms/pricing/).
**Types d’instances de réplication à usage général**
| Type | vCPU | Mémoire (Gio) |
| --- | --- | --- |
| dms.t3.micro | 2 | 1 |
| dms.t3.small | 2 | 2 |
| dms.t3.medium | 2 | 4 |
| dms.t3.large | 2 | 8 |
**Types d’instances de réplication optimisés pour le calcul**
| Type | vCPU | Mémoire (Gio) |
| --- | --- | --- |
| dms.c5.large | 2 | 4 |
| dms.c5.xlarge | 4 | 8 |
| dms.c5.2xlarge | 8 | 16 |
| dms.c5.4xlarge | 16 | 32 |
| dms.c5.9xlarge | 36 | 72 |
| dms.c5.12xlarge | 48 | 96 |
| dms.c5.18xlarge | 72 | 144 |
| dms.c5.24xlarge | 96 | 192 |
| dms.c6i.large | 2 | 4 |
| dms.c6i.xlarge | 4 | 8 |
| dms.c6i.2xlarge | 8 | 16 |
| dms.c6i.4xlarge | 16 | 32 |
| dms.c6i.8xlarge | 32 | 64 |
| dms.c6i.12xlarge | 48 | 96 |
| dms.c6i.16xlarge | 64 | 128 |
| dms.c6i.24xlarge | 96 | 192 |
| dms.c6i.32xlarge | 128 | 256 |
| dms.c7i.large | 2 | 4 |
| dms.c7i.xlarge | 4 | 8 |
| dms.x7i.2xlarge | 8 | 16 |
| dms.x7i.4xlarge | 16 | 32 |
| dms.x7i.8xlarge | 32 | 64 |
| dms.x7i.12xlarge | 48 | 96 |
| dms.x7i.16xlarge | 64 | 128 |
| dms.x7i.24xlarge | 96 | 192 |
| dms.x7i.48xlarge | 192 | 384 |
**Types d’instances de réplication à mémoire optimisée**
| Type | vCPU | Mémoire (Gio) |
| --- | --- | --- |
| dms.r5.large | 2 | 16 |
| dms.r5.xlarge | 4 | 32 |
| dms.r5.2xlarge | 8 | 64 |
| dms.r5.4xlarge | 16 | 128 |
| dms.r5.8xlarge | 32 | 256 |
| dms.r5.12xlarge | 48 | 384 |
| dms.r5.16xlarge | 64 | 512 |
| dms.r5.24xlarge | 96 | 768 |
| dms.r6i.large | 2 | 16 |
| dms.r6i.xlarge | 4 | 32 |
| dms.r6i.2xlarge | 8 | 64 |
| dms.r6i.4xlarge | 16 | 128 |
| dms.r6i.8xlarge | 32 | 256 |
| dms.r6i.12xlarge | 48 | 384 |
| dms.r6i.16xlarge | 64 | 512 |
| dms.r6i.24xlarge | 96 | 768 |
| dms.r6i.32xlarge | 128 | 1 024 |
| dms.r7i.large | 2 | 16 |
| dms.r7i.xlarge | 4 | 32 |
| dms.r7i.2xlarge | 8 | 64 |
| dms.r7i.4xlarge | 16 | 128 |
| dms.r7i.8xlarge | 32 | 256 |
| dms.r7i 12 x large | 48 | 384 |
| dms.r7i.16 x large | 64 | 512 |
| dms.r7i 24 x large | 96 | 768 |
| dms.r7i 48 x large | 192 | 1536 |
Les tableaux ci-dessus répertorient tous les types d'instances de AWS DMS réplication, mais les types disponibles dans votre région peuvent varier. Pour connaître les types d’instances de réplication disponibles dans votre région, vous pouvez exécuter la commande [AWS CLI](https://docs.aws.amazon.com/cli/latest/reference/dms/index.html) suivante :
```
aws dms describe-orderable-replication-instances --region your_region_name
```
**Topics**
+ [Choix de la classe d’instances à utiliser](#CHAP_ReplicationInstance.Types.Deciding)
+ [Utilisation du mode illimité pour les instances à performances extensibles](#CHAP_ReplicationInstance.Types.UnlimitedMode)
## Choix de la classe d’instances à utiliser
Pour déterminer la classe d'instance de réplication qui vous convient le mieux, examinons le processus de capture des données de modification (CDC) AWS DMS utilisé.
Supposons que vous exécutez une tâche de chargement complet \$1 CDC (chargement en masse \$1 réplication continue). Dans ce cas, la tâche possède son propre SQLite référentiel pour stocker les métadonnées et autres informations. Avant de AWS DMS démarrer un chargement complet, procédez comme suit :
+ AWS DMS commence à capturer les modifications apportées aux tables qu'il migre à partir du journal des transactions du moteur source (c'est ce que nous appelons les *modifications mises en cache*). Une fois le chargement complet terminé, ces modifications mises en cache sont collectées et appliquées sur la cible. En fonction du volume des modifications mises en cache, ces modifications peuvent être appliquées directement à partir de la mémoire, où elles sont collectées en premier, jusqu'à un seuil défini. Elles peuvent également être appliquées à partir du disque, où les modifications sont écrites lorsqu’elles ne peuvent pas être conservées en mémoire.
+ Une fois les modifications mises en cache appliquées, AWS DMS lance par défaut un processus d'application transactionnel sur l'instance cible.
Au cours de la phase des modifications mises en cache appliquées et de la phase de réplication en cours, AWS DMS utilise deux tampons de flux, un pour les données entrantes et sortantes. AWS DMS utilise également un composant important appelé *trieur,* qui est une autre mémoire tampon. Voici deux utilisations importantes du composant trieur (qui en a d'autres) :
+ Il suit toutes les transactions et s'assure de transférer uniquement les transactions pertinentes vers la mémoire tampon sortante.
+ Il s'assure que les transactions sont transférées dans le même ordre de validation que sur la source.
Comme vous pouvez le voir, nous avons trois mémoires tampon importantes dans cette architecture pour CDC dans AWS DMS. Si l'un quelconque de ces tampons connaît une sollicitation importante de mémoire, la migration peut avoir des problèmes de performances susceptibles d'entraîner des échecs.
Lorsque vous connectez d’importantes charges de travail dotées d’un grand nombre de transactions par seconde (TPS) dans cette architecture, la mémoire supplémentaire fournie par les instances R5 et R6i peut s’avérer utile. Vous pouvez utiliser les instances R5 et R6i pour conserver un grand nombre de transactions en mémoire et éviter des problèmes de sollicitation de mémoire au cours des réplications continues.
## Utilisation du mode illimité pour les instances à performances extensibles
Une instance à performances extensibles configurée en mode `unlimited`, telle qu’une instance T3, peut maintenir une utilisation de CPU élevée pour toute période donnée, en cas de nécessité. Le prix horaire de l’instance peut couvrir automatiquement tous les pics d’utilisation de CPU. Il le fait si l’utilisation moyenne de CPU de l’instance est égale ou inférieure à la référence sur une période glissante de 24 heures ou pendant la durée de vie de l’instance, si celle-ci est plus courte.
Pour la grande majorité des charges de travail à usage général, les instances configurées comme `unlimited` fournissent des performances suffisantes sans frais supplémentaires. Si l’instance s’exécute avec une utilisation d’UC supérieure pendant une période prolongée, c’est possible moyennant des frais supplémentaires fixes par heure vCPU. Pour en savoir plus sur la tarification des instances T3, consultez « Crédits CPU T3 » dans [AWS Database Migration Service](https://aws.amazon.com/dms/pricing/).
Pour plus d'informations sur le `unlimited` mode pour les instances T3, consultez la section [Mode illimité pour les instances à performances éclatantes](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/burstable-performance-instances-unlimited-mode.html) dans le guide de l'utilisateur *Amazon EC2*.
**Important**
Si vous utilisez une instance `dms.t3.micro` dans le cadre de l’[offre gratuite AWS](https://aws.amazon.com/free/) et que vous l’utilisez en mode `unlimited`, des frais peuvent s’appliquer. En particulier, des frais peuvent s’appliquer si votre utilisation moyenne sur une période glissante de 24 heures excède l’utilisation de référence de l’instance. Pour plus d'informations, consultez la section [Utilisation de base](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/burstable-credits-baseline-concepts.html#baseline_performance) dans le guide de l'*utilisateur Amazon EC2*.
Les instances T3 sont lancées en mode `unlimited` par défaut. Si l’utilisation moyenne de l’UC sur une période de 24 heures dépasse le niveau de référence, vous devrez payer des frais pour les crédits excédentaires. Dans certains cas, vous pouvez lancer des instances Spot T3 en mode `unlimited` et prévoir de les utiliser immédiatement et pour une courte durée. Si vous effectuez cette opération sans temps d’inactivité pour accumuler des crédits de CPU, vous devrez payer des frais pour les crédits excédentaires. Nous vous recommandons de lancer vos instances Spot T3 en mode standard pour éviter des coûts plus élevés. Pour plus d'informations, consultez les sections « [Les crédits excédentaires peuvent entraîner des frais](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/burstable-performance-instances-unlimited-mode-concepts.html#unlimited-mode-surplus-credits) », « [Instances ponctuelles T3 » et « Mode standard » pour les instances](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-spot-limits.html#t3-spot-instances) [offrant des performances optimisées dans le guide](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/burstable-performance-instances-standard-mode.html) de l'utilisateur *Amazon* EC2.
# Sélection de la meilleure taille pour une instance de réplication
Le choix de l'instance de réplication appropriée dépend de plusieurs facteurs propres à votre cas d'utilisation. Pour mieux comprendre comment les ressources d'instance de réplication sont utilisées, consultez la discussion suivante. Elle couvre le scénario courant d'une tâche de chargement complet \$1 CDC.
Lors d'une tâche de chargement complet, AWS DMS charge les tables individuellement. Par défaut, huit tables sont chargées à la fois. AWS DMS capture les modifications continues apportées à la source pendant une tâche de chargement complet afin que les modifications puissent être appliquées ultérieurement sur le point de terminaison cible. Ces modifications sont mises en cache en mémoire ; si la mémoire disponible est épuisée, les modifications sont mises en cache sur le disque. Lorsqu'une tâche de chargement complet est terminée pour une table, applique AWS DMS immédiatement les modifications mises en cache à la table cible.
Une fois que toutes les modifications mises en cache pour une table ont été appliquées, le point de terminaison cible se trouve dans un état transactionnel cohérent. À ce stade, la cible est synchronisée avec le point de terminaison source par rapport aux dernières modifications mises en cache. AWS DMS commence ensuite la réplication en cours entre la source et la cible. Pour ce faire, AWS DMS prend les opérations de modification des journaux de transactions source et les applique à la cible de manière cohérente sur le plan des transactions. (Ce processus suppose que l'option Appliquer optimisée par lots n'est pas sélectionnée). AWS DMS diffuse les modifications en cours via la mémoire de l'instance de réplication, si possible. Sinon, AWS DMS écrit les modifications sur le disque de l'instance de réplication jusqu'à ce qu'elles puissent être appliquées à la cible.
Vous pouvez contrôler la façon dont l'instance de réplication gère le traitement des modifications et la façon dont la mémoire est utilisée dans ce processus. Pour plus d'informations sur la manière d'ajuster le traitement des modifications, consultez [Paramètres de réglage du traitement des modifications](CHAP_Tasks.CustomizingTasks.TaskSettings.ChangeProcessingTuning.md).
## Facteurs à prendre en compte
La mémoire et l’espace disque sont des facteurs clés pour la sélection d’une instance de réplication appropriée à votre cas d’utilisation. Vous trouverez ci-dessous une présentation des caractéristiques des cas d’utilisation à analyser pour choisir une instance de réplication.
+ Taille des tables et de la base de données
Le volume de données permet de déterminer la configuration des tâches afin d’optimiser les performances de chargement complet. Par exemple, pour deux schémas de 1 To, vous pouvez partitionner les tables en quatre tâches de 500 Go et les exécuter en parallèle. Le parallélisme possible dépend de la ressource CPU disponible dans l’instance de réplication. C’est pourquoi il est judicieux de connaître la taille de votre base de données et de vos tables afin d’optimiser les performances de chargement complet. Cela permet de déterminer le nombre de tâches que vous pouvez éventuellement effectuer.
+ Objets volumineux
Les types de données présents dans l’étendue de migration peuvent affecter les performances. Les objets volumineux (LOBs) ont notamment un impact sur les performances et la consommation de mémoire. Pour migrer une valeur LOB, AWS DMS exécute un processus en deux étapes. Tout d'abord, AWS DMS insère la ligne dans la cible sans la valeur LOB. Ensuite, AWS DMS met à jour la ligne avec la valeur LOB. Cela a un impact sur la mémoire, il est donc important d’identifier les colonnes LOB dans la source et d’analyser leur taille.
+ Fréquence de chargement et taille des transactions
La fréquence de chargement et le nombre de transactions par seconde (TPS) influencent l’utilisation de la mémoire. Un nombre élevé du TPS ou des activités de langage de manipulation de données (DML) entraîne une utilisation importante de mémoire. Cela se produit parce que DMS met en cache les modifications jusqu’à ce qu’elles soient appliquées à la cible. Pendant la CDC, cela entraîne un échange (écriture sur le disque physique en raison d’un débordement de mémoire), qui génère de la latence.
+ Clés de table et intégrité référentielle
Les informations relatives aux clés de la table déterminent le mode CDC (application par lots ou application transactionnelle) que vous utilisez pour migrer les données. En général, l’application transactionnelle est plus lente que l’application par lots. Pour les transactions de longue durée, il peut y avoir de nombreuses modifications à migrer. Lorsque vous utilisez l'application transactionnelle, il AWS DMS peut être nécessaire de disposer de plus de mémoire pour stocker les modifications par rapport à l'application par lots. Si vous migrez des tables sans clés primaires, l’application par lots échoue et la tâche DMS passe en mode d’application transactionnelle. Lorsque l'intégrité référentielle est active entre les tables pendant le CDC, AWS DMS utilise l'application transactionnelle par défaut. Pour plus d’informations sur l’application par lots par rapport à l’application transactionnelle, consultez [Comment puis-je utiliser la fonctionnalité d’application par lots DMS pour améliorer les performances de réplication CDC ?](https://aws.amazon.com/premiumsupport/knowledge-center/dms-batch-apply-cdc-replication/).
Utilisez ces métriques pour déterminer si l’instance de réplication doit être optimisée pour le calcul ou pour la mémoire.
## Problèmes courants
Vous pouvez être confronté aux problèmes courants suivants qui entraînent une contention des ressources sur l’instance de réplication lors de la migration. Pour en savoir plus sur les métriques de l’instance de réplication, consultez [Métriques des instances de réplication](CHAP_Monitoring.md#CHAP_Monitoring.Metrics.CloudWatch).
+ Si la mémoire d’une instance de réplication devient insuffisante, cela entraîne l’écriture de données sur le disque. La lecture depuis le disque peut entraîner une latence, que vous pouvez éviter en dimensionnant l’instance de réplication avec suffisamment de mémoire.
+ La taille de disque attribuée à l’instance de réplication peut être inférieure à celle requise. La taille du disque est utilisée quand les données en mémoire débordent ; elle est également utilisée pour stocker les journaux de tâches. Le nombre maximal d’IOPS en dépend également.
+ L’exécution de plusieurs tâches ou de tâches présentant un parallélisme élevé affecte la consommation de CPU de l’instance de réplication. Cela ralentit le traitement des tâches et génère de la latence.
## Bonnes pratiques
Tenez compte de ces deux bonnes pratiques les plus courantes lors du dimensionnement d’une instance de réplication. Pour de plus amples informations, veuillez consulter [Les meilleures pratiques pour AWS Database Migration Service](CHAP_BestPractices.md).
1. Dimensionnez votre charge de travail et déterminez si elle est gourmande en ressources informatiques ou en mémoire. Sur cette base, vous pouvez déterminer la classe et la taille de l’instance de réplication :
+ AWS DMS processus LOBs en mémoire. Cette opération nécessite une quantité importante de mémoire.
+ Le nombre de tâches et le nombre de threads ont un impact sur la consommation de CPU. Évitez d’en utiliser plus de huit `MaxFullLoadSubTasks` pendant l’opération de chargement complet.
1. Augmentez l’espace disque attribué à l’instance de réplication lorsque la charge de travail est élevée pendant le chargement complet. Cela permet à l’instance de réplication d’utiliser le nombre maximal d’IOPS qui lui est attribué.
Les directives précédentes ne couvrent pas tous les scénarios possibles. Il est important de prendre en compte les spécificités de votre cas d’utilisation particulier lorsque vous déterminez la taille de votre instance de réplication.
Les tests précédents montrent que le CPU et la mémoire varient avec différentes charges de travail. En particulier, LOBs cela affecte la mémoire, et le nombre de tâches ou le parallélisme affectent le processeur. Une fois que votre migration est en cours d’exécution, surveillez le CPU, la mémoire libérable, le stockage disponible et les IOPS de votre instance de réplication. En fonction des données que vous collectez, vous pouvez dimensionner votre instance de réplication à la hausse ou à la baisse, selon les besoins.
# Utilisation des versions du moteur de réplication
Le *moteur de réplication* est le AWS DMS logiciel principal qui s'exécute sur votre instance de réplication et exécute les tâches de migration que vous spécifiez. 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 moteur de réplication a son propre numéro, pour la distinguer des autres versions.
Lorsque vous lancez une nouvelle instance de réplication, celle-ci exécute la dernière version AWS DMS du moteur, sauf indication contraire de votre part. Pour de plus amples informations, veuillez consulter [Utilisation d'une instance AWS DMS de réplication](CHAP_ReplicationInstance.md).
Si une instance de réplication est actuellement en cours d'exécution, vous pouvez la mettre à niveau vers une version du moteur plus récente. (AWS DMS ne prend pas en charge les rétrogradations de version du moteur.) Pour de plus amples informations sur les versions du moteur de réplication, veuillez consulter [AWS Notes de mise à jour du DMS](CHAP_ReleaseNotes.md).
## Mise à niveau de la version du moteur à l'aide de la console
Vous pouvez mettre à niveau une instance AWS DMS de réplication à l'aide du AWS Management Console.
**Pour mettre à niveau une instance de réplication à l'aide de la console**
1. Ouvrez la AWS DMS console à l'adresse [https://console.aws.amazon.com/dms/v2/](https://console.aws.amazon.com/dms/v2/).
1. Dans le volet de navigation, sélectionnez **Instances de réplication**.
1. Choisissez votre moteur de réplication, puis choisissez **Modifier**.
1. Pour **Version du moteur**, choisissez le numéro de version de votre choix, puis choisissez **Modifier**.
**Note**
Nous vous recommandons d’arrêter toutes les tâches avant de mettre à niveau l’instance de réplication. Si vous n'arrêtez pas la tâche, elle l' AWS DMS arrêtera automatiquement avant la mise à niveau. Si vous arrêtez la tâche manuellement, vous devrez la démarrer manuellement une fois la mise à niveau terminée. La mise à niveau de l'instance de réplication prend plusieurs minutes. Lorsque l'instance est prête, son statut passe à **available**.
## Mise à niveau de la version du moteur à l'aide du AWS CLI
Vous pouvez mettre à niveau une instance de AWS DMS réplication à l'aide du AWS CLI, comme suit.
**Pour mettre à niveau une instance de réplication à l'aide du AWS CLI**
1. Déterminez le nom Amazon Resource Name (ARN) de votre instance de réplication à l'aide de la commande suivante.
```
aws dms describe-replication-instances \
--query "ReplicationInstances[*].[ReplicationInstanceIdentifier,ReplicationInstanceArn,ReplicationInstanceClass]"
```
Dans la sortie, prenez note du nom ARN pour l'instance de réplication que vous souhaitez mettre à niveau ; par exemple : `arn:aws:dms:us-east-1:123456789012:rep:6EFQQO6U6EDPRCPKLNPL2SCEEY`
1. Déterminez quelles versions d'instance de réplication sont disponibles à l'aide de la commande suivante.
```
aws dms describe-orderable-replication-instances \
--query "OrderableReplicationInstances[*].[ReplicationInstanceClass,EngineVersion]"
```
Dans la sortie, prenez note du ou des numéros de version du moteur disponibles pour votre classe d’instances de réplication. Vous devriez voir ces informations dans la sortie à partir de l'étape 1.
1. Mettez à niveau l'instance de réplication à l'aide de la commande suivante.
```
aws dms modify-replication-instance \
--replication-instance-arn arn \
--engine-version n.n.n
```
Remplacez *arn* ce qui précède par l'ARN de l'instance de réplication réel de l'étape précédente.
*n.n.n *Remplacez-le par le numéro de version du moteur que vous souhaitez, par exemple : `3.4.5`
**Note**
La mise à niveau de l'instance de réplication prend plusieurs minutes. Vous pouvez afficher le statut de l'instance de réplication à l'aide de la commande suivante.
```
aws dms describe-replication-instances \
--query "ReplicationInstances[*].[ReplicationInstanceIdentifier,ReplicationInstanceStatus]"
```
Lorsque l'instance de réplication est prête, son statut passe à **available**.
# Instances de réplication publiques et privées
Vous pouvez spécifier si une instance de réplication dispose d’une adresse IP publique ou privée que l’instance utilise pour se connecter aux bases de données source et cible.
Une *instance de réplication privée* a une adresse IP privée à laquelle vous ne pouvez pas accéder en dehors du réseau de réplication. Vous utilisez une instance privée lorsque les bases de données source et cible se trouvent sur le même réseau connecté au cloud privé virtuel (VPC) de l’instance de réplication. Le réseau peut être connecté au VPC à l'aide d'un réseau privé virtuel (VPN) ou d'un Direct Connect peering VPC.
Une connexion d'*appairage VPC* est une connexion réseau entre deux. VPCs Il permet le routage en utilisant les adresses IP privées de chaque VPC comme si elles se trouvaient sur le même réseau. Pour de plus amples informations sur l'appairage de VPC, veuillez consulter la section [Appairage de VPC](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-peering.html) dans le *Guide de l'utilisateur Amazon VPC*.
Une *instance de réplication publique* peut utiliser le groupe de sécurité de VPC de l’instance de réplication et l’adresse IP publique de l’instance de réplication ou l’adresse IP publique de la passerelle NAT. Ces connexions forment un réseau que vous utilisez pour la migration des données.
# Adressage IP et types de réseau
AWS DMS crée toujours votre instance de réplication dans un Amazon Virtual Private Cloud (VPC). Lorsque vous créez votre VPC, vous pouvez déterminer l'adressage IP à utiliser : l'un ou l'autre IPv6, IPv4 ou les deux. Ensuite, lorsque vous créez ou modifiez une instance de réplication, vous pouvez spécifier l'utilisation d'un protocole d' IPv4adresse ou d'un protocole d' IPv6 adresse en *mode double pile*.
**IPv4 adresses**
Lorsque vous créez un VPC, vous pouvez spécifier une plage d' IPv4 adresses pour le VPC sous la forme d'un bloc CIDR (Classless Inter-Domain Routing), tel que 10.0.0.0/16. Un groupe de sous-réseaux définit la plage d’adresses IP de ce bloc CIDR. Ces adresses IP peuvent être privées ou publiques.
Une adresse IPv4 privée est une adresse IP qui ne peut pas être atteinte via Internet. Vous pouvez utiliser des adresses IPv4 privées pour la communication entre votre instance de réplication et d’autres ressources, telles que les instances Amazon EC2, dans le même VPC. Chaque instance de réplication dispose d’une adresse IP privée pour la communication dans le VPC.
Une adresse IP publique est une IPv4 adresse accessible depuis Internet. Vous pouvez utiliser des adresses publiques pour la communication entre votre instance de réplication et les ressources sur Internet. Vous contrôlez si votre instance de réplication reçoit une adresse IP publique.
**Mode double pile et adresses IPv6 **
Lorsque vous avez des ressources qui doivent communiquer avec votre instance de réplication IPv6, utilisez le *mode double pile.* Pour utiliser le mode double pile, assurez-vous qu'un bloc IPv6 CIDR est associé à chaque sous-réseau du groupe de sous-réseaux que vous associez à l'instance de réplication. Vous pouvez créer un nouveau groupe de sous-réseaux de réplication ou modifier un groupe de sous-réseaux de réplication existant pour répondre à cette exigence. Chaque IPv6 adresse est unique au monde. Le bloc IPv6 CIDR de votre VPC est automatiquement attribué à partir du pool IPv6 d'adresses Amazon. Vous ne pouvez pas choisir la plage vous-même.
Le DMS désactive l'accès à Internet Gateway pour les IPv6 points de terminaison des instances privées de réplication en mode double pile. DMS fait cela pour garantir que vos IPv6 points de terminaison sont privés et ne sont accessibles que depuis votre VPC.
Vous pouvez utiliser la AWS DMS console pour créer ou modifier une instance de réplication et spécifier le mode double pile dans la section **Type de réseau**. L’image suivante présente la section **Network type** (Type de réseau) dans la console.
![\[AWS Type de réseau du Service de Migration de Base de Données\]](http://docs.aws.amazon.com/fr_fr/dms/latest/userguide/images/datarep-network-type.png)
**Références**
+ Pour obtenir des informations sur le mode IPv4 et IPv6 les adresses, consultez la section [Adressage IP](https://docs.aws.amazon.com/vpc/latest/userguide/how-it-works.html#vpc-ip-addressing) dans le *guide de l'utilisateur Amazon VPC*.
+ Pour plus d’informations sur la création d’une instance de réplication à l’aide du mode double pile, consultez [Création d'une instance de réplication](CHAP_ReplicationInstance.Creating.md).
+ Pour plus d’informations sur la modification d’une instance de réplication, consultez [Modification d'une instance de réplication](CHAP_ReplicationInstance.Modifying.md).
# Configuration d'un réseau pour une instance de réplication
AWS DMS crée toujours l'instance de réplication dans un VPC basé sur Amazon VPC. Vous spécifiez le VPC dans lequel votre instance de réplication est située. Vous pouvez utiliser votre VPC par défaut pour votre compte et votre AWS région, ou vous pouvez créer un nouveau VPC.
Veillez à ce que l’interface réseau Elastic allouée pour le VPC de votre instance de réplication soit associée à un groupe de sécurité. Veillez également à ce que les règles de ce groupe de sécurité autorisent tout le trafic sur tous les ports à quitter (sortir) le VPC. Cette approche permet la communication de l’instance de réplication vers vos points de terminaison de base de données source et cible, si les bonnes règles de trafic sortant sont activées sur les points de terminaison. Nous recommandons l'utilisation des paramètres par défaut pour les points de terminaison, qui autorisent le trafic sortant sur tous les ports vers toutes les adresses.
Les points de terminaison source et cible accèdent à l'instance de réplication située à l'intérieur du VPC en se connectant au VPC ou en étant à l'intérieur du VPC. Les points de terminaison de base de données doivent inclure des listes de contrôle d'accès réseau (ACLs) et des règles de groupe de sécurité (le cas échéant) qui autorisent l'accès entrant depuis l'instance de réplication. La façon dont vous configurez cela dépend de la configuration réseau que vous utilisez. Vous pouvez utiliser le groupe de sécurité de VPC de l’instance de réplication, l’adresse IP privée ou publique de l’instance de réplication ou l’adresse IP publique de la passerelle NAT. Ces connexions forment un réseau que vous utilisez pour la migration des données.
**Note**
Comme une adresse IP peut changer à la suite de modifications apportées à l’infrastructure sous-jacente, nous vous recommandons d’utiliser la plage d’adresses CIDR d’un VPC ou de router le trafic sortant de votre instance de réplication via une adresse IP Elastic associée à une passerelle NAT. Pour plus d'informations sur la création d'un VPC, y compris d'un bloc CIDR, consultez [Work with VPCs and subnets](https://docs.aws.amazon.com/vpc/latest/userguide/working-with-vpcs.html) dans le guide de l'utilisateur d'*Amazon Virtual Private Cloud*. Pour plus d’informations sur les adresses IP Elastic, consultez [Adresses IP Elastic](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/elastic-ip-addresses-eip.html) dans le *Guide de l’utilisateur Amazon Elastic Compute Cloud*.
## Configurations réseau pour la migration de base de données
Vous pouvez utiliser différentes configurations réseau avec AWS Database Migration Service. Voici quelques configurations courantes pour un réseau utilisé pour la migration de base de données.
**Topics**
+ [Configuration avec tous les composants de migration de base de données dans un VPC](#CHAP_ReplicationInstance.VPC.Configurations.ScenarioAllVPC)
+ [Configuration avec plusieurs VPCs](#CHAP_ReplicationInstance.VPC.Configurations.ScenarioVPCPeer)
+ [Configuration avec partage VPCs](#CHAP_ReplicationInstance.VPC.Configurations.ScenarioVPCShared)
+ [Configuration d'un réseau vers un VPC à l'aide Direct Connect d'un VPN](#CHAP_ReplicationInstance.VPC.Configurations.ScenarioDirect)
+ [Configuration d'un réseau à un VPC avec Internet](#CHAP_ReplicationInstance.VPC.Configurations.ScenarioInternet)
+ [Configuration avec une instance de base de données RDS ne figurant pas dans un VPC vers une instance de base de données dans un VPC en utilisant ClassicLink](#CHAP_ReplicationInstance.VPC.Configurations.ClassicLink)
+ [Configuration d'un réseau se connectant à AWS des services](#CHAP_ReplicationInstance.VPC.Configurations.networkconnecting)
+ [Configuration d'un réseau se connectant à des AWS services à l'aide de points de terminaison VPC](#CHAP_ReplicationInstance.VPC.Configurations.vpcendpoints)
+ [Configuration d'un réseau se connectant à AWS des services via Internet](#CHAP_ReplicationInstance.VPC.Configuration.networkconnectingusinginternet)
Dans la mesure du possible, nous vous recommandons de créer une instance de réplication DMS dans la même région que votre point de terminaison cible, et dans le même VPC ou sous-réseau que votre point de terminaison cible.
### Configuration avec tous les composants de migration de base de données dans un VPC
Le réseau le plus simple pour la migration de base de données consiste à rassembler le point de terminaison source, l'instance de réplication et le point de terminaison cible dans le même VPC. Cette configuration convient si vos points de terminaison sources et cibles se trouvent sur une instance de base de données Amazon RDS ou une instance Amazon EC2.
L'illustration suivante présente une configuration dans laquelle une base de données sur une instance Amazon EC2 se connecte à l'instance de réplication et les données sont migrées vers une instance de base de données Amazon RDS.
![\[AWS Exemple de VPC tout-en-un du Service de migration de base de données\]](http://docs.aws.amazon.com/fr_fr/dms/latest/userguide/images/datarep-scenarioAllVPC.png)
Le groupe de sécurité du VPC utilisé dans cette configuration doit autoriser le trafic entrant sur le port de base de données à partir de l'instance de réplication. Vous pouvez effectuer cette opération de plusieurs manières. Vous pouvez vous assurer que le groupe de sécurité utilisé par l’instance de réplication ait accès aux points de terminaison. Vous pouvez également autoriser la plage CIDR du VPC, l’adresse IP Elastic de la passerelle NAT ou l’adresse IP privée de l’instance de réplication si vous en utilisez une. Toutefois, nous vous déconseillons d’utiliser l’adresse IP privée de l’instance de réplication, car elle peut interrompre la réplication en cas de modification de l’adresse IP de réplication.
### Configuration avec plusieurs VPCs
Si votre point de terminaison source et votre point de terminaison cible sont différents VPCs, vous pouvez créer votre instance de réplication dans l'un des. VPCs Vous pouvez ensuite lier les deux VPCs en utilisant le peering VPC.
Une connexion d'appairage VPC est une connexion réseau entre deux VPC VPCs qui permet le routage en utilisant les adresses IP privées de chaque VPC comme s'ils se trouvaient sur le même réseau. Vous pouvez créer une connexion d'appairage VPC entre votre propre compte VPCs, avec un VPC d'un autre AWS compte ou avec un VPC d'une autre région. AWS Pour de plus amples informations sur l'appairage de VPC, veuillez consulter la section [Appairage de VPC](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-peering.html) dans le *Guide de l'utilisateur Amazon VPC*.
L'illustration suivante présente un exemple de configuration utilisant l'appairage de VPC. Ici, la base de données source sur une instance Amazon EC2 dans un VPC se connecte par appairage de VPC à un VPC. Ce VPC contient l’instance de réplication et la base de données cible sur une instance de base de données Amazon RDS.
![\[AWS Instance de réplication du Service de Migration de base de données\]](http://docs.aws.amazon.com/fr_fr/dms/latest/userguide/images/datarep-scenarioVPCPeer.png)
Pour mettre en œuvre l’appairage de VPC, suivez les instructions figurant dans [Utilisation de connexions d’appairage de VPC](https://docs.aws.amazon.com/vpc/latest/peering/working-with-vpc-peering.html), dans la documentation *Amazon Virtual Private Cloud – Appairage de VPC*. Assurez-vous que la table de routage d’un VPC contient le bloc CIDR de l’autre. Par exemple, si le VPC A utilise la destination 10.0.0.0/16 et que le VPC B utilise la destination 172.31.0.0, la table de routage du VPC A doit contenir 172.31.0.0 et la table de routage du VPC B doit contenir 10.0.0.0/16. Pour en savoir plus, consultez [Mise à jour de vos tables de routage pour une connexion d’appairage de VPC](https://docs.aws.amazon.com/vpc/latest/peering/vpc-peering-routing.html) dans la documentation *Amazon Virtual Private Cloud – Appairage de VPC*.
Les groupes de sécurité de VPC utilisés dans cette configuration doivent autoriser le trafic entrant sur le port de base de données à partir de l’instance de réplication, ou doivent autoriser le trafic entrant sur le bloc CIDR du VPC en cours d’appairage.
### Configuration avec partage VPCs
AWS DMS traite les sous-réseaux partagés avec un compte client participant au sein d'une organisation comme les sous-réseaux ordinaires d'un même compte. Vous trouverez ci-dessous une description du mode de gestion AWS DMS VPCs, des sous-réseaux et de la manière dont vous pouvez utiliser le partage VPCs.
Vous pouvez configurer votre configuration réseau pour qu'elle fonctionne dans des sous-réseaux personnalisés ou VPCs en créant `ReplicationSubnetGroup` des objets. Lorsque vous créez un `ReplicationSubnetGroup`, vous pouvez choisir de spécifier des sous-réseaux d’un VPC spécifique dans votre compte. La liste des sous-réseaux que vous spécifiez doit inclure au moins deux sous-réseaux situés dans des zones de disponibilité distinctes, et tous les sous-réseaux doivent se trouver dans le même VPC. Lors de la création d'un`ReplicationSubnetGroup`, les clients spécifient uniquement des sous-réseaux. AWS DMS déterminera le VPC en votre nom, car chaque sous-réseau est lié à exactement un VPC.
Lorsque vous créez un AWS DMS `ReplicationInstance` ou un AWS DMS `ReplicationConfig`, vous pouvez choisir de spécifier `ReplicationSubnetGroup` and/or un groupe de sécurité VPC dans lequel la réplication `ReplicationInstance` ou sans serveur fonctionne. S'il n'est pas spécifié, AWS DMS choisit le client par défaut `ReplicationSubnetGroup` (qui est AWS DMS créé en votre nom s'il n'est pas spécifié pour tous les sous-réseaux du VPC par défaut) et le groupe de sécurité VPC par défaut.
Vous pouvez choisir d’exécuter vos migrations dans une zone de disponibilité que vous spécifiez ou dans l’une des zones de disponibilité de votre élément `ReplicationSubnetGroup`. Lorsque vous AWS DMS tentez de créer une instance de réplication ou de démarrer une réplication sans serveur, les zones de disponibilité de vos sous-réseaux sont converties en zones de disponibilité dans le compte de service principal, afin de garantir le lancement des instances dans la bonne zone de disponibilité, même si les mappages de zones de disponibilité ne sont pas identiques entre les deux comptes.
Si vous utilisez un VPC partagé, vous devez vous assurer de créer des objets `ReplicationSubnetGroup` qui correspondent aux sous-réseaux que vous souhaitez utiliser à partir d’un VPC partagé. Lorsque vous créez un élément `ReplicationInstance` ou `ReplicationConfig`, vous devez spécifier un élément `ReplicationSubnetGroup` pour le VPC partagé et spécifier un groupe de sécurité de VPC que vous avez créé pour votre VPC partagé avec votre demande de création.
Notez ce qui suit à propos de l’utilisation d’un VPC partagé :
+ Le propriétaire du VPC ne peut pas partager une ressource avec un participant, mais celui-ci peut créer une ressource de service dans le sous-réseau du propriétaire.
+ Le propriétaire du VPC ne peut pas accéder à une ressource (telle qu’une instance de réplication) créée par le participant, car toutes les ressources sont spécifiques au compte. Toutefois, tant que vous créez l’instance de réplication dans le VPC partagé, elle peut accéder aux ressources du VPC quel que soit le compte propriétaire, à condition que le point de terminaison ou la tâche de réplication dispose des autorisations appropriées.
+ Les ressources étant spécifiques à un compte, les autres participants ne peuvent pas accéder aux ressources appartenant à d’autres comptes. Vous ne pouvez accorder aucune autorisation à d’autres comptes pour leur permettre d’accéder aux ressources créées dans le VPC partagé avec votre compte.
### Configuration d'un réseau vers un VPC à l'aide Direct Connect d'un VPN
Les réseaux distants peuvent se connecter à un VPC à l'aide de plusieurs options telles que AWS Direct Connect ou une connexion VPN logicielle ou matérielle. Ces options sont souvent utilisées pour intégrer des services sur site existants, comme la surveillance, l’authentification, la sécurité, les données ou d’autres systèmes, en étendant un réseau interne dans le cloud AWS . Grâce à ce type d’extension de réseau, vous pouvez en toute transparence vous connecter à des ressources hébergées par AWS, telles qu’un VPC.
L'illustration suivante présente une configuration dans laquelle le point de terminaison source est une base de données sur site dans un centre de données d'entreprise. Il est connecté via Direct Connect ou un VPN à un VPC qui contient l’instance de réplication et une base de données cible sur une instance de base de données Amazon RDS.
![\[AWS Instance de réplication du Service de Migration de base de données\]](http://docs.aws.amazon.com/fr_fr/dms/latest/userguide/images/datarep-scenarioDirect.png)
Dans cette configuration, le groupe de sécurité de VPC doit inclure une règle de routage qui envoie à un hôte le trafic destiné à la plage CIDR d’un VPC ou à une adresse IP spécifique. Cet hôte doit être en mesure d'acheminer le trafic du VPC vers le VPN sur site. Dans ce cas, l’hôte NAT inclut ses propres paramètres de groupe de sécurité. Ces paramètres doivent autoriser le trafic provenant de la plage CIDR de VPC de l’instance de réplication, d’une adresse IP privée ou du groupe de sécurité dans l’instance NAT. Toutefois, nous vous déconseillons d’utiliser l’adresse IP privée de l’instance de réplication, car elle peut interrompre la réplication en cas de modification de l’adresse IP de réplication.
### Configuration d'un réseau à un VPC avec Internet
Si vous n'utilisez pas de VPN ou Direct Connect si vous ne vous connectez pas à AWS des ressources, vous pouvez utiliser Internet pour migrer votre base de données. Dans ce cas, vous pouvez effectuer une migration vers une instance Amazon EC2 ou vers une instance de base de données Amazon RDS. Cette configuration implique une instance de réplication publique dans un VPC avec une passerelle Internet qui contient le point de terminaison cible et l'instance de réplication.
![\[AWS Instance de réplication du Service de Migration de base de données\]](http://docs.aws.amazon.com/fr_fr/dms/latest/userguide/images/datarep-scenarioInternet.png)
Pour ajouter une passerelle Internet à votre VPC, veuillez consulter [Attachement d'une passerelle Internet](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Internet_Gateway.html#Add_IGW_Attach_Gateway) dans le *Guide de l'utilisateur Amazon VPC*.
La table de routage du VPC doit inclure des règles de routage qui envoient par défaut le trafic non destiné au VPC vers la passerelle Internet. Dans cette configuration, la connexion au point de terminaison semble venir de l'adresse IP publique de l'instance de réplication et non pas de l'adresse IP privée. Pour plus d’informations, consultez [Tables de routage de VPC](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Route_Tables.html) dans le *Guide de l’utilisateur Amazon VPC*.
### Configuration avec une instance de base de données RDS ne figurant pas dans un VPC vers une instance de base de données dans un VPC en utilisant ClassicLink
| |
| --- |
| Nous retirons EC2-Classic le 15 août 2022. Nous vous recommandons de migrer d'EC2-Classic vers un VPC. Pour plus d’informations, consultez [Migrer d’EC2-Classic vers un VPC](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/vpc-migrate.html) dans le Guide de l’utilisateur Amazon EC2 et le blog [EC2-Classic Networking is Retiring – Here’s How to Prepare](https://aws.amazon.com/blogs/aws/ec2-classic-is-retiring-heres-how-to-prepare/) (Se préparer au retrait de la mise en réseau EC2-Classic). |
Pour connecter une instance de base de données Amazon RDS ne se trouvant pas dans un VPC à un serveur de réplication DMS et une instance de base de données dans un VPC, vous pouvez ClassicLink utiliser un serveur proxy.
ClassicLink vous permet de lier une instance de base de données EC2-Classic à un VPC de votre compte, dans la même région. AWS Une fois que vous avez créé le lien, l'instance DB source peut communiquer avec l'instance de réplication à l'intérieur du VPC à l'aide de leurs adresses IP privées.
Étant donné que l'instance de réplication du VPC ne peut pas accéder directement à l'instance de base de données source sur la plate-forme EC2-Classic à l'aide d' ClassicLinkun serveur proxy. Le serveur proxy connecte l'instance de base de données source au VPC contenant l'instance de réplication et l'instance de base de données cible. Le serveur proxy est utilisé ClassicLink pour se connecter au VPC. Le réacheminement de port sur le serveur proxy permet la communication entre l'instance de base de données source et l'instance de base de données cible dans le VPC.
![\[AWS Service de migration de base de données à l'aide de ClassicLink\]](http://docs.aws.amazon.com/fr_fr/dms/latest/userguide/images/datarep-scenarioClassicLink.png)
#### Utilisation ClassicLink avec AWS Database Migration Service
Vous pouvez connecter une instance de base de données Amazon RDS qui ne se trouve pas dans un VPC à un serveur de réplication DMS et AWS une instance de base de données qui se trouve dans un VPC. Pour ce faire, vous pouvez utiliser Amazon EC2 ClassicLink avec un serveur proxy.
La procédure suivante indique comment l'utiliser ClassicLink à cette fin. Cette procédure connecte une instance de base de données source Amazon RDS qui ne se trouve pas dans un VPC à un VPC contenant une instance de réplication DMS et AWS une instance de base de données cible.
+ Créez une instance de réplication AWS DMS dans un VPC. (Toutes les instances de réplication sont créées dans VPCs.)
+ Associez un groupe de sécurité de VPC à l’instance de réplication et à l’instance de base de données cible. Lorsque deux instances partagent un groupe de sécurité VPC, elles peuvent communiquer l'une avec l'autre par défaut.
+ Configurez un serveur proxy sur une instance EC2 classique.
+ Créez une connexion ClassicLink entre le serveur proxy et le VPC.
+ Créez des points de terminaison AWS DMS pour les bases de données source et cible.
+ Créez une tâche AWS DMS.
**À utiliser pour ClassicLink migrer une base de données sur une instance de base de données ne faisant pas partie d'un VPC vers une base de données sur une instance de base de données d'un VPC**
1. Créez une instance de réplication AWS DMS et attribuez un groupe de sécurité VPC :
1. Connectez-vous à la AWS DMS console AWS Management Console et ouvrez-la à l'adresse [https://console.aws.amazon.com/dms/v2/](https://console.aws.amazon.com/dms/v2/).
Si vous êtes connecté en tant qu'utilisateur Gestion des identités et des accès AWS (IAM), assurez-vous de disposer des autorisations d'accès AWS DMS appropriées. Pour plus d'informations sur les autorisations requises pour la migration de base de données, consultez [Autorisations IAM nécessaires pour utiliser AWS DMS](security-iam.md#CHAP_Security.IAMPermissions).
1. Sur la page **Tableau de bord**, sélectionnez **Instance de réplication**. Suivez les instructions de la page [Étape 1 : créer une instance de réplication à l'aide de la AWS DMS console](CHAP_GettingStarted.Replication.md#CHAP_GettingStarted.Replication.ReplicationInstance) pour créer une instance de réplication.
1. Après avoir créé l'instance de réplication AWS DMS, ouvrez la console de service EC2. Choisissez **Interfaces réseau** dans le volet de navigation.
1. Choisissez l'*DMSNetworkinterface*, puis choisissez **Modifier les groupes de sécurité** dans le menu **Actions**.
1. Choisissez le groupe de sécurité que vous voulez utiliser pour l’instance de réplication et l’instance de base de données cible.
1. Associez le groupe de sécurité de la dernière étape à l’instance de base de données cible.
1. Ouvrez la console de service Amazon RDS. Choisissez **Instances** dans le panneau de navigation.
1. Choisissez l’instance de base de données cible. Pour **Actions d’instance**, choisissez **Modifier**.
1. Pour le paramètre **Groupe de sécurité**, choisissez le groupe de sécurité que vous avez utilisé à l’étape précédente.
1. Choisissez **Continuer**, puis **Modifier l’instance de base de données**.
1. Étape 3 : Configurer un serveur proxy sur une instance EC2 classique à l'aide de NGINX. Utilisez une AMI de votre choix pour lancer une instance EC2 classique. L'exemple suivant est basée sur l'AMI Ubuntu Server 14.04 LTS (HVM).
Pour configurer un serveur proxy sur une instance EC2 classique
1. Connectez-vous à l'instance EC2 classique et installez NGINX à l'aide des commandes suivantes :
```
Prompt> sudo apt-get update
Prompt> sudo wget http://nginx.org/download/nginx-1.9.12.tar.gz
Prompt> sudo tar -xvzf nginx-1.9.12.tar.gz
Prompt> cd nginx-1.9.12
Prompt> sudo apt-get install build-essential
Prompt> sudo apt-get install libpcre3 libpcre3-dev
Prompt> sudo apt-get install zlib1g-dev
Prompt> sudo ./configure --with-stream
Prompt> sudo make
Prompt> sudo make install
```
1. Modifiez le fichier de démon NGINX `/etc/init/nginx.conf`, en utilisant le code suivant :
```
# /etc/init/nginx.conf – Upstart file
description "nginx http daemon"
author "email"
start on (filesystem and net-device-up IFACE=lo)
stop on runlevel [!2345]
env DAEMON=/usr/local/nginx/sbin/nginx
env PID=/usr/local/nginx/logs/nginx.pid
expect fork
respawn
respawn limit 10 5
pre-start script
$DAEMON -t
if [ $? -ne 0 ]
then exit $?
fi
end script
exec $DAEMON
```
1. Créez un fichier de configuration NGINX à l'adresse `/usr/local/nginx/conf/nginx.conf`. Dans le fichier de configuration, ajoutez les éléments suivants :
```
# /usr/local/nginx/conf/nginx.conf - NGINX configuration file
worker_processes 1;
events {
worker_connections 1024;
}
stream {
server {
listen DB instance port number;
proxy_pass DB instance identifier:DB instance port number;
}
}
```
1. À partir de la ligne de commande, démarrez NGINX à l'aide des commandes suivantes :
```
Prompt> sudo initctl reload-configuration
Prompt> sudo initctl list | grep nginx
Prompt> sudo initctl start nginx
```
1. Créez une ClassicLink connexion entre le serveur proxy et le VPC cible qui contient l'instance de base de données cible et l'instance de réplication :
1. Ouvrez la console EC2 et choisissez l’instance EC2 Classic qui exécute le serveur proxy.
1. Pour **Actions**, choisissez **ClassicLink**, puis choisissez **Lier au VPC**.
1. Choisissez le groupe de sécurité que vous avez utilisé précédemment dans cette procédure.
1. Choisissez **Lien vers le VPC**.
1. Étape 5 : Créez des points de terminaison AWS DMS à l'aide de la procédure décrite à l'adresse. [Étape 2 : Spécifier les points de terminaison sources et cibles](CHAP_GettingStarted.Replication.md#CHAP_GettingStarted.Replication.Endpoints) Veillez à utiliser le nom d’hôte DNS EC2 interne du proxy comme nom de serveur lorsque vous spécifiez le point de terminaison source.
1. Créez une tâche AWS DMS à l'aide de la procédure décrite dans[Étape 3 : Créer une tâche et migrer les données](CHAP_GettingStarted.Replication.md#CHAP_GettingStarted.Replication.Tasks).
### Configuration d'un réseau se connectant à AWS des services
Pour vous connecter aux AWS services, utilisez une connexion Internet ou des points de terminaison Virtual Private Cloud (VPC). Cela s'applique lorsque :
Vos points de terminaison source ou cible utilisent AWS des services tels que :
+ AWS Secrets Manager
+ Amazon Simple Storage Service
Votre point de terminaison cible est un AWS service tel que :
+ Amazon S3
+ Amazon Kinesis
+ Amazon DynamoDB
+ Amazon Redshift
+ Amazon OpenSearch Service
+ Amazon Athena
### Configuration d'un réseau se connectant à des AWS services à l'aide de points de terminaison VPC
Les points de terminaison VPC fournissent des connexions sécurisées entre vos AWS ressources, connectant les ressources VPC aux AWS services sans avoir besoin d'un accès Internet. Vos applications situées dans des sous-réseaux privés peuvent accéder aux AWS services tout en restant au sein du AWS réseau, ce qui améliore la sécurité et réduit le temps de latence. Veuillez vous référer à l'image ci-dessous :
![\[\]](http://docs.aws.amazon.com/fr_fr/dms/latest/userguide/images/aws_dms_vpc_endpoints.jpg)
Pour plus d'informations, consultez [Configuration des points de terminaison VPC en tant que points de terminaison AWS DMS source et cible et Configuration des points de terminaison](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_VPC_Endpoints.html) VPC du [AWS DMS gestionnaire de secrets](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Advanced.Endpoints.secretsmanager.html).
### Configuration d'un réseau se connectant à AWS des services via Internet
Une instance de réplication a besoin d'un accès Internet pour se connecter aux AWS ressources lors de la migration des données.
Pour plus d'informations sur les sous-réseaux privés et publics au sein d'un VPC, [consultez Exemple : VPC avec serveurs dans des sous-réseaux privés et NAT dans](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-example-private-subnets-nat.html) le guide de l'utilisateur d'*Amazon Virtual Private Cloud*. Vous devez vous assurer de tester la configuration de votre réseau pour vérifier la connectivité avec tout service requis.
## Créer groupe de sous-réseaux de réplication
Dans le cadre du réseau à utiliser pour la migration de bases de données, vous devez spécifier les sous-réseaux de votre cloud privé virtuel (VPC) que vous avez l’intention d’utiliser. Ce VPC doit être basé sur le service Amazon VPC. Un *sous-réseau* est une plage d'adresses IP dans votre VPC dans une Zone de disponibilité donnée. Ces sous-réseaux peuvent être répartis entre les zones de disponibilité de la AWS région où se trouve votre VPC.
Lorsque vous créez une instance de réplication ou un profil d'instance dans la console AWS DMS, vous pouvez utiliser le sous-réseau de votre choix.
Vous créez un groupe de sous-réseaux de réplication pour définir les sous-réseaux à utiliser. Vous devez spécifier les sous-réseaux dans au moins deux zones de disponibilité.
**Pour créer un groupe de sous-réseaux de réplication**
1. Connectez-vous à la AWS DMS console AWS Management Console et ouvrez-la à l'adresse [https://console.aws.amazon.com/dms/v2/](https://console.aws.amazon.com/dms/v2/).
Si vous êtes connecté en tant qu’utilisateur IAM, vous devez détenir les autorisations appropriées pour accéder à AWS DMS. Pour plus d'informations sur les autorisations requises pour la migration de base de données, consultez [Autorisations IAM nécessaires pour utiliser AWS DMS](security-iam.md#CHAP_Security.IAMPermissions).
1. Dans le panneau de navigation, choisissez **Subnet groups (Groupes de sous-réseaux)**.
1. Choisissez **Créer groupe de sous-réseaux**.
1. Sur la page **Créer un groupe de sous-réseaux de réplication**, spécifiez les informations de votre groupe de sous-réseaux de réplication. Le tableau suivant décrit les paramètres.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/dms/latest/userguide/CHAP_ReplicationInstance.VPC.html)
1. Choisissez **Créer groupe de sous-réseaux**.
## Résolution des points de terminaison de domaine à l’aide de DNS
Généralement, une instance de AWS DMS réplication utilise le résolveur DNS (Domain Name System) d'une instance Amazon EC2 pour résoudre les points de terminaison du domaine. Si vous avez besoin d’une résolution DNS, vous pouvez utiliser Amazon Route 53 Resolver. Pour plus d’informations sur l’utilisation du résolveur DNS Route 53, consultez [Mise en route avec Route 53 Resolver](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver-getting-started.html).
Pour en savoir plus sur la façon d’utiliser votre propre serveur de noms sur site pour résoudre certains points de terminaison à l’aide d’Amazon Route 53 Resolver, consultez [Utilisation de votre propre serveur de noms sur site](CHAP_BestPractices.md#CHAP_BestPractices.Rte53DNSResolver).
# Définition d'une clé de chiffrement pour une instance de réplication
AWS Le DMS chiffre le stockage utilisé par une instance de réplication et les informations de connexion du point de terminaison. Pour chiffrer le stockage utilisé par une instance de réplication, AWS DMS utilise un élément AWS KMS key propre à votre AWS compte. Vous pouvez afficher et gérer cette clé KMS avec AWS Key Management Service (AWS KMS). Vous pouvez utiliser la clé KMS par défaut de votre compte (`aws/dms`) ou une clé KMS que vous créez. Si vous possédez déjà une clé de AWS KMS chiffrement, vous pouvez également l'utiliser pour le chiffrement.
Vous pouvez spécifier votre propre clé de chiffrement en fournissant un identifiant de clé KMS pour chiffrer vos ressources AWS DMS. Lorsque vous spécifiez votre propre clé de chiffrement, le compte d'utilisateur utilisé pour effectuer la migration de base de données doit avoir accès à cette clé. Pour plus d'informations sur la création de vos propres clés de chiffrement et pour donner aux utilisateurs l'accès à une clé de chiffrement, consultez le *[Manuel du développeur AWS KMS](https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html)*.
Si vous ne spécifiez pas d'identifiant de clé KMS, AWS DMS utilise votre clé de chiffrement par défaut. KMS crée la clé de chiffrement par défaut pour AWS DMS pour votre AWS compte. Votre AWS compte possède une clé de chiffrement par défaut différente pour chaque AWS région.
Pour gérer les clés utilisées pour chiffrer vos ressources AWS DMS, vous utilisez. AWS KMS Vous pouvez le trouver AWS KMS en AWS Management Console recherchant **KMS** dans le volet de navigation.
AWS KMS combine du matériel et des logiciels sécurisés et hautement disponibles pour fournir un système de gestion des clés adapté au cloud. À l'aide de AWS KMS, vous pouvez créer des clés de chiffrement et définir les politiques qui contrôlent la manière dont ces clés peuvent être utilisées. AWS KMS prend en charge AWS CloudTrail, afin que vous puissiez auditer l'utilisation des clés pour vérifier que les clés sont utilisées de manière appropriée. Vos AWS KMS clés peuvent être utilisées en combinaison avec AWS DMS et d'autres AWS services pris en charge. Les services AWS pris en charge incluent Amazon RDS, Amazon S3, Amazon Elastic Block Store (Amazon EBS) et Amazon Redshift.
Lorsque vous avez créé vos ressources AWS DMS avec une clé de chiffrement spécifique, vous ne pouvez pas modifier la clé de chiffrement de ces ressources. Assurez-vous de déterminer vos exigences en matière de clé de chiffrement avant de créer vos ressources AWS DMS.
# Création d'une instance de réplication
Dans le cadre de la migration d’une base de données, votre première tâche consiste à créer une instance de réplication. Cette instance de réplication nécessite suffisamment de stockage et de puissance de traitement pour effectuer les tâches que vous attribuez et pour migrer les données de la base de données source vers la base de données cible. La taille de cette instance varie en fonction de la quantité de données que vous devez migrer et des tâches que vous souhaitez que l'instance effectue. Pour plus d'informations sur les instances de réplication, consultez la page [Utilisation d'une instance AWS DMS de réplication](CHAP_ReplicationInstance.md).
**Pour créer une instance de réplication à l'aide de la AWS console**
1. Choisissez **les instances de réplication** dans le volet de navigation de la AWS DMS console, puis sélectionnez **Créer une instance de réplication**.
1. Sur la page **Créer une instance de réplication**, spécifiez vos informations d'instance de réplication. Le tableau suivant décrit les paramètres que vous pouvez utiliser.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/dms/latest/userguide/CHAP_ReplicationInstance.Creating.html)
1. Cliquez sur l'onglet **Avancé** pour définir des valeurs pour les paramètres de réseau et de chiffrement si vous en avez besoin. Le tableau suivant décrit les paramètres.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/dms/latest/userguide/CHAP_ReplicationInstance.Creating.html)
1. Spécifiez les paramètres de **Maintenance**. Le tableau suivant décrit les paramètres. Pour plus d'informations sur les paramètres de maintenance, consultez [Utilisation de la fenêtre AWS DMS de maintenance](CHAP_ReplicationInstance.MaintenanceWindow.md).
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/dms/latest/userguide/CHAP_ReplicationInstance.Creating.html)
1. Choisissez **Créer instance de réplication**.
# Modification d'une instance de réplication
Vous pouvez modifier les paramètres d'une instance de réplication pour, par exemple, modifier la classe d'instance ou augmenter l'espace de stockage.
Lorsque vous modifiez une instance de réplication, vous pouvez appliquer les modifications immédiatement. Pour appliquer immédiatement les modifications, choisissez l’option **Appliquer immédiatement les modifications** dans la AWS Management Console. Vous pouvez également utiliser le `--apply-immediately` paramètre lorsque vous appelez AWS CLI le ou définissez le `ApplyImmediately` paramètre sur `true` lorsque vous utilisez l'API DMS.
Si vous ne choisissez pas d'appliquer les modifications immédiatement, les modifications sont placées dans la file d'attente des modifications en attente. Au cours de la fenêtre de maintenance suivante, les modifications en attente sont appliquées.
**Note**
Si vous choisissez d'appliquer les modifications immédiatement, les modifications placées dans la file d'attente des modifications en attente sont également appliquées. Si des modifications en attente ont besoin d'un temps d'arrêt, le choix de l'option **Appliquer immédiatement les modifications** peut entraîner un temps d'arrêt imprévu.
**Pour modifier une instance de réplication à l'aide de la AWS console**
1. Connectez-vous à la AWS DMS console AWS Management Console et ouvrez-la à l'adresse [https://console.aws.amazon.com/dms/v2/](https://console.aws.amazon.com/dms/v2/).
1. Dans le volet de navigation, sélectionnez **Instances de réplication**.
1. Choisissez l'instance de réplication que vous souhaitez modifier. Le tableau suivant décrit les modifications que vous pouvez effectuer.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/dms/latest/userguide/CHAP_ReplicationInstance.Modifying.html)
## Bonnes pratiques lors de la modification d'une instance de réplication
Lorsque vous modifiez une instance de réplication, le respect de ces bonnes pratiques permet de garantir une mise à jour réussie avec un impact minimal sur vos flux de travail de migration. Suivez les étapes clés suivantes avant, pendant et après les modifications afin de préserver l'intégrité des données et l'efficacité opérationnelle tout au long du processus.
**Calendrier de modification du plan :**
+ Vous pouvez appliquer les modifications immédiatement ou les planifier pour la prochaine fenêtre de maintenance.
+ Planifiez pendant les périodes de faible trafic afin de minimiser l'impact.
**Étapes de prémodification :**
+ Arrêtez toutes les tâches de réplication actives.
+ Vérifiez que toutes les tâches ont été correctement arrêtées.
+ Documentez les paramètres actuels des tâches de configuration.
**Lors de la modification :**
+ Surveillez la progression des modifications.
+ Attendez le statut « Disponible » avant de continuer.
**Étapes postérieures à la modification :**
+ Reprenez toutes les tâches précédemment arrêtées.
+ Vérifiez que les tâches s'exécutent correctement.
# redémarrage d'une instance de réplication.
Vous pouvez redémarrer une instance AWS DMS de réplication pour redémarrer le moteur de réplication. Le redémarrage entraîne une interruption momentanée de l'instance de réplication. À cette occasion, le statut de l'instance est défini sur **Redémarrage**. Si l' AWS DMS instance est configurée pour le mode multi-AZ, le redémarrage peut être effectué avec un basculement. Un AWS DMS événement est créé lorsque le redémarrage est terminé.
Si votre AWS DMS instance est un déploiement multi-AZ, vous pouvez forcer un basculement planifié d'une zone de AWS disponibilité à une autre lors du redémarrage. Lorsque vous forcez un basculement planifié de votre AWS DMS instance, AWS DMS ferme les connexions actives sur l'instance actuelle avant de passer automatiquement à une instance de secours dans une autre zone de disponibilité. Le redémarrage à l'aide d'un basculement planifié vous permet de simuler un événement de basculement planifié d'une AWS DMS instance, par exemple lors du dimensionnement de la classe d'instance de réplication.
**Note**
Lorsqu’un redémarrage force un basculement d’une zone de disponibilité à une autre, le changement de zone de disponibilité peut ne pas être reflété pendant quelques minutes. Ce décalage apparaît dans et dans les appels à l' AWS DMS API AWS CLI and. AWS Management Console
Si des tâches de migration s’exécutent sur l’instance de réplication au moment du redémarrage, aucune perte de données ne se produit, mais la tâche s’arrête et son statut passe à l’état d’erreur.
Si les tables de la tâche de migration sont en cours de chargement en bloc (phase de chargement complet) et n’ont pas encore démarré, elles passent à un état d’erreur. En revanche, les tables qui sont complètes à ce moment-là restent à un état complet. Lorsqu’un redémarrage se produit pendant la phase de chargement complet, nous vous recommandons d’effectuer l’une des étapes ci-dessous.
+ Supprimer de la tâche les tables dont l’état est complet, puis redémarrer la tâche avec les tables restantes.
+ Créer une nouvelle tâche avec des tables en état d’erreur et des tables en attente.
Si les tables comprises dans la tâche de migration se trouvent dans la phase de réplication continue, la tâche reprend une fois que le redémarrage est terminé.
Vous ne pouvez pas redémarrer votre instance de AWS DMS réplication si son statut n'est pas **disponible**. Votre AWS DMS instance peut être indisponible pour plusieurs raisons, telles qu'une modification demandée précédemment ou une action liée à la fenêtre de maintenance. Le temps nécessaire au redémarrage d'une instance de AWS DMS réplication est généralement court (moins de 5 minutes).
## Redémarrage d'une instance de réplication à l'aide de la console AWS
Pour redémarrer une instance de réplication, utilisez la AWS console.
**Pour redémarrer une instance de réplication à l'aide de la AWS console**
1. Connectez-vous à la AWS DMS console AWS Management Console et ouvrez-la à l'adresse [https://console.aws.amazon.com/dms/v2/](https://console.aws.amazon.com/dms/v2/).
1. Dans le volet de navigation, sélectionnez **Instances de réplication**.
1. Choisissez l'instance de réplication que vous souhaitez redémarrer.
1. Choisissez **Redémarrer**. La boîte de dialogue **Redémarrer l’instance de réplication** s’ouvre.
1. Cochez la case **Redémarrer avec le basculement planifié ?** si vous avez configuré votre instance de réplication pour le déploiement multi-AZ et que vous souhaitez basculer vers une autre zone de disponibilité AWS .
1. Choisissez **Redémarrer**.
## Redémarrage d'une instance de réplication via l'interface de ligne de commande
Pour redémarrer une instance de réplication, utilisez la AWS CLI [https://docs.aws.amazon.com/cli/latest/reference/dms/reboot-replication-instance.html](https://docs.aws.amazon.com/cli/latest/reference/dms/reboot-replication-instance.html)commande avec le paramètre suivant :
+ `--replication-instance-arn`
**Example Exemple de redémarrage simple**
L' AWS CLI exemple suivant redémarre une instance de réplication.
```
aws dms reboot-replication-instance \
--replication-instance-arn arn of my rep instance
```
**Example Exemple de redémarrage simple avec basculement**
L' AWS CLI exemple suivant redémarre une instance de réplication avec basculement.
```
aws dms reboot-replication-instance \
--replication-instance-arn arn of my rep instance \
--force-planned-failover
```
## Redémarrage d'une instance de réplication via l'API
Pour redémarrer une instance de réplication, utilisez l'[https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBInstance.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBInstance.html)action AWS DMS API avec les paramètres suivants :
+ `ReplicationInstanceArn = arn of my rep instance`
**Example Exemple de redémarrage simple**
L'exemple de code suivant redémarre une instance de réplication.
```
1. https://dms.us-west-2.amazonaws.com/
2. ?Action=RebootReplicationInstance
3. &DBInstanceArn=arn of my rep instance
4. &SignatureMethod=HmacSHA256
5. &SignatureVersion=4
6. &Version=2014-09-01
7. &X-Amz-Algorithm=AWS4-HMAC-SHA256
8. &X-Amz-Credential=AKIADQKE4SARGYLE/20140425/us-east-1/dms/aws4_request
9. &X-Amz-Date=20140425T192732Z
10. &X-Amz-SignedHeaders=content-type;host;user-agent;x-amz-content-sha256;x-amz-date
11. &X-Amz-Signature=1dc9dd716f4855e9bdf188c70f1cf9f6251b070b68b81103b59ec70c3e7854b3
```
**Example Exemple de redémarrage simple avec basculement**
L'exemple de code suivant redémarre une instance de réplication et bascule vers une autre zone de AWS disponibilité.
```
1. https://dms.us-west-2.amazonaws.com/
2. ?Action=RebootReplicationInstance
3. &DBInstanceArn=arn of my rep instance
4. &ForcePlannedFailover=true
5. &SignatureMethod=HmacSHA256
6. &SignatureVersion=4
7. &Version=2014-09-01
8. &X-Amz-Algorithm=AWS4-HMAC-SHA256
9. &X-Amz-Credential=AKIADQKE4SARGYLE/20140425/us-east-1/dms/aws4_request
10. &X-Amz-Date=20140425T192732Z
11. &X-Amz-SignedHeaders=content-type;host;user-agent;x-amz-content-sha256;x-amz-date
12. &X-Amz-Signature=1dc9dd716f4855e9bdf188c70f1cf9f6251b070b68b81103b59ec70c3e7854b3
```
# Supprimez une instance de réplication.
Vous pouvez supprimer une instance de AWS DMS réplication lorsque vous avez fini de l'utiliser. Si vous avez des tâches de migration qui utilisent l'instance de réplication, vous devez arrêter et supprimer ces tâches avant de supprimer l'instance de réplication.
Si vous fermez votre AWS compte, toutes les AWS DMS ressources et configurations associées à celui-ci sont supprimées au bout de deux jours. Ces ressources incluent toutes les instances de réplication, la configuration des points de terminaison source et cible, les tâches de réplication et les certificats SSL. Si, au bout de deux jours, vous décidez de AWS DMS réutiliser, vous recréez les ressources dont vous avez besoin.
Si votre instance de réplication répond à tous les critères de suppression et qu’elle conserve son statut `DELETING` pendant une période prolongée, contactez le support pour résoudre le problème.
## Suppression d'une instance de réplication à l'aide de la AWS console
Pour supprimer une instance de réplication, utilisez la AWS console.
**Pour supprimer une instance de réplication à l'aide de la AWS console**
1. Connectez-vous à la AWS DMS console AWS Management Console et ouvrez-la à l'adresse [https://console.aws.amazon.com/dms/v2/](https://console.aws.amazon.com/dms/v2/).
1. Dans le volet de navigation, sélectionnez **Instances de réplication**.
1. Choisissez l'instance de réplication que vous souhaitez supprimer.
1. Sélectionnez **Delete (Supprimer)**.
1. Dans la boîte de dialogue , , choisissez **Supprimer**.
## Suppression d'une instance de réplication à l'aide de l'interface de ligne de commande
Pour supprimer une instance de réplication, utilisez la AWS CLI [https://docs.aws.amazon.com/cli/latest/reference/dms/delete-replication-instance.html](https://docs.aws.amazon.com/cli/latest/reference/dms/delete-replication-instance.html)commande avec le paramètre suivant :
+ `--replication-instance-arn`
**Example Exemple de suppression**
L' AWS CLI exemple suivant supprime une instance de réplication.
```
aws dms delete-replication-instance \
--replication-instance-arn arn of my rep instance
```
## Suppression d'une instance de réplication à l'aide de l'API
Pour supprimer une instance de réplication, utilisez l'[https://docs.aws.amazon.com/dms/latest/APIReference/API_DeleteReplicationInstance.html](https://docs.aws.amazon.com/dms/latest/APIReference/API_DeleteReplicationInstance.html)action AWS DMS API avec les paramètres suivants :
+ `ReplicationInstanceArn = arn of my rep instance`
**Example Exemple de suppression**
L'exemple de code suivant supprime une instance de réplication.
```
1. https://dms.us-west-2.amazonaws.com/
2. ?Action=DeleteReplicationInstance
3. &DBInstanceArn=arn of my rep instance
4. &SignatureMethod=HmacSHA256
5. &SignatureVersion=4
6. &Version=2014-09-01
7. &X-Amz-Algorithm=AWS4-HMAC-SHA256
8. &X-Amz-Credential=AKIADQKE4SARGYLE/20140425/us-east-1/dms/aws4_request
9. &X-Amz-Date=20140425T192732Z
10. &X-Amz-SignedHeaders=content-type;host;user-agent;x-amz-content-sha256;x-amz-date
11. &X-Amz-Signature=1dc9dd716f4855e9bdf188c70f1cf9f6251b070b68b81103b59ec70c3e7854b3
```
# Utilisation de la fenêtre AWS DMS de maintenance
Chaque instance de AWS DMS réplication dispose d'une fenêtre de maintenance hebdomadaire au cours de laquelle toutes les modifications système disponibles sont appliquées. Vous pouvez considérer le créneau de maintenance comme une occasion de contrôler le moment où les modifications et les correctifs logiciels sont appliqués.
S'il est AWS DMS déterminé qu'une maintenance est requise au cours d'une semaine donnée, elle a lieu pendant la période de maintenance de 30 minutes que vous avez choisie lors de la création de l'instance de réplication. AWS DMS effectue la plupart des opérations de maintenance pendant la fenêtre de maintenance de 30 minutes. Toutefois, une plus longue durée peut être nécessaire pour de plus grandes modifications.
## Effet de la maintenance sur les tâches de migration existantes
Lorsqu'une tâche de AWS DMS migration est exécutée sur une instance, les événements suivants se produisent lorsqu'un correctif est appliqué :
+ Si les tables dans la tâche de migration se trouvent dans la phase de réplication des modifications en continu (CDC), AWS DMS arrête la tâche pendant un moment, puis la reprend après l’application du correctif. La migration reprend ensuite à partir du point où elle a été interrompue lorsque le correctif a été appliqué.
+ S'il s' AWS DMS agit de **migrer une table dans le cadre d'une tâche de migration de données existantes** **ou de migration de données existantes et de réplication des modifications en cours**, DMS arrête puis redémarre la migration pour toutes les tables en phase de chargement complet pendant l'application du correctif. DMS arrête et reprend également toutes les tables en phase CDC pendant l’application du correctif.
## Modification de la configuration de la fenêtre de maintenance
Vous pouvez modifier la période de maintenance à l'aide de l'API AWS Management Console, de ou de l' AWS DMS API. AWS CLI
### Modification de la configuration de la fenêtre de maintenance à l’aide de la console
Vous pouvez modifier l'horaire de la fenêtre de maintenance à l'aide de l' AWS Management Console.
**Pour modifier la fenêtre de maintenance préférée à l'aide de la console**
1. Connectez-vous à la AWS DMS console AWS Management Console et ouvrez-la à l'adresse [https://console.aws.amazon.com/dms/v2/](https://console.aws.amazon.com/dms/v2/).
1. Dans le volet de navigation, sélectionnez **Instances de réplication**.
1. Choisissez l'instance de réplication que vous souhaitez modifier, puis sélectionnez **Modifier**.
1. Développez la section **Maintenance** et choisissez la date et l'heure de votre fenêtre de maintenance.
1. Choisissez **Apply changes immediately**.
1. Sélectionnez **Modifier**.
### Modification de la configuration de la fenêtre de maintenance à l'aide de l'interface de ligne de commande
Pour ajuster la fenêtre de maintenance préférée, utilisez la AWS CLI [https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html)commande avec les paramètres suivants.
+ `--replication-instance-identifier`
+ `--preferred-maintenance-window`
**Example**
L' AWS CLI exemple suivant définit la fenêtre de maintenance sur les mardis, de 4 h 00 à 4 h 30. UTC.
```
aws dms modify-replication-instance \
--replication-instance-identifier myrepinstance \
--preferred-maintenance-window Tue:04:00-Tue:04:30
```
### Modification de la configuration de la fenêtre de maintenance à l'aide de l'API
Pour ajuster la fenêtre de maintenance préférée, utilisez l'[https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBInstance.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBInstance.html)action AWS DMS API avec les paramètres suivants.
+ `ReplicationInstanceIdentifier = myrepinstance`
+ `PreferredMaintenanceWindow = Tue:04:00-Tue:04:30`
**Example**
L’exemple de code suivant définit la fenêtre de maintenance pour qu’elle ait lieu tous les mardis entre 04 h 00 et 04 h 30. UTC.
```
1. https://dms.us-west-2.amazonaws.com/
2. ?Action=ModifyReplicationInstance
3. &DBInstanceIdentifier=myrepinstance
4. &PreferredMaintenanceWindow=Tue:04:00-Tue:04:30
5. &SignatureMethod=HmacSHA256
6. &SignatureVersion=4
7. &Version=2014-09-01
8. &X-Amz-Algorithm=AWS4-HMAC-SHA256
9. &X-Amz-Credential=AKIADQKE4SARGYLE/20140425/us-east-1/dms/aws4_request
10. &X-Amz-Date=20140425T192732Z
11. &X-Amz-SignedHeaders=content-type;host;user-agent;x-amz-content-sha256;x-amz-date
12. &X-Amz-Signature=1dc9dd716f4855e9bdf188c70f1cf9f6251b070b68b81103b59ec70c3e7854b3
```