Actualizaciones del motor de base de datos de Aurora MySQL del 25/05/2021 (versión 2.10.0) (obsoleta)

CVE-2021-23841

CVE-2021-3449

CVE-2020-28196

CVE-2020-14790

CVE-2020-14776

CVE-2020-14567

CVE-2020-14559

CVE-2020-14553

CVE-2020-14547

CVE-2020-14540

CVE-2020-14539

CVE-2018-3251

CVE-2018-3156

CVE-2018-3143

CVE-2016-5440

Ahora se admite la clase de instancia db.t3.large para Aurora MySQL.

Replicación de registros binarios:

Disponibilidad mejorada de las instancias de lector:

Se ha mejorado el rendimiento de las lecturas de página de lectura anticipada solicitadas por la técnica lógica de lectura anticipada (LRA). Esto se hizo mediante la agrupación de las lecturas de varias páginas en una única solicitud enviada al almacenamiento de Aurora. Como resultado, las consultas que utilizan la optimización LRA se ejecutan hasta tres veces más rápido.

Reinicios y aplicación de parches sin tiempo de inactividad:

Mejoras para un inicio más rápido cuando la base de datos tiene un gran número de índices y tablas temporales creados durante una actividad DDL interrumpida anteriormente.

Se han corregido varios problemas relacionados con reinicios repetidos durante la recuperación de bloqueos de las operaciones DDL interrumpidas, como DROP TRIGGER, ALTER TABLE y específicamente ALTER TABLE, que modifican el tipo de partición o el número de particiones en una tabla.

Se ha corregido un problema que podía provocar el reinicio del servidor durante el procesamiento de registros de flujos de actividad de bases de datos (DAS).

Se ha corregido un problema al imprimir un mensaje de error al procesar una consulta de ALTER en tablas del sistema.

Se ha corregido un problema por el que la caché de consultas podía devolver resultados obsoletos en una instancia de lector.

Se ha corregido un error que provocaba que algunas métricas de confirmación de Aurora no se actualizaran cuando la variable de sistema innodb_flush_log_at_trx_commit se establecía en 0 o 2.

Se ha corregido un problema por el que el resultado de una consulta almacenada en la caché de consultas no se actualizaba mediante transacciones multiestado.

Se ha corregido un error que podía provocar que la última marca temporal modificada de los archivos de registro binario no se actualizara correctamente. Esto podría provocar que los archivos de registro binario se purguen de forma prematura, antes de alcanzar el periodo de retención configurado por el cliente.

Se ha corregido el nombre y la posición del archivo binlog que se informaron de forma incorrecta de InnoDB después de la recuperación de bloqueos.

Se ha corregido un problema que podía provocar que las transacciones grandes generaran eventos binlog incorrectos si el parámetro binlog_checksum se establecía en NONE.

Se ha corregido un problema que provocaba que una réplica binlog se detuviera con un error si la transacción reproducida contenía una instrucción DDL y un gran número de cambios de fila.

Se ha corregido un problema que provocaba un reinicio en una instancia de lector al soltar una tabla.

Se ha corregido un error que provocaba que los conectores de código abierto fallaran al intentar consumir un archivo binlog con una transacción grande.

Se ha corregido un problema que podía provocar resultados de consulta incorrectos en la columna de geometría grande después de crear un índice espacial en la tabla con los valores de geometría grandes.

La base de datos vuelve a crear el espacio de tabla temporal durante el reinicio, lo que permite liberar y recuperar el espacio de almacenamiento asociado.

Se ha corregido un error que impedía truncar las tablas de performance_schema en las instancias de lector de Aurora.

Se ha corregido un problema que provocaba que una réplica binlog se detuviera por un error HA_ERR_KEY_NOT_FOUND.

Se ha corregido un problema que provocaba que la base de datos se reiniciara al ejecutar una declaración FLUSH TABLES WITH READ LOCK.

Se ha corregido un error que impedía el uso de funciones de bloqueo de nivel de usuario en instancias de lector de Aurora.

Las transacciones entrelazadas en ocasiones podían bloquear el aplicador de réplica cuando el nivel de aislamiento de transacciones se estableció en REPEATABLE READ. (Error n.º 25040331)

Cuando un procedimiento almacenado contenía una declaración que hacía referencia a una vista que a su vez hacía referencia a otra vista, el procedimiento no podía invocarse correctamente más de una vez. (Error n.° 87858, error n.° 26864199)

Para consultas con muchas condiciones de OR, el optimizador ahora es más eficiente en la memoria y es menos probable que exceda el límite de memoria impuesto por la variable de sistema range_optimizer_max_mem_size. Además, el valor predeterminado de esa variable se ha elevado de 1 536 000 a 8 388 608. (Error n.° 79450, error n.° 22283790)

