Proceso de conmutación por error para una implementación multi-AZ de RDS Custom para SQL Server
Si se produce una interrupción planeada o no planeada de la instancia de base de datos a causa de un defecto de la infraestructura, Amazon RDS cambia automáticamente a una réplica en espera de otra zona de disponibilidad si se ha activado Multi-AZ. El tiempo requerido para completar la conmutación por error dependerá de la actividad de la base de datos y de otras condiciones existentes en el momento en que la instancia de base de datos principal deja de estar disponible. Los tiempos de conmutación por error suelen estar entre los 60 y 120 segundos. Sin embargo, las transacciones grandes o un proceso de recuperación largo pueden aumentar el tiempo de conmutación por error. Cuando la conmutación por error se haya completado, puede hacer falta más tiempo para que la consola de RDS muestre la nueva zona de disponibilidad.
nota
Puede forzar una conmutación por error manualmente cuando reinicie una instancia de base de datos con conmutación por error. Para obtener información sobre cómo reiniciar una instancia de base de datos, consulte Reinicio de una instancia de base de datos.
Amazon RDS gestiona las conmutaciones por error automáticamente para que sea posible reanudar las operaciones de la base de datos lo antes posible sin intervención administrativa. La instancia de base de datos principal conmuta automáticamente a la réplica en espera si se da cualquiera de las condiciones descritas en la siguiente tabla. Puede ver los motivos de la conmutación por error en el registro de eventos de RDS.
| Motivo de la conmutación por error | Descripción |
|---|---|
|
Se ha desencadenado una conmutación por error durante la ventana de mantenimiento para un parche del sistema operativo o una actualización de seguridad. Para obtener más información, consulte Mantenimiento de una instancia de base de datos. |
|
La implementación de una instancia de base de datos Multi-AZ detectó una instancia de base de datos principal deteriorada y se produjo una conmutación por error. |
|
El monitoreo de RDS detectó un error de accesibilidad de la red a la instancia de base de datos principal y desencadenó una conmutación por error. |
|
Una modificación de la instancia de base de datos ha activado una conmutación por error. Para obtener más información, consulte Modificación de una instancia de base de datos de RDS Custom for SQL Server. |
|
La implementación de una instancia de base de datos Multi-AZ detectó un problema de almacenamiento en la instancia de base de datos principal y se produjo una conmutación por error. |
|
La instancia de base de datos multi-AZ de RDS Custom para SQL Server se reinició con conmutación por error. Para obtener más información, consulte Reinicio de una instancia de base de datos. |
|
La instancia de base de datos principal no responde. Le recomendamos que pruebe los siguientes pasos:
|
Para determinar si se produjo una conmutación por error en la instancia de base de datos Multi-AZ, puede hacer lo siguiente:
Configure suscripciones de eventos de base de datos para notificar por correo electrónico o por SMS que se ha iniciado una conmutación por error. Para obtener más información sobre los eventos, consulte Uso de notificaciones de eventos de Amazon RDS.
Visualice sus eventos de base de datos mediante la consola de RDS o las operaciones de la API.
Puede ver el estado actual de la implementación de una instancia de base de datos multi-AZ de RDS Custom para SQL Server mediante la consola de RDS, la CLI o las operaciones de la API.
Configuración de Time to Live (TTL) con aplicaciones que utilizan una implementación multi-AZ de RDS Custom para SQL Server
El mecanismo de conmutación por error cambia automáticamente el registro del Sistema de nombres de dominio (DNS) de la instancia de base de datos para que apunte a la instancia de base de datos en espera. Como consecuencia, necesita restablecer las conexiones existentes a la instancia de base de datos. Asegúrese de que cualquier valor de configuración de tiempo de vida (TTL) de la memoria caché de DNS sea bajo y compruebe que la aplicación no almacene el DNS en caché durante un periodo prolongado. Un valor de TTL alto puede impedir que la aplicación se vuelva a conectar rápidamente a la instancia de base de datos tras la conmutación por error.
