Uso de parches sin tiempo de inactividad - Amazon Aurora

Uso de parches sin tiempo de inactividad

Realizar actualizaciones para clústeres de base de datos de Aurora MySQL implica la posibilidad de una interrupción cuando se cierra la base de datos y mientras se actualiza. De forma predeterminada, si comienza la actualización cuando la base de datos está ocupada, perderá todas las conexiones y transacciones que el clúster de bases de datos tiene en proceso. Si espera hasta que la base de datos esté inactiva para realizar la actualización, es posible que tenga que esperar mucho tiempo.

La característica de aplicación de parches sin tiempo de inactividad (ZDP) intenta, en la medida de lo posible, conservar las conexiones de cliente a través de una actualización de Aurora MySQL. Si la ZDP se completa correctamente, las sesiones de aplicación se conservan y el motor de base de datos se reinicia a la vez que la actualización está en curso. El reinicio del motor de base de datos puede provocar una disminución del rendimiento de unos segundos a aproximadamente un minuto.

La ZDP no se aplica a lo siguiente:

  • Revisiones y actualizaciones del sistema operativo (OS)

  • Actualizaciones de la versión principal

ZDP está disponible para todas las versiones de Aurora MySQL y todas las clases de instancia de base de datos admitidas.

ZDP no es compatible con Aurora Serverless v1 o las bases de datos globales de Aurora.

nota

Recomendamos que se usen solo las clases de instancia de base de datos T para los servidores de desarrollo y de pruebas, o para otros servidores que no se utilicen para la producción. Para obtener más detalles sobre las clases de instancia T, consulte Utilización de clases de instancia T para el desarrollo y la prueba.

Puede ver métricas de atributos importantes durante la ZDP en el registro de errores de MySQL. También puede ver información sobre cuándo Aurora MySQL utiliza la ZDP o elige no usar la ZDP en la página Eventos en la AWS Management Console.

En Aurora MySQL versión 2.10 y posteriores y la versión 3, Aurora puede realizar una revisión de tiempo de inactividad cero esté o no habilitada la replicación de registros binarios. Si la replicación de registros binarios está habilitada, Aurora MySQL elimina automáticamente la conexión al destino binlog durante una operación ZDP. Aurora MySQL se reconecta automáticamente al destino binlog y reanuda la reproducción después de que finalice el reinicio.

La ZDP también funciona en combinación con las mejoras de reinicio de Aurora MySQL 2.10 y versiones posteriores. La aplicación de parches a la instancia de base de datos del escritor aplica parches de forma automática a los lectores a la vez. Después de aplicar el parche, Aurora restaura las conexiones tanto en las instancias de base de datos del escritor como del lector. Antes de Aurora MySQL 2.10, la ZDP se aplica únicamente a la instancia de base de datos de escritor de un clúster.

Es posible que la ZDP no se complete correctamente en las siguientes condiciones:

  • Hay en curso consultas o transacciones de ejecución prolongada. Si Aurora puede llevar a cabo una ZDP en este caso, se cancelarán las transacciones abiertas, pero se mantendrán las conexiones.

  • Se están utilizando tablas temporales, bloqueos de usuario o bloqueos de tabla; por ejemplo, mientras se ejecutan instrucciones de lenguaje de definición de datos (DDL). Aurora interrumpe estas conexiones.

  • Existen cambios de parámetros pendientes.

Si no hubiera un período de tiempo apropiado para la realización de la ZDP debido a una o varias de estas condiciones, la aplicación de parches vuelve al comportamiento estándar.

nota

Para la versión 2 de Aurora MySQL anterior a la 2.11.0 y la versión 3 anterior a la 3.04.0, es posible que ZDP no se complete correctamente si hay conexiones Secure Socket Layer (SSL) o Transport Layer Security (TLS) abiertas.

Aunque las conexiones permanecen intactas tras una operación de ZDP correcta, se reinicializan algunas variables y características. Los siguientes tipos de información no se conservan durante un reinicio causado por una aplicación de parches sin tiempo de inactividad:

  • Variables globales. Aurora restaura las variables de sesión, pero no restaura las variables globales después del reinicio.

  • Variables de estado. En particular, el valor del tiempo de actividad que informa el estado del motor se restablece tras un reinicio que utiliza los mecanismos de ZDR o ZDP.

  • LAST_INSERT_ID.

  • Estado auto_increment en memoria para tablas. El estado de incremento automático en memoria se reinicializa. Para obtener más información sobre los valores de incremento automático, consulte el Manual de referencia de MySQL.

  • Información de diagnóstico de las tablas INFORMATION_SCHEMA y PERFORMANCE_SCHEMA. Esta información de diagnóstico también aparece en la salida de comandos como SHOW PROFILE y SHOW PROFILES.

Las siguientes actividades relacionadas con el reinicio sin tiempo de inactividad se indican en la página Events (Eventos):

  • Intento de actualizar la base de datos sin tiempo de inactividad.

  • Intento de actualizar la base de datos sin tiempo de inactividad finalizado. El evento informa cuánto tiempo tardó el proceso. El evento también informa sobre cuántas conexiones se conservaron durante el reinicio y cuántas se han eliminado. Puede consultar el registro de errores de la base de datos para ver más detalles sobre lo que ocurrió durante el reinicio.