Reproducción: en la función next_event(), a la que llama al subproceso SQL de una réplica para leer el siguiente evento del registro de retransmisión, el subproceso SQL no liberó el relaylog.log_lock que adquirió cuando se produjo un error (por ejemplo, debido a un registro de retransmisión cerrado). Esto provocó que se bloqueen todos los demás subprocesos que esperaban adquirir un bloqueo en el registro de retransmisión. Con esta corrección, el bloqueo se libera antes de que el subproceso SQL deje la función bajo la situación. (Error n.° 21697821)

Corregir un daño de memoria para ALTER TABLE con columna virtual. (Error n.° 24961167; error n.° 24960450)

Reproducción: las réplicas de subprocesos múltiples no se podían configurar con tamaños de cola pequeños mediante slave_pending_jobs_size_max si alguna vez necesitaban procesar transacciones de mayor tamaño que ese tamaño. Cualquier paquete mayor que slave_pending_jobs_size_max se rechazaba con el error ER_MTS_EVENT_BIGGER_PENDING_JOBS_SIZE_MAX, incluso si el paquete era inferior al límite establecido por slave_max_allowed_packet. Con esta corrección, slave_pending_jobs_size_max se convierte en un límite flexible en lugar de un límite invariable. Si el tamaño de un paquete supera slave_pending_jobs_size_max, pero es inferior a slave_max_allowed_packet, la transacción se retiene hasta que todos los trabajos de réplica tengan colas vacías y, a continuación, se procesen. Todas las transacciones posteriores se mantienen hasta que se haya completado la transacción grande. Por lo tanto, el tamaño de la cola de los trabajos de réplicas puede limitarse a la vez que permite transacciones más grandes ocasionales. (Error n.° 21280753, error n.° 77406)

Reproducción: cuando se utiliza una réplica de subprocesos múltiples, los errores del aplicador mostraban datos de ID de trabajos que no eran coherentes con los datos externalizados en las tablas de reproducción del esquema de rendimiento. (Error n.° 25231367)

Replicación: en una réplica de replicación basada en GTID que se ejecuta con -GTID-Mode=ON, -log-bin=OFF y usando -, cuando se detectaba un error que debía ignorarse, no se actualizaba slave-skip-errors correctamente, lo que provocaba una pérdida de sincronía con. Exec_Master_Log_Pos Exec_Master_Log_Pos Read_master_log_pos Si no se especificaba un GTID_NEXT, la réplica nunca actualizaba su estado GTID al retroceder desde una transacción de una única instrucción. El Exec_Master_Log_Pos no se podía actualizar porque, aunque la transacción había finalizado, su estado GTID mostraba lo contrario. La corrección elimina la limitación de actualizar el estado de GTID cuando una transacción se deshace solo si GTID_NEXT se especifica. (Error n.° 22268777)

Reproducción: una sentencia con errores parciales no consumía correctamente un GTID generado automáticamente o especificado cuando se deshabilitaba el registro binario. La corrección garantiza que un DROP TABLE con errores parciales, un DROP USER con errores parciales o un DROP VIEW con errores parciales consuman respectivamente el GTID pertinente y lo guarden en @@GLOBAL.GTID_EXECUTED y en la tabla mysql.gtid_executed cuando se desactiva el registro binario. (Error n.° 21686749)

Reproducción: las réplicas que ejecutan MySQL 5.7 no se han podido conectar a una fuente MySQL 5.5 debido a un error al recuperar el server_uuid, que no forma parte de MySQL 5.5. Esto se debió a cambios en el método de recuperación del server_uuid. (Error n.° 22748612)

Reproducción: el mecanismo de omisión de transacciones GTID que omite silenciosamente una transacción GTID ejecutada anteriormente no funcionaba correctamente para las transacciones XA. (Error n.° 25041920)

Las instrucciones ">XA ROLLBACK que fallaron debido a que se proporcionó un ID de transacción incorrecto, se podían registrar en el registro binario con el ID de transacción correcto y, por lo tanto, las réplicas de reproducción podían accionarlas. Ahora se comprueba la situación de error antes de que se produzca el registro binario y no se registran las instrucciones XA ROLLBACK fallidas. (Error n.° 26618925)

Replicación: si se configuró una réplica mediante una sentencia CHANGE MASTER TO que no especificaba el nombre del archivo de registro de origen ni la posición del registro de origen, se apagó antes de que se emitiera START SLAVE y, a continuación, se reinició con la opción - relay-log-recovery set, la replicación no se inició. Esto ocurría porque el subproceso receptor no se había iniciado antes de intentar recuperar el registro de retransmisión, por lo que no había ningún evento de rotación de registros disponible en el registro de retransmisión para proporcionar el nombre del archivo de registro de origen y la posición del registro de origen. En esta situación, la réplica ahora omite la recuperación del registro de retransmisión y registra una advertencia y, a continuación, procede a iniciar la reproducción. (Error n.° 28996606, error n.° 93397)

Reproducción: en la reproducción basada en filas, aparecía un mensaje que mostraba incorrectamente las longitudes de campo al reproducir desde una tabla con una columna utf8mb3 a una tabla de la misma definición en la que la columna se había definido con un conjunto de caracteres utf8mb4. (Error n.° 25135304, error n.° 83918)

