¿Por qué se reinició o se conmutó por error mi instancia de replicación de AWS DMS?

Descripción corta

Una instancia de replicación de AWS DMS se reinicia automáticamente por los siguientes motivos:

• Hay un problema de infraestructura con la instancia principal, como una pérdida de conectividad de red, un problema con la unidad de procesamiento o un problema de almacenamiento.
• El tipo de clase de instancia cambió como resultado de una actividad de escalado vertical.
• Hay un parche de software en curso en el host de la instancia durante un período de mantenimiento específico. Para más información, consulte Trabajar con versiones del motor de replicación.
• Usó las opciones Reiniciar o Reiniciar con conmutación por error planificada para realizar un reinicio manual de la instancia.

Cuando la instancia de replicación experimenta problemas y no responde a las comprobaciones de estado de AWS DMS, AWS DMS inicia automáticamente una recuperación o una conmutación por error. Para los despliegues Single-AZ, AWS DMS inicia una recuperación. En el caso de despliegues Multi-AZ, AWS DMS inicia una conmutación por error. A continuación, AWS DMS reinicia la instancia de replicación antes de que pueda reanudar manualmente las tareas de migración de la base de datos.

Resolución

Revisión de los eventos de AWS DMS para identificar la causa raíz

Para identificar la causa del reinicio o la conmutación por error de la instancia, consulte los eventos de AWS DMS de las últimas 24 horas. Abra la consola de AWS DMS y elija Eventos.

Nota: De forma predeterminada, AWS DMS registra los eventos en la zona horaria UTC.

Si quiere almacenar eventos durante mucho tiempo, envíe los eventos de AWS DMS a Amazon EventBridge. Para más información, consulte Implementación de un enfoque automatizado para gestionar los eventos operativos de AWS DMS.

Si ve el mensaje de evento Instancia de replicación parcheada, significa que se ha realizado una actualización de la versión del motor en la instancia de replicación. La actualización se puede realizar inmediatamente después de la modificación de la instancia o durante el período de mantenimiento programado.

Si el tipo de clase de instancia cambia, verá el mensaje de evento La clase de esta instancia de replicación se está cambiando o La clase de esta instancia de replicación ha cambiado. Los despliegues Single-AZ no estarán disponibles durante unos minutos mientras se haga una operación de escalado. Los despliegues Multi-AZ no estarán disponibles mientras dure la conmutación por error. La conmutación por error suele durar unos 60 segundos. AWS DMS actualiza la base de datos en espera antes de que se produzca una conmutación por error en la base de datos con el nuevo tamaño.

Es posible que vea los mensajes de evento Se inició la conmutación por error de la instancia Multi-AZ o Se completó la conmutación por error de la instancia Multi-AZ por los siguientes motivos:

• La instancia de replicación principal no responde.
• La instancia se reinició manualmente con las opciones Reiniciar o Reiniciar con una conmutación por error planificada.
• La instancia de replicación experimenta problemas de red intermitentes con el host subyacente.

Supervisión de las métricas de AWS DMS con el panel de supervisión mejorado

AWS DMS ofrece métricas desde el panel de supervisión mejorado a Registros de Amazon CloudWatch. Consulte el registro Instancias de replicación para conocer las métricas de rendimiento, uso de recursos y estado.

Nota: Las replicaciones sin servidor de AWS DMS no admiten la supervisión mejorada.

Activación de los despliegues Multi-AZ para reducir el tiempo de inactividad

Para reducir el tiempo de inactividad, active los despliegues Multi-AZ. En un despliegue Multi-AZ, hay disponible una réplica en espera de la instancia de replicación en una zona de disponibilidad diferente. Para más información, consulte Resiliencia en AWS Database Migration Service.

Nota: En las instancias que utilizan Amazon Simple Storage Service (Amazon S3) como destino, AWS DMS puede escribir registros duplicados en su bucket de S3. Esto ocurre cuando se reanuda la tarea tras un reinicio o una conmutación por error y TargetTablePrepMode se establece en DO_NOTHING.

Información relacionada

Best practices for AWS Database Migration Service

Working with an AWS DMS replication instance