Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.
# Trabajar con una instancia AWS DMS de replicación
Al crear una instancia de AWS DMS replicación, la AWS DMS crea en una instancia de Amazon EC2 en una nube privada virtual (VPC) basada en el servicio Amazon VPC. Esta instancia de replicación es la que se usa para migrar sus bases de datos. Al usar una instancia de replicación, puede obtener alta disponibilidad y soporte de conmutación por error con una implementación Multi-AZ cuando elija la opción **Multi-AZ.**
En una implementación Multi-AZ, aprovisiona y mantiene AWS DMS automáticamente una réplica síncrona en espera de la instancia de replicación en una zona de disponibilidad diferente. La instancia de replicación principal se replica sincrónicamente en las zonas de disponibilidad en la réplica en espera. Este enfoque proporciona redundancia de datos, elimina las I/O congelaciones y minimiza los picos de latencia.
![\[AWS Instancia de replicación de Database Migration Service\]](http://docs.aws.amazon.com/es_es/dms/latest/userguide/images/datarep-conceptual2.png)
AWS DMS utiliza una instancia de replicación para conectarse al banco de datos de origen, leer los datos de origen y formatear los datos para que los consuma el banco de datos de destino. Una instancia de replicación también carga los datos en el almacén de datos de destino. La mayor parte de este procesamiento ocurre en la memoria. No obstante, es posible que en las transacciones de mayor volumen se precise almacenar en la memoria búfer del disco. Las transacciones almacenadas en caché y los archivos de registro también se escriben en el disco.
Puede crear una instancia de AWS DMS replicación en las siguientes AWS regiones.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/dms/latest/userguide/CHAP_ReplicationInstance.html)
AWS DMS admite una AWS región especial, denominada así, AWS GovCloud (US) que está diseñada para permitir a las agencias gubernamentales y a los clientes de EE. UU. trasladar las cargas de trabajo confidenciales a la nube. AWS GovCloud (US) aborda los requisitos normativos y de cumplimiento específicos del gobierno de EE. UU. Para obtener más información AWS GovCloud (US), consulte [¿Qué es AWS GovCloud (EE. UU.)?](https://docs.aws.amazon.com/govcloud-us/latest/UserGuide/whatis.html)
A continuación, encontrará más detalles acerca de las instancias de replicación.
**Topics**
+ [Cómo elegir la instancia de replicación de AWS DMS adecuada para su migración](CHAP_ReplicationInstance.Types.md)
+ [Selección del mejor tamaño para una instancia de replicación](CHAP_BestPractices.SizingReplicationInstance.md)
+ [Trabajo con las versiones de motor de replicación](CHAP_ReplicationInstance.EngineVersions.md)
+ [Instancias de replicación pública y privada](CHAP_ReplicationInstance.PublicPrivate.md)
+ [Tipos de direcciones IP y red](CHAP_ReplicationInstance.IPAddressing.md)
+ [Configuración de una red para una instancia de replicación](CHAP_ReplicationInstance.VPC.md)
+ [Establecimiento de una clave de cifrado para una instancia de replicación](CHAP_ReplicationInstance.EncryptionKey.md)
+ [Creación de una instancia de replicación](CHAP_ReplicationInstance.Creating.md)
+ [Modificación de una instancia de replicación](CHAP_ReplicationInstance.Modifying.md)
+ [Reinicio de una instancia de replicación](CHAP_ReplicationInstance.Rebooting.md)
+ [Eliminación de una instancia de replicación](CHAP_ReplicationInstance.Deleting.md)
+ [Trabajando con la ventana AWS DMS de mantenimiento](CHAP_ReplicationInstance.MaintenanceWindow.md)
# Cómo elegir la instancia de replicación de AWS DMS adecuada para su migración
AWS DMS crea la instancia de replicación en una instancia de Amazon EC2. AWS DMS actualmente admite las clases de instancias Amazon EC2 T3, C5, C6i, R5 y R6i para las instancias de replicación:
+ Las instancias T3 son el tipo de instancia de uso general fragmentable de próxima generación. Este tipo proporciona un nivel básico de rendimiento de la CPU con posibilidad de ampliar el uso de la CPU en cualquier momento durante el tiempo que sea necesario. Las instancias T3 ofrecen un equilibrio entre recursos informáticos, de memoria y de red y están diseñadas para aplicaciones con un uso moderado de CPU que experimentan picos temporales en su uso. Las instancias T3 acumulan créditos de CPU cuando una carga de trabajo funciona por debajo del umbral de referencia. Cada crédito de CPU obtenido proporciona a la instancia T3 la oportunidad de aprovechar al máximo el rendimiento de un núcleo de CPU completo durante un minuto cuando sea necesario.
Las instancias T3 pueden realizar ráfagas en cualquier momento durante el tiempo que sea necesario en el modo `unlimited`. Para obtener más información sobre el modo `unlimited`, consulte [Trabajo con modo ilimitado para las instancias de rendimiento ampliable](#CHAP_ReplicationInstance.Types.UnlimitedMode).
+ Las instancias C5 son el tipo de instancia de próxima generación que ofrecen un alto rendimiento rentable a un precio bajo por cómputo para ejecutar cargas de trabajo avanzadas con un uso intensivo de computación. Esto incluye cargas de trabajo como servidores web de alto rendimiento, computación de alto rendimiento (HPC), procesamiento por lotes, publicación de anuncios, juegos multijugador altamente escalables y codificación de vídeo. Otras cargas de trabajo para las que las instancias C5 son adecuadas incluyen el modelado científico, el análisis distribuido y la inferencia de aprendizaje profundo y automático. Las instancias C5 están disponibles con una selección de procesadores de Intel y AMD.
+ Las instancias C6i ofrecen un rendimiento informático hasta un 15 % superior al de las instancias Gen5 comparables para una amplia variedad de cargas de trabajo y un cifrado de memoria permanente. Las instancias C6i son ideales para cargas de trabajo con un uso intensivo de computación, como el procesamiento por lotes, la analítica distribuida, la computación de alto rendimiento (HPC), la distribución de anuncios, los juegos multijugador altamente escalables y la codificación de vídeo.
+ Las instancias R5 son la nueva generación de tipos de instancias optimizados para memoria para Amazon EC2. Las instancias R5 son ideales para aplicaciones con un uso intensivo de memoria, como bases de datos de alto rendimiento, cachés en memoria de escala web distribuida, bases de datos en memoria de tamaño mediano, análisis de macrodatos en tiempo real y otras aplicaciones empresariales. Las migraciones o replicaciones continuas de sistemas de transacciones de alto rendimiento que se utilizan también pueden consumir grandes cantidades de CPU y memoria. AWS DMS
+ Las instancias R6i ofrecen un rendimiento informático hasta un 15 % superior al de las instancias Gen5 comparables para una amplia variedad de cargas de trabajo y un cifrado de memoria permanente. Las instancias R6i cuentan con la certificación SAP y son ideales para cargas de trabajo como bases de datos SQL y NoSQL, cachés en memoria distribuidas a escala web como Memcached y Redis OSS, bases de datos en memoria como SAP HANA y análisis de macrodatos en tiempo real, como los clústeres de Hadoop y Spark.
+ Las instancias de C7i ofrecen mejor rendimiento computacional que las instancias comparables de la generación anterior. En el caso AWS DMS de las cargas de trabajo, las instancias C7i son excelentes para acelerar los procesos de transformación de datos, gestionar las conversiones de esquemas que requieren muchos recursos informáticos y mantener un rendimiento constante durante las tareas de migración de gran volumen. Estas instancias ofrecen un equilibrio ideal de rendimiento computacional para las cargas de trabajo que requieren un rendimiento sostenido de la CPU.
+ Las instancias de R7i ofrecen mejor rendimiento computacional que las instancias comparables de la generación anterior, además de disponer de una gran capacidad de memoria para las cargas de trabajo con un uso intensivo de memoria. En cuanto a AWS DMS las cargas de trabajo, las instancias R7i son especialmente adecuadas para tareas con bases de datos de gran tamaño que procesan grandes volúmenes de transacciones simultáneas de bases de datos, lo que permite gestionar de forma eficiente los escenarios de replicación con uso intensivo de memoria y los procesos complejos de validación de datos que requieren una cantidad considerable de búferes de memoria.
Cada instancia de replicación tiene una configuración específica de memoria y de vCPU. La siguiente tabla muestra la configuración de cada tipo de instancia de replicación. Para obtener información acerca de los precios, consulte la [página de precios del servicio de AWS Database Migration Service](https://aws.amazon.com/dms/pricing/).
**Tipos de instancias de replicación de uso general**
| Tipo | vCPU | Memoria (GiB) |
| --- | --- | --- |
| dms.t3.micro | 2. | 1 |
| dms.t3.small | 2 | 2. |
| dms.t3.medium | 2 | 4 |
| dms.t3.large | 2 | 8 |
**Tipos de instancias de replicación optimizadas para computación**
| Tipo | vCPU | Memoria (GiB) |
| --- | --- | --- |
| 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 |
**Tipos de instancias de replicación optimizadas para memoria**
| Tipo | vCPU | Memoria (GiB) |
| --- | --- | --- |
| 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 | 1024 |
| 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.12x grande | 48 | 384 |
| dms.r7i.16x grande | 64 | 512 |
| dms.r7i.24xlarge | 96 | 768 |
| dms.r7i.48xlarge | 192 | 1536 |
En las tablas anteriores se enumeran todos los tipos de instancias de AWS DMS replicación, pero los tipos disponibles en su región pueden variar. Para ver los tipos de instancias de replicación disponibles en la región, puede ejecutar el siguiente comando [AWS CLI](https://docs.aws.amazon.com/cli/latest/reference/dms/index.html):
```
aws dms describe-orderable-replication-instances --region your_region_name
```
**Topics**
+ [Decidir qué clase de instancias usar](#CHAP_ReplicationInstance.Types.Deciding)
+ [Trabajo con modo ilimitado para las instancias de rendimiento ampliable](#CHAP_ReplicationInstance.Types.UnlimitedMode)
## Decidir qué clase de instancias usar
Para ayudar a determinar qué clase de instancia de replicación podría funcionar mejor para usted, veamos el proceso de captura de datos de cambios (CDC) que AWS DMS utiliza.
Supongamos que está ejecutando una tarea de carga completa más CDC (carga masiva más replicación continua). En este caso, la tarea tiene su propio SQLite repositorio para almacenar metadatos y otra información. Antes de AWS DMS iniciar una carga completa, se llevan a cabo los siguientes pasos:
+ AWS DMS comienza a capturar los cambios de las tablas que está migrando desde el registro de transacciones del motor de origen (los denominamos *cambios en caché*). Después de que se haya realizado la carga completa, estos cambios en caché se recopilan y se aplican en el destino. En función del volumen de los cambios en la memoria caché, estos cambios se pueden aplicar directamente desde la memoria, donde se recopilan en primer lugar, hasta un umbral definido. O pueden aplicarse desde el disco, donde los cambios se escriben cuando no se pueden mantener en memoria.
+ Una vez aplicados los cambios en caché, se AWS DMS inicia de forma predeterminada un proceso de aplicación transaccional en la instancia de destino.
Durante la fase de cambios en caché aplicada y la fase de replicaciones en curso, AWS DMS utiliza dos búferes de flujo, uno para los datos entrantes y salientes. AWS DMS también utiliza un componente importante denominado *clasificador,* que es otro búfer de memoria. A continuación se muestran dos usos importantes del componente clasificador (que tiene otros):
+ Realiza un seguimiento de todas las transacciones y se asegura de que reenvía únicamente las transacciones pertinentes al búfer de salida.
+ Se asegura de que las transacciones se reenvían en el mismo orden de confirmación que en el origen.
Como puede ver, tenemos tres importantes búferes de memorias en esta arquitectura para CDC en AWS DMS. Si cualquiera de estos búferes experimenta presión de memoria, la migración puede tener problemas de desempeño que podrían llegar a producir errores.
Cuando conecte cargas de trabajo pesadas con un elevado número de transacciones por segundo (TPS) en esta arquitectura, puede encontrar la memoria adicional proporcionada por instancias R5 y R6i útiles. Puede utilizar instancias R5 y R6i para almacenar un gran número de transacciones en memoria y evitar problemas de presión de memoria durante las replicaciones en curso.
## Trabajo con modo ilimitado para las instancias de rendimiento ampliable
Una instancia de rendimiento ampliable configurada como `unlimited`, por ejemplo una instancia de T3, puede sostener una utilización de la CPU alta durante cualquier periodo siempre que sea necesario. El precio por hora de la instancia puede cubrir automáticamente todos los picos de uso de la CPU. Es así si la utilización media de la CPU de la instancia está a la par o por debajo de la base de referencia en un periodo de 24 horas o durante la vida útil de la instancia, lo que dure menos.
Para la gran mayoría de las cargas de trabajo de uso general, las instancias configuradas como `unlimited` proporcionan un rendimiento suficiente sin cargos adicionales. Si la instancia requiere un mayor uso de la CPU durante un período prolongado, también puede hacerlo por un cargo fijo adicional por hora de vCPU. Para obtener información sobre los precios de las instancias T3, consulte “Créditos de CPU T3” en [AWS Database Migration Service](https://aws.amazon.com/dms/pricing/).
Para obtener más información sobre el modo `unlimited` para instancias de T3, consulte [Modo ilimitado para las instancias de rendimiento ampliable](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/burstable-performance-instances-unlimited-mode.html) en la *Guía del usuario de Amazon EC2*.
**importante**
Si utiliza una instancia `dms.t3.micro` en la oferta del [nivel gratuito de AWS](https://aws.amazon.com/free/) y la utiliza en modo `unlimited`, es posible que se apliquen cargos. En particular, podrían aplicarse cargos si la utilización promedio en un periodo de 24 horas supera la utilización de base de referencia de la instancia. Para obtener más información, consulte [Utilización de referencia](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/burstable-credits-baseline-concepts.html#baseline_performance) en la *Guía del usuario de Amazon EC2*.
Las instancias T3 se lanzan como `unlimited` de forma predeterminada. Si el uso medio de CPU durante un período de 24 horas supera la base de referencia, incurre en cargos por créditos excedentes. En algunos casos, es posible que lance instancias de spot T3 como `unlimited` y planee usarlas inmediatamente y durante un corto periodo de tiempo. Si lo hace sin tiempo de inactividad para acumular créditos de CPU, genera gastos por créditos excedentes. Le recomendamos lanzar las instancias de spot de T3 en modo estándar para evitar pagar costos más elevados. Para obtener más información, consulte [Los créditos sobrantes pueden generar costos](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/burstable-performance-instances-unlimited-mode-concepts.html#unlimited-mode-surplus-credits), las [instancias de spot T3](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-spot-limits.html#t3-spot-instances) y [Modo estándar para las instancias de rendimiento ampliable](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/burstable-performance-instances-standard-mode.html) en la *Guía del usuario de Amazon EC2*.
# Selección del mejor tamaño para una instancia de replicación
La selección de la instancia de replicación adecuada depende de varios factores del caso de uso. Para ayudar a entender cómo se utilizan los recursos de instancias de replicación, consulte la siguiente explicación. Trata la situación habitual de una tarea de carga completa \$1 CDC.
Durante una tarea de carga completa, AWS DMS carga las tablas de forma individual. De forma predeterminada, se cargan ocho tablas a la vez. AWS DMS captura los cambios continuos en la fuente durante una tarea de carga completa para que los cambios se puedan aplicar más adelante en el punto final de destino. Los cambios se almacenan en caché en la memoria y, en caso de agotarse la memoria disponible, se almacenan en la memoria caché del disco. Cuando se completa una tarea de carga completa para una tabla, aplica AWS DMS inmediatamente los cambios en caché a la tabla de destino.
Después de que se hayan aplicado todos los cambios en la memoria caché pendientes para una tabla, el punto de enlace de destino se encuentra en un estado coherente desde el punto de vista transaccional. En este punto, el destino está sincronizado con el punto final de origen con respecto a los últimos cambios en caché. AWS DMS a continuación, comienza la replicación continua entre el origen y el destino. Para ello, AWS DMS toma las operaciones de cambio de los registros de transacciones de origen y las aplica al destino de manera coherente desde el punto de vista de las transacciones. (Este proceso supone que la aplicación optimizada por lotes no está seleccionada). AWS DMS transmite los cambios en curso a través de la memoria de la instancia de replicación, si es posible. De lo contrario, AWS DMS escribe los cambios en el disco de la instancia de replicación hasta que se puedan aplicar en el destino.
El usuario tiene cierto control sobre la forma en que la instancia de replicación gestiona el procesamiento de los cambios y sobre cómo se utiliza la memoria en dicho proceso. Para obtener más información acerca de cómo ajustar el procesamiento de cambios, consulte [Configuración de ajuste del procesamiento de cambios](CHAP_Tasks.CustomizingTasks.TaskSettings.ChangeProcessingTuning.md).
## Factores que se deben tener en cuenta
La memoria y el espacio en disco son factores clave a la hora de seleccionar una instancia de replicación adecuada para el caso de uso. A continuación, puede encontrar un análisis de las características de los casos de uso que se deben analizar para elegir una instancia de replicación.
+ Base de datos y tamaño de tabla
El volumen de datos ayuda a determinar la configuración de la tarea para optimizar el rendimiento de la carga completa. Por ejemplo, para dos esquemas de 1 TB, puede particionar las tablas en cuatro tareas de 500 GB y ejecutarlas en paralelo. El posible paralelismo depende del recurso de CPU disponible en la instancia de replicación. Por eso es una buena idea entender el tamaño de la base de datos y las tablas para optimizar el rendimiento de carga completa. Ayuda a determinar la cantidad de tareas que puede realizar.
+ Objetos grandes
Los tipos de datos que están presentes en el ámbito de la migración pueden afectar al rendimiento. En particular, los objetos grandes (LOBs) afectan al rendimiento y al consumo de memoria. Para migrar un valor LOB, AWS DMS lleva a cabo un proceso de dos pasos. En primer lugar, AWS DMS inserta la fila en el objetivo sin el valor LOB. En segundo lugar, AWS DMS actualiza la fila con el valor LOB. Esto afecta a la memoria, por lo que es importante identificar las columnas de LOB en el origen y analizar su tamaño.
+ Frecuencia de carga y tamaño de las transacciones
La frecuencia de carga y las transacciones por segundo (TPS) influyen en el uso de memoria. Un número elevado de actividades relacionadas con TPS o el lenguaje de manipulación de datos (DML) se traduce en un uso elevado de la memoria. Esto sucede porque DMS almacena en caché los cambios hasta que se aplican al destino. Durante la CDC, esto provoca un intercambio (escritura en el disco físico debido a un desbordamiento de memoria), lo que provoca latencia.
+ Claves de tabla e integridad referencial
La información sobre las claves de la tabla determina el modo CDC (aplicación por lotes o aplicación transaccional) que se utiliza para migrar los datos. En general, la aplicación transaccional es más lenta que la aplicación por lotes. En el caso de las transacciones de larga duración, es posible que haya que migrar muchos cambios. Cuando se utiliza la aplicación transaccional, AWS DMS es posible que se necesite más memoria para almacenar los cambios en comparación con la aplicación por lotes. Si migra tablas sin claves principales, la aplicación por lotes producirá un error y la tarea de DMS pasará al modo de aplicación transaccional. Cuando la integridad referencial está activa entre tablas durante la CDC, se AWS DMS utiliza la aplicación transaccional de forma predeterminada. Para obtener más información sobre la aplicación por lotes en comparación con la aplicación transaccional, consulte [¿Cómo puedo utilizar la característica de aplicación por lotes de DMS para mejorar el rendimiento de la replicación de CDC?](https://aws.amazon.com/premiumsupport/knowledge-center/dms-batch-apply-cdc-replication/).
Utilice estas métricas para determinar si necesita que la instancia de replicación esté optimizada para la computación o para la memoria.
## Problemas comunes
Es posible que se enfrente a los siguientes problemas comunes que provocan la contención de recursos en la instancia de replicación durante la migración. Para obtener información sobre las métricas de instancia de replicación, consulte [Métricas de instancia de replicación](CHAP_Monitoring.md#CHAP_Monitoring.Metrics.CloudWatch).
+ Si la memoria de una instancia de replicación resulta insuficiente, los datos se escriben en el disco. La lectura desde el disco puede provocar latencia, que se puede evitar si se asigna suficiente memoria a la instancia de replicación.
+ El tamaño del disco asignado a la instancia de replicación puede ser inferior al necesario. El tamaño del disco se usa cuando los datos de la memoria se desbordan; también se usa para almacenar los registros de tareas. Las IOPS máximas también dependen de ello.
+ La ejecución de varias tareas o tareas con un alto paralelismo afecta al consumo de CPU de la instancia de replicación. Esto ralentiza el procesamiento de las tareas y provoca latencia.
## Prácticas recomendadas
Tenga en cuenta estas dos prácticas recomendadas más comunes al determinar el tamaño de una instancia de replicación. Para obtener más información, consulte [Mejores prácticas para AWS Database Migration Service](CHAP_BestPractices.md).
1. Calcule la carga de trabajo y comprenda si requiere un uso intensivo del equipo o de la memoria. En función de esto, puede determinar la clase y el tamaño de la instancia de replicación:
+ AWS DMS procesos LOBs en la memoria. Esta operación requiere una cantidad considerable de memoria.
+ El número de tareas y el número de subprocesos afectan al consumo de CPU. Evite utilizar más de ocho `MaxFullLoadSubTasks` durante la operación de carga completa.
1. Aumente el espacio en disco asignado a la instancia de replicación cuando tenga una carga de trabajo elevada durante la carga completa. De este modo, la instancia de replicación utilizará el máximo de IOPS que se le haya asignado.
Las directrices anteriores no cubren todas las situaciones posibles. Es importante tener en cuenta los detalles específicos del caso de uso particular al determinar el tamaño de la instancia de replicación.
Las pruebas anteriores muestran que la CPU y la memoria varían con las diferentes cargas de trabajo. En particular, LOBs afectan a la memoria y el recuento de tareas o el paralelismo afectan a la CPU. Cuando la migración se esté ejecutando, monitoree la CPU, la memoria que se puede liberar, la cantidad de almacenamiento libre y las IOPS de la instancia de replicación. En función de los datos que recopile, puede ampliar o reducir las dimensiones de la instancia de replicación según sea necesario.
# Trabajo con las versiones de motor de replicación
El *motor de replicación* es el AWS DMS software principal que se ejecuta en la instancia de replicación y realiza las tareas de migración que especifique. AWS publica periódicamente nuevas versiones del software del motor de AWS DMS replicación, con nuevas funciones y mejoras en el rendimiento. Cada versión del software del motor de replicación tiene su propio número de versión para diferenciarlo de otras versiones.
Cuando lanza una nueva instancia de replicación, ejecuta la última versión del AWS DMS motor, a menos que especifique lo contrario. Para obtener más información, consulte [Trabajar con una instancia AWS DMS de replicación](CHAP_ReplicationInstance.md).
Si tiene una instancia de replicación en ejecución, puede actualizarla a una versión del motor más reciente. (AWS DMS no admite la degradación de versiones del motor). Para obtener más información acerca de las versiones del motor de replicación, consulte [AWS Notas de la versión de DMS](CHAP_ReleaseNotes.md).
## Actualización de la versión del motor mediante la consola
Puede actualizar una instancia de AWS DMS replicación mediante. Consola de administración de AWS
**Para actualizar una instancia de replicación con la consola**
1. Abra la AWS DMS consola en la versión [https://console.aws.amazon.com/dms/2/](https://console.aws.amazon.com/dms/v2/).
1. En el panel de navegación, elija **Instancias de replicación**.
1. Elija su motor de replicación y, a continuación, seleccione **Modify**.
1. Para **Versión del motor**, elija el número de la versión que quiere y, a continuación, elija **Modificar**.
**nota**
Se recomienda detener todas las tareas antes de actualizar la instancia de replicación. Si no detiene la tarea, la AWS DMS detendrá automáticamente antes de la actualización. Si detiene la tarea manualmente, tendrá que iniciarla manualmente una vez finalizada la actualización. La actualización de la instancia de replicación tarda varios minutos. Cuando la instancia esté lista, su estado cambiará a **available**.
## Actualización de la versión del motor mediante el AWS CLI
Puede actualizar una instancia de AWS DMS replicación mediante el AWS CLI, de la siguiente manera.
**Para actualizar una instancia de replicación mediante AWS CLI**
1. Determine el Nombre de recurso de Amazon (ARN) de la instancia de replicación mediante el siguiente comando.
```
aws dms describe-replication-instances \
--query "ReplicationInstances[*].[ReplicationInstanceIdentifier,ReplicationInstanceArn,ReplicationInstanceClass]"
```
En la salida, tome nota del Nombre de recurso de Amazon (ARN) de la instancia de replicación que quiere actualizar, por ejemplo: `arn:aws:dms:us-east-1:123456789012:rep:6EFQQO6U6EDPRCPKLNPL2SCEEY`
1. Determine qué versiones de instancias de replicación están disponibles mediante el siguiente comando.
```
aws dms describe-orderable-replication-instances \
--query "OrderableReplicationInstances[*].[ReplicationInstanceClass,EngineVersion]"
```
En la salida, tenga en cuenta el número o números de versión del motor que están disponibles para la clase de instancia de replicación. Debería ver esta información en la salida del paso 1.
1. Actualice la instancia de replicación utilizando el siguiente comando.
```
aws dms modify-replication-instance \
--replication-instance-arn arn \
--engine-version n.n.n
```
Sustituya *arn* lo anterior por el ARN de la instancia de replicación real del paso anterior.
*n.n.n *Sustitúyalo por el número de versión del motor que desee, por ejemplo: `3.4.5`
**nota**
La actualización de la instancia de replicación tarda varios minutos. Puede ver el estado de la instancia de replicación utilizando el siguiente comando.
```
aws dms describe-replication-instances \
--query "ReplicationInstances[*].[ReplicationInstanceIdentifier,ReplicationInstanceStatus]"
```
Cuando la instancia de replicación esté lista, su estado cambiará a **available**.
# Instancias de replicación pública y privada
Puede especificar si una instancia de replicación tiene una dirección IP pública o privada que utiliza para conectarse a las bases de datos de origen y de destino.
Una *instancia de replicación privada* tiene una dirección IP privada a la que no puede acceder desde fuera de la red de replicación. Se usa una instancia privada cuando las bases de datos de origen y destino están en la misma red que está conectada a la nube privada virtual (VPC) de la instancia de replicación. La red se puede conectar a la VPC mediante una red privada virtual (VPN) o un emparejamiento de VPC. Direct Connect
Una conexión de *emparejamiento de VPC* es una conexión de red entre dos. VPCs Permite el enrutamiento mediante las direcciones IP privadas de cada VPC como si estuvieran en la misma red. Para obtener más información acerca de las interconexiones de VPC, consulte [Interconexiones de VPC](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-peering.html) en la *Guía del usuario de Amazon VPC*.
Una *instancia de replicación pública* puede usar el grupo de seguridad de VPC de la instancia de replicación y la dirección IP pública de la instancia de replicación o la dirección IP pública de la puerta de enlace NAT. Estas conexiones forman una red que se utiliza para migrar datos.
# Tipos de direcciones IP y red
AWS DMS siempre crea la instancia de replicación en una Amazon Virtual Private Cloud (VPC). Al crear la VPC, puede determinar la dirección IP que va a utilizar: una IPv4 o IPv6 ambas. A continuación, al crear o modificar una instancia de replicación, puede especificar el uso de un protocolo de IPv4 direcciones o un protocolo de IPv6 direcciones mediante el modo de *doble pila*.
**IPv4 direcciones**
Al crear una VPC, puede especificar un rango de IPv4 direcciones para la VPC en forma de bloque de enrutamiento entre dominios sin clase (CIDR), como 10.0.0.0/16. Un grupo de subredes define el rango de direcciones IP de este bloque de CIDR. Esta dirección IP puede ser privada o pública.
Una dirección IPv4 privada es una dirección IP a la que no se puede obtener acceso desde Internet. Se pueden usar direcciones IPv4 privadas para la comunicación entre la instancia de replicación y otros recursos, como instancias de Amazon EC2, en la misma VPC. Cada instancia de replicación tiene una dirección IP privada para la comunicación en la VPC.
Una dirección IP pública es una dirección a la que se puede acceder desde Internet. IPv4 Puede usar las direcciones públicas para la comunicación entre la instancia de replicación y los recursos en Internet. Debe controlar si la instancia de replicación recibe una dirección IP pública.
**Modo y direcciones de doble pila IPv6 **
Cuando tenga recursos que deban comunicarse con su instancia de replicación IPv6, utilice el modo de *doble pila*. Para usar el modo de doble pila, asegúrese de que cada subred del grupo de subredes que asocie a la instancia de replicación tenga un bloque IPv6 CIDR asociado. Puede crear un nuevo grupo de subredes de replicación o modificar un grupo existente de subredes de replicación para cumplir este requisito. Cada IPv6 dirección es única a nivel mundial. El bloque IPv6 CIDR de su VPC se asigna automáticamente desde el conjunto IPv6 de direcciones de Amazon. Usted no puede elegir el rango.
El DMS deshabilita el acceso a Internet Gateway para los IPv6 puntos finales de las instancias de replicación privadas en modo de doble pila. DMS lo hace para garantizar que sus IPv6 puntos de conexión sean privados y solo se pueda acceder a ellos desde su VPC.
**Puede usar la AWS DMS consola para crear o modificar una instancia de replicación y especificar el modo de doble pila en la sección de tipos de red.** En la imagen siguiente se muestra la sección **Network type** (Tipo de red) en la consola.
![\[AWS Tipo de red del Database Migration Service\]](http://docs.aws.amazon.com/es_es/dms/latest/userguide/images/datarep-network-type.png)
**Referencias**
+ Para obtener información sobre los modos IPv4 y IPv6 las direcciones, consulte Direcciones [IP](https://docs.aws.amazon.com/vpc/latest/userguide/how-it-works.html#vpc-ip-addressing) en la Guía del *usuario de Amazon VPC*.
+ Para obtener más información sobre la creación de una instancia de replicación mediante el modo de pila doble, consulte [Creación de una instancia de replicación](CHAP_ReplicationInstance.Creating.md).
+ Para obtener más información sobre la modificación de una instancia de replicación, consulte [Modificación de una instancia de replicación](CHAP_ReplicationInstance.Modifying.md).
# Configuración de una red para una instancia de replicación
AWS DMS siempre crea la instancia de replicación en una VPC basada en Amazon VPC. Especifique la VPC donde que se encuentra la instancia de replicación. Puede usar su VPC predeterminada para su cuenta y AWS región, o puede crear una nueva VPC.
Asegúrese de que la interfaz de red elástica asignada a la VPC de la instancia de replicación esté asociada a un grupo de seguridad. Además, asegúrese de que las reglas de este grupo de seguridad permitan que todo el tráfico de todos los puertos abandone (salga) la VPC. Este enfoque permite que haya comunicación entre la instancia de replicación y los puntos de conexión de las bases de datos de origen y de destino, si las reglas de entrada correctas están habilitadas en los puntos de conexión. Le recomendamos que utilice la configuración predeterminada para los puntos de enlace, la cual permite la salida en todos los puertos y a todas las direcciones.
Los puntos de enlace de origen y de destino acceden a la instancia de replicación que está dentro de la VPC conectando a la VPC o por estar dentro de la VPC. Los puntos finales de la base de datos deben incluir listas de control de acceso a la red (ACLs) y reglas de grupos de seguridad (si corresponde) que permitan el acceso entrante desde la instancia de replicación. La forma de configurarlo depende de la configuración de red que utilice. Puede utilizar el grupo de seguridad de la VPC de la instancia de replicación, la dirección IP privada o pública de la instancia de replicación o la dirección IP pública de la puerta de enlace NAT. Estas conexiones forman una red que se utiliza para migrar datos.
**nota**
Dado que una dirección IP puede cambiar como resultado de cambios en la infraestructura subyacente, le recomendamos que utilice un rango CIDR de VPC o enrute el tráfico saliente de la instancia de replicación a través de una IP elástica asociada a NAT GW. Para obtener más información sobre la creación de una VPC, incluido un bloque CIDR, consulte [Trabajar con subredes VPCs y subredes](https://docs.aws.amazon.com/vpc/latest/userguide/working-with-vpcs.html) en la Guía del usuario de *Amazon Virtual Private Cloud*. Para obtener más información acerca de las direcciones IP elásticas, consulte [Direcciones IP elásticas](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/elastic-ip-addresses-eip.html) en la *Guía del usuario de Amazon Elastic Compute Cloud*.
## Configuraciones de red para migrar bases de datos
Puede usar varias configuraciones de red diferentes con AWS Database Migration Service. Las siguientes son configuraciones comunes para una red utilizada para migrar bases de datos.
**Topics**
+ [Configuración con todos los componentes de migración de bases de datos en una VPC](#CHAP_ReplicationInstance.VPC.Configurations.ScenarioAllVPC)
+ [Configuración con múltiples VPCs](#CHAP_ReplicationInstance.VPC.Configurations.ScenarioVPCPeer)
+ [Configuración con compartición VPCs](#CHAP_ReplicationInstance.VPC.Configurations.ScenarioVPCShared)
+ [Configuración de una red a una VPC mediante una Direct Connect VPN](#CHAP_ReplicationInstance.VPC.Configurations.ScenarioDirect)
+ [Configuración de una red a una VPC mediante Internet](#CHAP_ReplicationInstance.VPC.Configurations.ScenarioInternet)
+ [Configuración con una instancia de base de datos de RDS que no está en una VPC a una instancia de base de datos en una VPC mediante ClassicLink](#CHAP_ReplicationInstance.VPC.Configurations.ClassicLink)
+ [Configuración de una red que se conecta a servicios AWS](#CHAP_ReplicationInstance.VPC.Configurations.networkconnecting)
+ [Configuración de una red que se conecta a AWS servicios mediante puntos finales de VPC](#CHAP_ReplicationInstance.VPC.Configurations.vpcendpoints)
+ [Configuración de una red que se conecta a servicios mediante Internet AWS](#CHAP_ReplicationInstance.VPC.Configuration.networkconnectingusinginternet)
Cuando sea práctico, le recomendamos que cree una instancia de replicación de DMS en la misma región que el punto de conexión de destino y en la misma VPC o subred que el punto de conexión de destino.
### Configuración con todos los componentes de migración de bases de datos en una VPC
La red más sencilla para migrar las bases de datos es aquella en la que el punto de enlace de origen, la instancia de replicación y el punto de enlace de destino están todos en la misma VPC. Esta configuración es buena si los puntos de conexión de origen y de destino están en una instancia de base de datos de Amazon RDS o en una instancia de Amazon EC2.
La siguiente ilustración muestra una configuración en la que una base de datos de una instancia de Amazon EC2 se conecta a la instancia de replicación y los datos se migran a una instancia de base de datos de Amazon RDS.
![\[AWS Ejemplo de VPC todo en uno de Database Migration Service\]](http://docs.aws.amazon.com/es_es/dms/latest/userguide/images/datarep-scenarioAllVPC.png)
El grupo de seguridad VPC utilizado en esta configuración debe permitir la entrada al puerto de la base de datos desde la instancia de replicación. Puede hacerlo de un par de formas. Puede asegurarse de que el grupo de seguridad utilizado por la instancia de replicación llegue a los puntos de conexión. O bien, puede permitir el rango CIDR de la VPC, la IP elástica de NAT GW o la dirección IP privada de la instancia de replicación, si está utilizando una. Sin embargo, no le recomendamos que utilice la dirección IP privada de la instancia de replicación, ya que puede interrumpir la replicación si la dirección IP de la replicación cambia.
### Configuración con múltiples VPCs
Si el punto final de origen y el punto final de destino son diferentes VPCs, puede crear su instancia de replicación en uno de los VPCs. A continuación, puede vincular los dos VPCs mediante el emparejamiento de VPC.
Una conexión de emparejamiento de VPC es una conexión de red entre dos VPCs que permite el enrutamiento mediante las direcciones IP privadas de cada VPC como si estuvieran en la misma red. Puede crear una conexión de emparejamiento de VPC entre la suya VPCs, con una VPC de otra AWS cuenta o con una VPC de una región diferente. AWS Para obtener más información acerca de las interconexiones de VPC, consulte [Interconexiones de VPC](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-peering.html) en la *Guía del usuario de Amazon VPC*.
En la siguiente ilustración se muestra una configuración de ejemplo con interconexión de VPC. Aquí, la base de datos de origen en una instancia de Amazon EC2 en una VPC se conecta por la interconexión de VPC para una VPC. Esta VPC contiene la instancia de replicación y la base de datos de destino en una instancia de base de datos de Amazon RDS.
![\[AWS Instancia de replicación de Database Migration Service\]](http://docs.aws.amazon.com/es_es/dms/latest/userguide/images/datarep-scenarioVPCPeer.png)
Para implementar el emparejamiento de VPC, siga las instrucciones en [Trabajo con conexiones de emparejamiento de VPC](https://docs.aws.amazon.com/vpc/latest/peering/working-with-vpc-peering.html) que se encuentran en la documentación de *Emparejamiento de nube privada virtual (VPC) de Amazon*. Asegúrese de que la tabla de enrutamiento de una VPC contenga el bloque de CIDR de la otra. Por ejemplo, si la VPC A usa el destino 10.0.0.0/16 y la VPC B usa el destino 172.31.0.0, la tabla de enrutamiento de la VPC A debe contener 172.31.0.0 y la tabla de enrutamiento de la VPC B debe contener 10.0.0.0/16. Para obtener información más detallada, consulte [Actualizar las tablas de enrutamiento para la conexión de emparejamiento de VPC](https://docs.aws.amazon.com/vpc/latest/peering/vpc-peering-routing.html) en la documentación de *Emparejamiento de nube privada virtual (VPC) de Amazon*.
Los grupos de seguridad de VPC utilizados en esta configuración deben permitir la entrada al puerto de la base de datos desde la instancia de replicación o deberían permitir el ingreso en el bloque de CIDR de la VPC interconectada.
### Configuración con compartición VPCs
AWS DMS trata las subredes que se comparten con una cuenta de cliente participante en una organización del mismo modo que las subredes normales de la misma cuenta. A continuación VPCs, se describe cómo AWS DMS gestiona las subredes y cómo puede utilizarlas de forma compartida. VPCs
Puede configurar la configuración de red para que funcione en subredes personalizadas o VPCs mediante la creación `ReplicationSubnetGroup` de objetos. Al crear `ReplicationSubnetGroup`, tiene la opción de elegir especificar subredes de una VPC concreta de la cuenta. La lista de subredes que especifique debe incluir al menos dos subredes que estén en zonas de disponibilidad independientes y todas las subredes deben estar en la misma VPC. Al crear una`ReplicationSubnetGroup`, los clientes solo especifican las subredes. AWS DMS determinará la VPC en su nombre, ya que cada subred está vinculada exactamente a una VPC.
Al crear una AWS DMS `ReplicationInstance` o una AWS DMS `ReplicationConfig`, puede elegir especificar `ReplicationSubnetGroup` and/or un grupo de seguridad de VPC en el que opere la replicación `ReplicationInstance` sin servidor. Si no se especifica, AWS DMS elige el valor predeterminado del cliente `ReplicationSubnetGroup` (que se AWS DMS crea en su nombre si no se especifica para todas las subredes de la VPC predeterminada) y el grupo de seguridad de VPC predeterminado.
Puede elegir ejecutar las migraciones en la zona de disponibilidad que especifique o en cualquiera de las zonas de disponibilidad en `ReplicationSubnetGroup`. Cuando AWS DMS intenta crear una instancia de replicación o iniciar una replicación sin servidor, convierte las zonas de disponibilidad de sus subredes en zonas de disponibilidad en la cuenta de servicio principal, a fin de garantizar que lanzamos las instancias en la zona de disponibilidad correcta, incluso si las asignaciones de zonas de disponibilidad no son idénticas entre las dos cuentas.
Si usa una VPC compartida, tendrá que asegurarse de crear objetos de `ReplicationSubnetGroup` que se asignen a las subredes que desee usar desde una VPC compartida. Al crear una `ReplicationInstance` o una `ReplicationConfig`, debe especificar un `ReplicationSubnetGroup` para la VPC compartida y especificar un grupo de seguridad de VPC que haya creado para la VPC compartida con la solicitud de creación.
Tenga en cuenta lo siguiente sobre el uso de una VPC compartida:
+ El propietario de la VPC no puede compartir un recurso con un participante, pero el participante puede crear un recurso de servicio en la subred del propietario.
+ El propietario de la VPC no puede acceder a un recurso (como una instancia de replicación) que cree el participante, porque todos los recursos son específicos de la cuenta. Sin embargo, siempre que cree la instancia de replicación en la VPC compartida, esta podrá acceder a los recursos de la VPC independientemente de la cuenta propietaria, siempre que el punto de conexión de replicación o la tarea tengan los permisos correctos.
+ Como los recursos son específicos de cada cuenta, los demás participantes no pueden acceder a los recursos que son propiedad de otras cuentas. No hay permisos que pueda conceder a otras cuentas para que puedan acceder a los recursos creados en la VPC compartida con la cuenta.
### Configuración de una red a una VPC mediante una Direct Connect VPN
Las redes remotas se pueden conectar a una VPC mediante varias opciones, como Direct AWS Connect o una conexión VPN de software o hardware. Estas opciones a menudo sirven para integrar servicios locales existentes, como los de monitoreo, autenticación, seguridad, datos o de otros sistemas, gracias a la ampliación de una red interna hacia la nube de AWS . El uso de este tipo de extensión de red permite conectarse sin problemas a recursos alojados en AWS, como una VPC.
La siguiente ilustración muestra una configuración en la que el punto de enlace de origen es una base de datos local en un centro de datos corporativo. Se conecta mediante Direct Connect o una VPN a una VPC que contiene la instancia de replicación y una base de datos de destino en una instancia de base de datos de Amazon RDS.
![\[AWS Instancia de replicación de Database Migration Service\]](http://docs.aws.amazon.com/es_es/dms/latest/userguide/images/datarep-scenarioDirect.png)
En esta configuración, el grupo de seguridad de la VPC debe incluir una regla de enrutamiento que envíe el tráfico destinado a un rango CIDR de VPC o dirección IP concreta a un host. Este host debe ser capaz de conectar el tráfico de la VPC con la VPN local. En este caso, el host NAT incluye su propia configuración de grupo de seguridad. Esta configuración debe permitir el tráfico desde el rango CIDR de la VPC, la dirección IP privada o el grupo de seguridad de la instancia de replicación hacia la instancia de NAT. Sin embargo, no le recomendamos que utilice la dirección IP privada de la instancia de replicación, ya que puede interrumpir la replicación si la dirección IP de la replicación cambia.
### Configuración de una red a una VPC mediante Internet
Si no usa una VPN o no se conecta Direct Connect a AWS los recursos, puede usar Internet para migrar su base de datos. En este caso, puede migrar a una instancia de Amazon EC2 o una instancia de base de datos de Amazon RDS. Esta configuración supone usar una instancia de replicación pública en una VPC con una gateway de Internet que contenga el punto de enlace de destino y la instancia de replicación.
![\[AWS Instancia de replicación de Database Migration Service\]](http://docs.aws.amazon.com/es_es/dms/latest/userguide/images/datarep-scenarioInternet.png)
Para agregar una gateway de Internet a la VPC, consulte [Asociar una gateway de Internet](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Internet_Gateway.html#Add_IGW_Attach_Gateway) en la *Guía del usuario de Amazon VPC*.
La tabla de enrutamiento de la VPC debe incluir reglas de enrutamiento que envíen de forma predeterminada el tráfico no destinado a la VPC a la puerta de enlace de Internet. En esta configuración, la conexión al punto de enlace parece proceder de la dirección IP pública de la instancia de replicación, no de la dirección IP privada. Para obtener más información, consulte [Tablas de enrutamiento de VPC](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Route_Tables.html) en la *Guía del usuario de Amazon VPC*.
### Configuración con una instancia de base de datos de RDS que no está en una VPC a una instancia de base de datos en una VPC mediante ClassicLink
| |
| --- |
| Vamos a retirar EC2-Classic el 15 de agosto de 2022. Le recomendamos que migre de EC2-Classic a una VPC. Para obtener más información, consulte el tema [Migrar de EC2-Classic a una VPC](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/vpc-migrate.html) en la guía del usuario de Amazon EC2 y la publicación del 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/). |
Para conectar una instancia de base de datos de Amazon RDS que no esté en una VPC a un servidor de replicación de DMS y una instancia de base de datos de una VPC, puede ClassicLink utilizarla con un servidor proxy.
ClassicLink le permite vincular una instancia de base de datos EC2-Classic a una VPC de su cuenta, dentro de la misma región. AWS Una vez que haya creado el enlace, la instancia de la base de datos de origen se podrá comunicar con la instancia de replicación dentro de la VPC a través de sus direcciones IP privadas.
Como la instancia de replicación de la VPC no puede acceder directamente a la instancia de base de datos de origen en la plataforma EC2-Classic mediante el uso de un ClassicLink servidor proxy. El servidor proxy conecta la instancia de base de datos de origen a la VPC que contiene la instancia de replicación y la instancia de base de datos de destino. El servidor proxy que se utiliza ClassicLink para conectarse a la VPC. El reenvío de puertos en el servidor proxy permite que la instancia de base de datos de origen y la instancia de base de datos de destino en la VPC puedan comunicarse.
![\[AWS Database Migration Service mediante ClassicLink\]](http://docs.aws.amazon.com/es_es/dms/latest/userguide/images/datarep-scenarioClassicLink.png)
#### Uso ClassicLink con AWS Database Migration Service
Puede conectar una instancia de base de datos de Amazon RDS que no esté en una VPC a un servidor de replicación de DMS y a AWS una instancia de base de datos que esté en una VPC. Para ello, puede utilizar Amazon EC2 ClassicLink con un servidor proxy.
El siguiente procedimiento muestra cómo utilizarlo ClassicLink para este fin. Este procedimiento conecta una instancia de base de datos de origen de Amazon RDS que no está en una VPC a una VPC que contiene una instancia de replicación de DMS y AWS una instancia de base de datos de destino.
+ Cree una instancia de replicación de AWS DMS en una VPC. (Todas las instancias de replicación se crean en VPCs.)
+ Asocie un grupo de seguridad de VPC a la instancia de replicación y a la instancia de base de datos de destino. Cuando dos instancias comparten un grupo de seguridad de VPC, pueden comunicarse entre sí de forma predeterminada.
+ Configure un servidor proxy en una instancia EC2 Classic.
+ Cree una conexión ClassicLink entre el servidor proxy y la VPC.
+ Cree puntos finales AWS de DMS para las bases de datos de origen y destino.
+ Cree una tarea de AWS DMS.
**Para usar para ClassicLink migrar una base de datos de una instancia de base de datos que no esté en una VPC a una base de datos de una instancia de base de datos de una VPC**
1. Cree una instancia de replicación de AWS DMS y asigne un grupo de seguridad de VPC:
1. [Inicie sesión en la AWS DMS consola Consola de administración de AWS y ábrala en la versión v2/. https://console.aws.amazon.com/dms/](https://console.aws.amazon.com/dms/v2/)
Si has iniciado sesión como usuario AWS Identity and Access Management (IAM), asegúrate de tener los permisos de acceso adecuados. AWS DMS Para obtener más información sobre los permisos necesarios para migrar bases de datos, consulte [Se necesitan permisos de IAM para utilizarlos AWS DMS](security-iam.md#CHAP_Security.IAMPermissions).
1. En la página **Dashboard**, elija **Replication Instance**. Siga las instrucciones que aparecen en [Paso 1: Cree una instancia de replicación mediante la AWS DMS consola](CHAP_GettingStarted.Replication.md#CHAP_GettingStarted.Replication.ReplicationInstance) para crear una instancia de replicación.
1. Una vez creada la instancia de replicación del AWS DMS, abra la consola de servicio EC2. C **Interfaces de red** desde el panel de navegación.
1. Elija la *DMSNetworkinterfaz* y, a continuación, elija **Cambiar grupos de seguridad** en el menú **Acciones**.
1. Elija el grupo de seguridad que desea utilizar para la instancia de replicación y la instancia de base de datos de destino.
1. Asocie el grupo de seguridad del último paso con la instancia de base de datos de destino:
1. Abra la consola del servicio de Amazon RDS. En el panel de navegación, elija **instancias**.
1. Elija la instancia de base de datos de destino. Para **Acciones de instancias**, elija **Modificar**.
1. Para el parámetro **Grupo de seguridad**, elija el grupo de seguridad que ha utilizado en el paso anterior.
1. Elija **Continuar** y a continuación elija **Modificar instancia de base de datos**.
1. Paso 3: Configurar un servidor proxy en una instancia EC2 Classic con NGINX. Utilice una AMI de su elección para lanzar una instancia EC2 Classic. El ejemplo siguiente se basa en la AMI Ubuntu Server 14.04 LTS (HVM).
Para configurar un servidor proxy en una instancia EC2 Classic
1. Establezca una conexión con la instancia EC2 Classic e instale NGINX con los siguientes comandos:
```
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. Edite el archivo de daemon NGINX, `/etc/init/nginx.conf`, usando el siguiente código:
```
# /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. Cree un archivo de configuración NGINX en `/usr/local/nginx/conf/nginx.conf`. En el archivo de configuración, añada lo siguiente:
```
# /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. Desde la línea de comandos, inicie NGINX con los siguientes comandos:
```
Prompt> sudo initctl reload-configuration
Prompt> sudo initctl list | grep nginx
Prompt> sudo initctl start nginx
```
1. Cree una ClassicLink conexión entre el servidor proxy y la VPC de destino que contenga la instancia de base de datos de destino y la instancia de replicación:
1. Abra la consola de EC2 y elija la instancia EC2 Classic que ejecuta el servidor proxy.
1. En **Acciones**, elija y **ClassicLink**, a continuación, elija **Vincular a VPC**.
1. Elija el grupo de seguridad que haya utilizado anteriormente en este procedimiento.
1. Elija **Enlace a VPC**.
1. Paso 5: Cree puntos finales de AWS DMS mediante el procedimiento descrito en. [Paso 2: Especificar los puntos de conexión de origen y destino](CHAP_GettingStarted.Replication.md#CHAP_GettingStarted.Replication.Endpoints) Asegúrese de utilizar el nombre de host EC2 DNS interno del proxy como el nombre del servidor cuando especifique el punto de conexión de origen.
1. Cree una tarea de AWS DMS mediante el procedimiento descrito en. [Paso 3: Crear una tarea y migrar los datos](CHAP_GettingStarted.Replication.md#CHAP_GettingStarted.Replication.Tasks)
### Configuración de una red que se conecta a servicios AWS
Para conectarse con AWS los servicios, utilice una conexión a Internet o puntos de conexión de Virtual Private Cloud (VPC). Esto es aplicable cuando:
Los puntos finales de origen o destino utilizan AWS servicios como:
+ AWS Secrets Manager
+ Amazon Simple Storage Service
Su punto final de destino es un AWS servicio como:
+ Amazon S3
+ Amazon Kinesis
+ Amazon DynamoDB
+ Amazon Redshift
+ OpenSearch Servicio Amazon
+ Amazon Athena
### Configuración de una red que se conecta a AWS servicios mediante puntos finales de VPC
Los puntos de enlace de VPC proporcionan conexiones seguras entre sus AWS recursos y conectan los recursos de VPC a los AWS servicios sin necesidad de acceso a Internet. Sus aplicaciones en subredes privadas pueden acceder a los AWS servicios mientras permanecen dentro de la AWS red, lo que mejora la seguridad y reduce la latencia. Consulte la imagen que aparece a continuación:
![\[\]](http://docs.aws.amazon.com/es_es/dms/latest/userguide/images/aws_dms_vpc_endpoints.jpg)
Para obtener más información, consulte [Configuración de puntos de enlace de VPC como puntos de enlace de AWS DMS origen y destino y Configuración de puntos de enlace](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_VPC_Endpoints.html) de VPC del [AWS DMS administrador de secretos](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Advanced.Endpoints.secretsmanager.html).
### Configuración de una red que se conecta a servicios mediante Internet AWS
Una instancia de replicación necesita acceso a Internet para conectarse a los AWS recursos durante la migración de datos.
Para obtener más información sobre las subredes públicas y privadas de una VPC, consulte [Ejemplo: una VPC con servidores en subredes privadas y NAT](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-example-private-subnets-nat.html) en la *Guía del usuario de Amazon Virtual Private Cloud*. Debe asegurarse de probar la configuración de la red para comprobar la conectividad con cualquier servicio requerido.
## Creación de un grupo de subredes de replicación
Dentro de la red que utilizará para migrar bases de datos, deberá especificar qué subredes de la nube privada virtual (VPC) tiene pensado utilizar. Esta VPC tiene que basarse en el servicio de Amazon VPC. Una *subred* es un rango de direcciones IP en la VPC dentro de una determinada zona de disponibilidad. Estas subredes se pueden distribuir entre las zonas de disponibilidad de la AWS región en la que se encuentra la VPC.
Al crear una instancia de replicación o un perfil de instancia en la consola del AWS DMS, puede usar la subred que elija.
Puede crear un grupo de subred de replicación para definir qué subredes se deben utilizar. Debe especificar subredes en al menos dos zonas de disponibilidad.
**Para crear un grupo de subred de replicación**
1. [Inicie sesión en la AWS DMS consola Consola de administración de AWS y ábrala en la versión v2/. https://console.aws.amazon.com/dms/](https://console.aws.amazon.com/dms/v2/)
Si ha iniciado sesión como usuario de IAM, asegúrese de que dispone de los permisos adecuados para acceder a AWS DMS. Para obtener más información sobre los permisos necesarios para migrar bases de datos, consulte [Se necesitan permisos de IAM para utilizarlos AWS DMS](security-iam.md#CHAP_Security.IAMPermissions).
1. En el panel de navegación, elija **Subnet groups (grupos de subredes)**.
1. Elija **Create subnet group (Crear grupo de subredes)**.
1. En la página **Crear grupo de subredes de replicación**, especifique la información del grupo de subred de replicación. La tabla siguiente describe la configuración.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/dms/latest/userguide/CHAP_ReplicationInstance.VPC.html)
1. Elija **Create subnet group (Crear grupo de subredes)**.
## Resolución de puntos de conexión de dominio mediante DNS
Por lo general, una instancia de AWS DMS replicación utiliza la resolución del Sistema de nombres de dominio (DNS) en una instancia de Amazon EC2 para resolver los puntos de enlace del dominio. Si necesita una resolución de DNS, puede utilizar Amazon Route 53 Resolver. Para obtener más información acerca del uso de Route 53 DNS Resolver, consulte [Introducción a Route 53 Resolver](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver-getting-started.html).
Para obtener información sobre cómo utilizar su propio servidor de nombres en las instalaciones para resolver determinados puntos de conexión mediante Amazon Route 53 Resolver, consulte [Uso de su propio servidor de nombres en las instalaciones](CHAP_BestPractices.md#CHAP_BestPractices.Rte53DNSResolver).
# Establecimiento de una clave de cifrado para una instancia de replicación
AWS El DMS cifra el almacenamiento utilizado por una instancia de replicación y la información de conexión del punto final. Para cifrar el almacenamiento utilizado por una instancia de replicación, el AWS DMS utiliza un almacenamiento AWS KMS key que es exclusivo de su cuenta. AWS Puede ver y administrar esta clave KMS con AWS Key Management Service ()AWS KMS. Puede utilizar la clave KMS predeterminada en la cuenta (`aws/dms`) o crear una clave KMS. Si ya tiene una clave de AWS KMS cifrado, también puede utilizarla para el cifrado.
Puede especificar su propia clave de cifrado proporcionando un identificador de clave de KMS para cifrar sus recursos de AWS DMS. Cuando especifique su propia clave de cifrado, la cuenta de usuario utilizada para migrar la base de datos deberá tener acceso a ella. Para obtener más información sobre cómo crear sus propias claves de cifrado y proporcionar a los usuarios acceso a una clave de cifrado, consulte la *[guía para desarrolladores de AWS KMS](https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html)*.
Si no especificas un identificador de clave de KMS, AWS DMS utilizará tu clave de cifrado predeterminada. KMS crea la clave de cifrado predeterminada para el AWS DMS de su AWS cuenta. Su AWS cuenta tiene una clave de cifrado predeterminada diferente para cada AWS región.
Para administrar las claves utilizadas para cifrar sus recursos de AWS DMS, utilice. AWS KMS Puede encontrarlo buscando **KMS AWS KMS ** en el Consola de administración de AWS panel de navegación.
AWS KMS combina hardware y software seguros y de alta disponibilidad para proporcionar un sistema de administración de claves adaptado a la nube. Con AWS KMSél, puede crear claves de cifrado y definir las políticas que controlan cómo se pueden utilizar estas claves. AWS KMS es compatible AWS CloudTrail, por lo que puede auditar el uso de las claves para comprobar que las claves se utilizan de forma adecuada. Sus AWS KMS claves se pueden usar en combinación con el AWS DMS y otros AWS servicios compatibles. Los servicios de AWS admitidos incluyen Amazon RDS, Amazon S3, Amazon Elastic Block Store (Amazon EBS) y Amazon Redshift.
Cuando haya creado sus recursos de AWS DMS con una clave de cifrado específica, no podrá cambiar la clave de cifrado de esos recursos. Asegúrese de determinar los requisitos de la clave de cifrado antes de crear los recursos de AWS DMS.
# Creación de una instancia de replicación
La primera tarea de migración de una base de datos es crear una instancia de replicación. Esta instancia de replicación requiere almacenamiento y capacidad de procesamiento suficientes para realizar las tareas que se asignan y migrar datos desde la base de datos de origen a la base de datos de destino. El tamaño necesario para esta instancia varía en función de la cantidad de datos que deba migrar y las tareas que necesita que efectúe la instancia. Para obtener más información sobre las instancias de replicación, consulte [Trabajar con una instancia AWS DMS de replicación](CHAP_ReplicationInstance.md).
**Para crear una instancia de replicación mediante la AWS consola**
1. Elija **instancias de replicación** en el panel de navegación de la AWS DMS consola y, a continuación, elija **Crear instancia de replicación**.
1. En la página **Create replication instance** especifique la información de la instancia de replicación. La tabla siguiente describe la configuración que puede realizar.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/dms/latest/userguide/CHAP_ReplicationInstance.Creating.html)
1. Seleccione la pestaña **Advanced** para establecer valores para la configuración de red y cifrado de la red en caso de que lo necesite. La tabla siguiente describe la configuración.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/dms/latest/userguide/CHAP_ReplicationInstance.Creating.html)
1. Especifique la configuración **Maintenance**. La tabla siguiente describe la configuración. Para obtener más información sobre la configuración de mantenimiento, consulte [Trabajando con la ventana AWS DMS de mantenimiento](CHAP_ReplicationInstance.MaintenanceWindow.md).
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/dms/latest/userguide/CHAP_ReplicationInstance.Creating.html)
1. Elija **Create replication instance**.
# Modificación de una instancia de replicación
Puede modificar la configuración de una instancia de replicación para, por ejemplo, cambiar la clase de instancia o para aumentar el almacenamiento.
Al modificar una instancia de replicación, puede aplicar los cambios inmediatamente. Para aplicar los cambios de forma inmediata, elija la opción **Aplicar cambios inmediatamente** en la Consola de administración de AWS. O usa el `--apply-immediately` parámetro cuando llames a la API de DMS AWS CLI, o establézcalo `ApplyImmediately` en ella `true` cuando utilices la API de DMS.
Si decide no aplicar los cambios inmediatamente, estos se colocan en la cola de modificaciones pendientes. Los cambios pendientes en la cola se aplican durante el siguiente periodo de mantenimiento.
**nota**
Si opta por aplicar los cambios inmediatamente, también se aplican los cambios de la cola de modificaciones pendientes. Si alguna de las modificaciones pendientes requiere un tiempo de inactividad, al elegir **Apply changes immediately** (Aplicar cambios inmediatamente) puede causar un tiempo de inactividad imprevisto.
**Para modificar una instancia de replicación mediante la consola AWS**
1. Inicie sesión en la AWS DMS consola Consola de administración de AWS y ábrala en la versión [https://console.aws.amazon.com/dms/v2/](https://console.aws.amazon.com/dms/v2/).
1. En el panel de navegación, elija **Instancias de replicación**.
1. Elija la instancia de replicación que desee modificar. En la siguiente tabla se describen las modificaciones que puede realizar.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/dms/latest/userguide/CHAP_ReplicationInstance.Modifying.html)
## Prácticas recomendadas a la hora de modificar una instancia de replicación
Al modificar una instancia de replicación, seguir estas prácticas recomendadas ayuda a garantizar una actualización correcta con un impacto mínimo en los flujos de trabajo de migración. Siga los siguientes pasos clave antes, durante y después de las modificaciones para mantener la integridad de los datos y la eficiencia operativa durante todo el proceso.
**Programación de las modificaciones:**
+ Puede aplicar los cambios inmediatamente o programarlos para el siguiente intervalo de mantenimiento.
+ Programe los cambios durante los períodos de poco tráfico para minimizar el impacto.
**Pasos previos a la modificación:**
+ Detenga las tareas de replicación activas.
+ Compruebe que todas las tareas se hayan detenido correctamente.
+ Documente los ajustes de la tarea de configuración actual.
**Durante la modificación:**
+ Supervise el progreso de las modificaciones.
+ Espere a que aparezca el estado Disponible antes de continuar.
**Pasos posteriores a la modificación:**
+ Reanude todas las tareas detenidas anteriormente.
+ Confirme que las tareas se estén ejecutando correctamente.
# Reinicio de una instancia de replicación
Puede reiniciar una instancia de AWS DMS replicación para reiniciar el motor de replicación. Cuando se reinicia una instancia de replicación, se produce una interrupción momentánea en esta, durante la cual su estado se establece en **Rebooting** (Reiniciando). Si la AWS DMS instancia está configurada para Multi-AZ, el reinicio se puede realizar con una conmutación por error. Se crea un AWS DMS evento cuando se completa el reinicio.
Si la AWS DMS instancia es una implementación en zonas de disponibilidad múltiples (Multi-AZ), puede forzar una conmutación por error planificada de una zona de AWS disponibilidad a otra al reiniciar. Al forzar una conmutación por error planificada de la AWS DMS instancia, AWS DMS se cierran las conexiones activas de la instancia actual antes de cambiar automáticamente a una instancia en espera en otra zona de disponibilidad. Reiniciar con una conmutación por error planificada le ayuda a simular un evento de conmutación por error planificado de una AWS DMS instancia, por ejemplo, al escalar la clase de instancia de replicación.
**nota**
Después de que un reinicio fuerce una conmutación por error de una zona de disponibilidad a otra, es posible que el cambio de zona de disponibilidad no se refleje durante varios minutos. Este retraso aparece en la API y en Consola de administración de AWS las llamadas a la API and. AWS CLI AWS DMS
Si las tareas de migración se están ejecutando en la instancia de replicación cuando se reinicia, no se produce ninguna pérdida de datos, pero la tarea se detiene y el estado de la tarea cambia a un estado de error.
Si las tablas de la tarea de migración se encuentran en medio de una carga masiva (fase de carga completa) y aún no se han iniciado, pasan a un estado de error. Sin embargo, las tablas que estén completas en ese momento permanecerán en un estado completo. Si se reinicia durante la fase de carga completa, le recomendamos que realice uno de los pasos que se indican a continuación.
+ Elimine de la tarea las tablas que estén en un estado completo y reiníciela con las tablas restantes.
+ Cree una nueva tarea con tablas en estado de error y con tablas pendientes.
Si las tablas de la tarea de migración se encuentran en la fase de replicación continua, la tarea se reanuda una vez que se haya completado el reinicio.
No puede reiniciar la instancia de AWS DMS replicación si su estado no está en el estado **Disponible**. La AWS DMS instancia puede no estar disponible por varios motivos, como una modificación solicitada anteriormente o una acción relacionada con el período de mantenimiento. El tiempo necesario para reiniciar una instancia de AWS DMS replicación suele ser pequeño (menos de 5 minutos).
## Reiniciar una instancia de replicación mediante la consola AWS
Para reiniciar una instancia de replicación, utilice la AWS consola.
**Para reiniciar una instancia de replicación mediante la AWS consola**
1. Inicie sesión en la AWS DMS consola Consola de administración de AWS y ábrala en la versión [https://console.aws.amazon.com/dms/v2/](https://console.aws.amazon.com/dms/v2/).
1. En el panel de navegación, elija **Instancias de replicación**.
1. Elija la instancia de replicación que desea reiniciar.
1. Elija **Reboot**. Se abre el cuadro de diálogo **Reiniciar la instancia de replicación**.
1. Seleccione la casilla de verificación **¿Desea reiniciar con conmutación por error?** si ha configurado la instancia de replicación para la implementación Multi-AZ y desea realizar la conmutación por error en otra zona de disponibilidad de AWS .
1. Elija **Reboot**.
## Reinicio de una instancia de replicación utilizando la CLI
Para reiniciar una instancia de replicación, utilice el 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)comando con el siguiente parámetro:
+ `--replication-instance-arn`
**Example Ejemplo de reinicio normal**
En el siguiente AWS CLI ejemplo, se reinicia una instancia de replicación.
```
aws dms reboot-replication-instance \
--replication-instance-arn arn of my rep instance
```
**Example Ejemplo de reinicio normal con conmutación por error**
En el siguiente AWS CLI ejemplo, se reinicia una instancia de replicación con conmutación por error.
```
aws dms reboot-replication-instance \
--replication-instance-arn arn of my rep instance \
--force-planned-failover
```
## Reinicio de una instancia de replicación utilizando la API
Para reiniciar una instancia de replicación, utilice la [https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBInstance.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBInstance.html)acción de la AWS DMS API con los siguientes parámetros:
+ `ReplicationInstanceArn = arn of my rep instance`
**Example Ejemplo de reinicio normal**
En el siguiente ejemplo de código, se reinicia una instancia de replicación.
```
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 Ejemplo de reinicio normal con conmutación por error**
En el siguiente ejemplo de código, se reinicia una instancia de replicación y se realiza una conmutación por error a otra zona de AWS disponibilidad.
```
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
```
# Eliminación de una instancia de replicación
Puede eliminar una instancia de AWS DMS replicación cuando haya terminado de usarla. Si tiene tareas de migración que utilizan la instancia de replicación, debe detener y eliminar las tareas antes de eliminar la instancia de replicación.
Si cierra su AWS cuenta, todos los AWS DMS recursos y configuraciones asociados a ella se eliminarán después de dos días. Estos recursos incluyen todas las instancias de replicación, configuración de punto de enlace de origen y de destino, tareas de replicación y certificados SSL. Si después de dos días decides volver a utilizarlos, AWS DMS vuelves a crear los recursos que necesitas.
Si la instancia de replicación cumple con todos los criterios de eliminación y permanece en el estado `DELETING` durante un periodo prolongado, contacte con el servicio de asistencia para solucionar el problema.
## Eliminar una instancia de replicación mediante la consola AWS
Para eliminar una instancia de replicación, utilice la AWS consola.
**Para eliminar una instancia de replicación mediante la AWS consola**
1. Inicie sesión en la AWS DMS consola Consola de administración de AWS y ábrala en la versión [https://console.aws.amazon.com/dms/v2/](https://console.aws.amazon.com/dms/v2/).
1. En el panel de navegación, elija **Instancias de replicación**.
1. Elija la instancia de replicación que desea eliminar.
1. Elija **Eliminar**.
1. En el cuadro de diálogo (Confirmación), elija **Delete (Eliminar)**.
## Eliminación de una instancia de replicación con la CLI
Para eliminar una instancia de replicación, utilice el 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)comando con el siguiente parámetro:
+ `--replication-instance-arn`
**Example Ejemplo de eliminación**
En el siguiente AWS CLI ejemplo, se elimina una instancia de replicación.
```
aws dms delete-replication-instance \
--replication-instance-arn arn of my rep instance
```
## Eliminación de una instancia de replicación con la API
Para eliminar una instancia de replicación, utilice la [https://docs.aws.amazon.com/dms/latest/APIReference/API_DeleteReplicationInstance.html](https://docs.aws.amazon.com/dms/latest/APIReference/API_DeleteReplicationInstance.html)acción de la AWS DMS API con los siguientes parámetros:
+ `ReplicationInstanceArn = arn of my rep instance`
**Example Ejemplo de eliminación**
El siguiente ejemplo de código elimina una instancia de replicación.
```
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
```
# Trabajando con la ventana AWS DMS de mantenimiento
Cada instancia de AWS DMS replicación tiene un período de mantenimiento semanal durante el cual se aplican los cambios disponibles en el sistema. Puede considerar un periodo de mantenimiento como una oportunidad para controlar cuándo se producirán las modificaciones y los parches de software.
Si AWS DMS determina que se requiere mantenimiento durante una semana determinada, el mantenimiento se realizará durante el período de mantenimiento de 30 minutos que eligió al crear la instancia de replicación. AWS DMS completa la mayor parte del mantenimiento durante el período de mantenimiento de 30 minutos. Sin embargo, puede que se necesite más tiempo para los cambios más grandes.
## Efecto del mantenimiento en las tareas de migración existentes
Cuando se ejecuta una tarea de AWS DMS migración en una instancia, se producen los siguientes eventos cuando se aplica un parche:
+ Si las tablas de la tarea de migración se encuentran en la fase de replicación de cambios en curso (CDC), AWS DMS detiene la tarea por un momento y, a continuación, la reanuda después de que se aplique el parche. Después la migración continúa a partir del punto en que se interrumpió cuando se aplicó el parche.
+ Si AWS DMS se trata de **migrar una tabla como parte de una tarea de migración de datos existentes** o de **migración de datos existentes y replicación de los cambios en curso**, el DMS detiene y, a continuación, reinicia la migración de todas las tablas que estén en fase de carga completa mientras se aplica el parche. DMS también detiene y reanuda todas las tablas que se encuentran en la fase de CDC mientras se aplica el parche.
## Cambio de la configuración del periodo de mantenimiento
Puede cambiar el período de mantenimiento mediante la Consola de administración de AWS, la o la AWS CLI API. AWS DMS
### Cambio de la configuración del periodo de mantenimiento mediante la consola
Puede cambiar el marco temporal del periodo de mantenimiento mediante la Consola de administración de AWS.
**Para cambiar el periodo de mantenimiento preferido mediante la consola**
1. Inicie sesión en la AWS DMS consola Consola de administración de AWS y ábrala en la [https://console.aws.amazon.com/dms/v2/](https://console.aws.amazon.com/dms/v2/).
1. En el panel de navegación, elija **Instancias de replicación**.
1. Seleccione la instancia de replicación que desea modificar y elija **Modify**.
1. Amplíe la pestaña **Mantenimiento** y elija una fecha y hora para el periodo de mantenimiento.
1. Seleccione **Apply changes immediately**.
1. Elija **Modificar**.
### Cambio de la configuración del periodo de mantenimiento mediante la CLI
Para ajustar la ventana de mantenimiento preferida, utilice el 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)comando con los siguientes parámetros.
+ `--replication-instance-identifier`
+ `--preferred-maintenance-window`
**Example**
En el siguiente AWS CLI ejemplo, se establece el período de mantenimiento en los martes, de las 4:00 a las 4:30 de la mañana. UTC.
```
aws dms modify-replication-instance \
--replication-instance-identifier myrepinstance \
--preferred-maintenance-window Tue:04:00-Tue:04:30
```
### Cambio de la configuración del periodo de mantenimiento mediante la API
Para ajustar el período de mantenimiento preferido, utilice la [https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBInstance.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBInstance.html)acción de la AWS DMS API con los siguientes parámetros.
+ `ReplicationInstanceIdentifier = myrepinstance`
+ `PreferredMaintenanceWindow = Tue:04:00-Tue:04:30`
**Example**
En el siguiente ejemplo de código, el periodo de mantenimiento se establece para los martes de 4:00 a 4: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
```