Reproducción: cuando se emitía una instrucción RESET SLAVE en una réplica de reproducción con GTID en uso, se purgaban los archivos de registro de retransmisión existentes, pero el nuevo archivo de registro de retransmisión de reemplazo se generaba antes de que se eliminara el conjunto de GTID recibidos para el canal. Por lo tanto, el conjunto de GTID anterior se escribía en el nuevo archivo de registro de retransmisión como el evento PREVIOUS_GTIDS, lo que provocaba un error fatal en la reproducción que indica que la réplica tenía más GTID que el origen, aunque el conjunto gtid_executed para ambos servidores estaba vacío. Ahora, cuando se emite RESET SLAVE, el conjunto de GTID recibidos se borra antes de generar el nuevo archivo de registro de retransmisión, de modo que no se produzca esta situación. (Error n.° 27411175)

Reproducción: con los GTID utilizados para la reproducción, las transacciones, incluidas las instrucciones que provocaron un error de análisis (ER_PARSE_ERROR), no se podían omitir manualmente mediante el método recomendado para insertar una transacción vacía o de reemplazo con el mismo GTID. Esta acción debería dar lugar a que la réplica identifique el GTID como ya utilizado y, por lo tanto, salte la transacción no deseada que compartía su GTID. Sin embargo, en el caso de un error de análisis, dado que la instrucción se analizaba antes de verificar el GTID para ver si era necesario omitirlo, el subproceso del aplicador de reproducción se detenía debido al error de análisis, aunque la intención era omitir la transacción de todos modos. Con esta corrección, el subproceso del aplicador de reproducción ahora ignora los errores de análisis si es necesario omitir la transacción en cuestión porque ya se ha utilizado el GTID. Tenga en cuenta que este cambio de comportamiento no se aplica en el caso de cargas de trabajo formadas por la salida de registro binario producida por mysqlbinlog. En esa situación, se corría el riesgo de que una transacción con un error de análisis que sigue inmediatamente después de una transacción omitida también se omitiera silenciosamente, cuando debería generar un error. (Error n.° 27638268)

Reproducción: habilita el subproceso SQL para que GTID salte una transacción parcial. (Error n.° 25800025)

Reproducción: cuando se suministraba un parámetro de tiempo de espera negativo o fraccional a WAIT_UNTIL_SQL_THREAD_AFTER_GTIDS(), el servidor se comportaba de forma inesperada. Con esta corrección:

Reproducción: si la función WAIT_FOR_EXECUTED_GTID_SET() se utilizaba con un valor de tiempo de espera que incluía una parte fraccionada (por ejemplo, 1,5), un error en la lógica de conversión hacía que el tiempo de espera se redondeara al segundo entero más cercano y a cero para valores inferiores a 1 segundo (por ejemplo, 0,1). La lógica de conversión se ha corregido ahora para que el valor de tiempo de espera se aplique como se especificó originalmente, sin redondeo. Gracias a Dirkjan Bussink por la contribución. (Error n.° 29324564, error n.° 94247)

Con los GTID habilitados, XA COMMIT en una transacción XA desconectada dentro de una transacción de varias instrucciones generaba una afirmación. (Error n.° 22173903)

Reproducción: se generaba una afirmación en las compilaciones de depuración si se emitía una sentencia XA ROLLBACK para un identificador de transacción desconocido cuando el valor gtid_next se establecía manualmente. El servidor ahora no intenta actualizar el estado GTID si una sentencia XA ROLLBACK falla con un error. (Error n.° 27928837, error n.° 90640)

Se solucionó un problema de orden de clasificación incorrecto cuando se utilizan varias funciones CASE en la cláusula ORDER BY (Error n.° 22810883).

Algunas consultas que utilizaban el orden podían acceder a una columna no inicializada durante la optimización y provocar la salida del servidor (Error n.º 27389294).

Combinaciones hash. Para obtener más información, consulte Optimización de consultas de combinación grandes de Aurora MySQL con combinaciones de hash en la Guía del usuario de Amazon Aurora.

Funciones nativas para invocar funciones de forma sincrónica. AWS Lambda Para obtener más información, consulte Invocación de una función de Lambda con una función nativa de Aurora MySQL en la Guía del usuario de Amazon Aurora.

Agrupación en lotes de análisis. Para obtener más información, consulte Actualizaciones del motor de base de datos de Aurora MySQL del 11/12/2017 (versión 1.16) (obsoleta).

Migración de datos desde MySQL con un bucket de Amazon S3. Para obtener más información, consulte Migración de datos desde MySQL con un bucket de Amazon S3 en la Guía del usuario de Amazon Aurora.

Complemento de replicación de grupo

Tamaño de página incrementado

Carga de grupo de búfer de InnoDB al inicio

Complemento de analizador de texto completo de InnoDB

Replicación de varios orígenes

Cambio de tamaño de grupo de búfer online

Complemento de validación de contraseñas

Complementos de reescritura de consulta

Filtrado de replicación

La instrucción SQL CREATE TABLESPACE