¿Cuáles son los factores que influyen en el tiempo de inactividad de los clústeres de bases de datos de Amazon Aurora?
Quiero entender por qué mi clúster de la base de datos de Amazon Aurora está inactivo.
Descripción breve
Sus instancias de base de datos de Amazon Aurora pueden estar inactivas por varios motivos. Los principales factores que influyen en el tiempo de inactividad son los siguientes:
- Actualizaciones de la versión del motor
- Conmutaciones por error del clúster de la base de datos
- Tareas de mantenimiento
- Reinicios de instancias o clústeres de bases de datos
- Modificación de configuraciones específicas de la instancia o clúster de base de datos
Resolución
Nota: Si recibe errores al ejecutar los comandos de la interfaz de la línea de comandos de AWS (AWS CLI), asegúrese de utilizar la versión más reciente de AWS CLI.
Actualizaciones de la versión del motor
Las actualizaciones de la versión del motor incluyen actualizaciones de versiones principales y secundarias. Tanto las actualizaciones principales como las secundarias provocan un tiempo de inactividad en todo el clúster de la base de datos de Aurora. Antes de actualizar un clúster de base de datos de producción, es importante que pruebe el proceso de actualización en un clúster de base de datos de prueba. Compruebe la duración del proceso y, a continuación, valide las aplicaciones antes de llevar a cabo la actualización.
También puede utilizar el despliegue azul-verde de Amazon Relational Database Service (Amazon RDS) para actualizar la versión principal o secundaria de su clúster. El tiempo de inactividad suele durar menos de un minuto en el caso de las actualizaciones cuando se utiliza el despliegue azul-verde.
Actualizaciones automáticas de versiones secundarias
Las actualizaciones automáticas de versiones secundarias provocan tiempo de inactividad en todo el clúster de la base de datos de Aurora. Estas actualizaciones automáticas de versiones secundarias se aplican durante el período de mantenimiento del clúster. Si no necesita esta función, desactive las actualizaciones automáticas de versiones secundarias en sus instancias de base de datos.
Para obtener más información, consulte Actualización de la versión secundaria o el nivel de parche de un clúster de bases de datos Aurora MySQL.
Nota: La activación de la función de actualizaciones automáticas de versiones secundarias en sí misma no provoca tiempo de inactividad durante la modificación. El tiempo de inactividad se produce solo cuando Aurora aplica la actualización automática.
Conmutación por error del clúster de la base de datos
Si el clúster de la base de datos de Aurora tiene una o más réplicas de Aurora, la réplica se promueve a la instancia principal durante los eventos de conmutación por error. Se produce un breve tiempo de inactividad y las operaciones de lectura y escritura fallan con una excepción. El servicio normalmente se restaura en menos de 120 segundos y, a menudo, en menos de 60 segundos.
Para aumentar la disponibilidad del clúster de la base de datos, cree una o más réplicas de Aurora en dos o más zonas de disponibilidad (AZ) diferentes. Para obtener más información, consulte Tolerancia a errores para un clúster de base de datos de Aurora.
Tareas de mantenimiento para el clúster de la base de datos de Aurora
Algunas tareas de mantenimiento, como las actualizaciones del sistema operativo o la aplicación de parches a la base de datos, hacen que el clúster de la base de datos se desconecte durante un breve período de tiempo. Para obtener más información, consulte Mantenimiento de un clúster de base de datos de Amazon Aurora.
Período de mantenimiento
El tiempo de inactividad no se produce de forma inherente cuando se modifica el período de mantenimiento. Sin embargo, es posible que el clúster de la base de datos tenga una o más acciones pendientes que provoquen tiempo de inactividad. Si cambia el periodo de mantenimiento, aplica las acciones pendientes inmediatamente y se produce un tiempo de inactividad. Para obtener más información sobre cómo modificar el periodo de mantenimiento, consulte ¿Qué tengo que saber sobre el periodo de mantenimiento de Amazon RDS?
Reinicios de clústeres o instancias de base de datos
El reinicio de un clúster o una instancia de base de datos provoca un tiempo de inactividad. El tiempo necesario para reiniciar cada instancia de base de datos del clúster depende de la actividad de la base de datos en el momento del reinicio. El tiempo de inactividad también depende del proceso de recuperación del motor específico de la base de datos. Para obtener más información, consulte Reinicio de un clúster de base de datos de Amazon Aurora o de una instancia de base de datos de Amazon Aurora.
Modificación de la clase de instancia de base de datos
Al modificar la clase de instancia de base de datos, se produce un tiempo de inactividad en la instancia de base de datos concreta, pero no en todo el clúster. Para obtener más información sobre las clases de instancias, consulte Clases de instancia de base de datos Aurora.
Adjuntar un nuevo clúster o grupo de parámetros de la base de datos
Al modificar el clúster o el grupo de parámetros de la base de datos adjunto a la instancia de base de datos, el tiempo de inactividad no se produce automáticamente. Sin embargo, para aplicar cambios a un grupo de parámetros del clúster de la base de datos, debe reiniciar la instancia de base de datos principal del clúster. Para los grupos de parámetros de base de datos, debe reiniciar la instancia para aplicar los cambios. El reinicio en sí mismo provoca un tiempo de inactividad. Para obtener más información, consulte Asociación de un grupo de parámetros de clúster de base de datos con un clúster de base de datos y Trabajo con los grupos de parámetros.
Modificación de configuraciones específicas de la instancia o clúster de base de datos
Modificación de la configuración de parámetros en un clúster o grupo de parámetros de base de datos
Los parámetros de la base de datos son estáticos o dinámicos. Al modificar la configuración de un parámetro estático en un clúster o grupo de parámetros de base de datos, el cambio de parámetro surtirá efecto después de reiniciar manualmente las instancias de base de datos de cada clúster de base de datos asociado. El tiempo de inactividad se produce durante el reinicio.
Sin embargo, cuando modifica una configuración de parámetros dinámicos en un clúster o grupo de parámetros de base de datos, los cambios se aplican inmediatamente al clúster de base de datos. La instancia no se reinicia al modificar los parámetros dinámicos, por lo que no hay tiempo de inactividad.
Para obtener más información, consulte Trabajo con grupos de parámetros.
Modificación del identificador de instancia de base de datos
El tiempo de inactividad se produce cuando se modifica el identificador de la instancia de base de datos porque esta se reinicia.
Modificación del puerto de la base de datos
El tiempo de inactividad se produce cuando se modifica el puerto de la base de datos que quiere utilizar para acceder al clúster de la base de datos. Esto ocurre porque todas las instancias de base de datos del clúster se reinician inmediatamente.
Modificación de la autoridad de certificación
Puede que quiera modificar la autoridad de certificación (CA) del certificado del servidor que utiliza la instancia de base de datos. En este caso de uso, se produce un tiempo de inactividad si el motor de la base de datos no admite la rotación sin reinicio. Utilice el comando de AWS CLI describe-db-ngine-versions para comprobar si el motor de la base de datos admite la rotación sin reinicio.
Para obtener más información sobre qué ajustes de Aurora influyen o no en el tiempo de inactividad, consulte Configuración para Amazon Aurora.
Información relacionada
Performing major version upgrades for Amazon Aurora MySQL with minimum downtime (Realización de actualizaciones principales de la versión para MySQL de Amazon Aurora con un tiempo de inactividad mínimo)
Contenido relevante
- ¿Qué factores afectan a mi tiempo de inactividad o al rendimiento de mi base de datos en Amazon RDS?OFICIAL DE AWSActualizada hace 3 años
- OFICIAL DE AWSActualizada hace 3 años
- OFICIAL DE AWSActualizada hace 2 años