Actualizaciones del motor de base de datos de Aurora MySQL del 07/08/2017 (versión 1.14) (obsoleta)

Versión: 1.14

Aurora MySQL 1.14 ya está disponible con carácter general. Todos los clústeres de bases de datos nuevos, incluidos los que se hayan restablecido a partir de instantáneas, se crearán en Aurora MySQL 1.14. Aurora MySQL 1.14 también es una actualización obligatoria para los clústeres de bases de datos existentes de Aurora MySQL. Enviaremos una notificación con el calendario para declarar obsoletas las versiones anteriores de Aurora MySQL.

Con la versión 1.14 de Aurora MySQL, estamos utilizando un modelo de aplicación de parches en clúster. Se aplican parches a todos los nodos de un clúster de base de datos Aurora al mismo tiempo. Las actualizaciones exigen el reinicio de la base de datos, por lo que se producirán entre 20 y 30 segundos de inactividad. A continuación, podrá volver a utilizar los clústeres de la base de datos. Si los clústeres de base de datos están ejecutando actualmente la versión 1.13, la característica de aplicación de parches sin tiempo de inactividad de Aurora podría permitir que las conexiones cliente con la instancia principal de Aurora persistieran durante la actualización, en función de la carga de trabajo.

Si tiene alguna duda, el equipo de AWS Support está disponible en los foros de la comunidad y a través de AWS Support.

Aplicación de parches sin tiempo de inactividad

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 un parche en el motor. Para obtener más información sobre la ZDP, consulte Uso de revisiones sin tiempo de inactividad en la Guía del usuario de Amazon Aurora.

Mejoras

• Se ha corregido un error incorrecto de "no se encuentra el registro" que se produce cuando se encuentra un registro en el índice secundario pero no en el principal.

• Se ha solucionado un problema de estabilidad que se puede producir si una aserción defensiva (añadida en la versión 1.12) es demasiado fuerte cuando una escritura individual abarca más de 32 páginas. Esta situación se puede producir, por ejemplo, con valores BLOB de gran tamaño.

• Se ha solucionado un problema de estabilidad debido a incoherencias entre la caché del espacio de tabla y la caché del diccionario.

• Se ha solucionado un problema en el que una réplica de Aurora deja de responder después de que supere el número máximo de intentos de conexión a la instancia principal. Ahora una réplica de Aurora se reinicia si el período de inactividad supera el período de tiempo de un latido que utiliza la instancia principal para la comprobación de estado.

• Se ha solucionado un bloqueo en directo que se puede producir en condiciones de simultaneidad muy alta cuando una conexión intenta adquirir un bloqueo de metadatos (MDL) exclusivo mientras se emite un comando, como ALTER TABLE.

• Se ha solucionado un problema de estabilidad en una réplica de lectura de Aurora en presencia de lecturas anticipadas lógicas/paralelas.

• Se ha mejorado LOAD FROM S3 de dos formas:

  1. Mejor control de los errores de tiempo de espera de Amazon S3 utilizando la operación de reintento de SDK además de la operación de reintento existente.

  2. Optimización del desempeño al cargar archivos muy grandes o un gran número de archivos almacenando en caché y reutilizando el estado del cliente.

• Se han solucionado los siguientes problemas de estabilidad con la característica de DDL rápida para las operaciones ALTER TABLE:

  1. Cuando la instrucción ALTER TABLE tiene varios comandos ADD COLUMN y los nombres de las columnas no están en orden ascendente.

  2. Cuando la cadena del nombre de la columna que se va a actualizar y su cadena de nombre correspondiente, que se obtienen de la tabla del sistema interna, son diferentes en un carácter de terminación nulo (/0).

  3. En determinadas operaciones de división de árbol B.

  4. Cuando la tabla tiene una clave principal de longitud variable.

• Se ha solucionado un problema de estabilidad con las réplicas de Aurora cuando se tarda demasiado en conseguir que su caché del índice de búsqueda de texto completo (FTS) sea coherente con la de la instancia principal. Esto puede ocurrir si aún no se han vaciado en el disco una gran parte de las entradas del índice FTS que se acaban de crear en la instancia principal.

• Se ha solucionado un problema se estabilidad que se puede producir durante la creación de índices.

• Nueva infraestructura que realiza un seguimiento del consumo de memoria por conexión y la telemetría asociada que se utilizarán para crear estrategias para evitar problemas de falta de memoria (OOM).

• Se ha solucionado un problema en el que ANALYZE TABLE se permitía incorrectamente en las réplicas de Aurora. Ahora se ha bloqueado.

• Se ha solucionado un problema de estabilidad provocado por un interbloqueo extraño como resultado de una condición de carrera entre una lectura anticipada lógica y la purga.

Integración de correcciones de errores de MySQL.

• Una búsqueda de texto completo combinada con tablas derivadas (subconsultas de la cláusula FROM) producía una salida del servidor. Ahora, si una operación de texto completo depende de una tabla derivada, el servidor produce un error que indica que no se puede realizar una búsqueda de texto completo en una tabla materializada. (Error n.º 68751 y error n.º 16539903)