Actualizaciones del motor SQL de base de datos Aurora My 2023-10-25 (versión 3.05.0, compatible con My 8.0.32) SQL - Amazon Aurora

Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

Actualizaciones del motor SQL de base de datos Aurora My 2023-10-25 (versión 3.05.0, compatible con My 8.0.32) SQL

Versión: 3.05.0

Aurora My SQL 3.05.0 está disponible de forma general. Las versiones Aurora My SQL 3.05 son compatibles con My SQL 8.0.32. Para obtener más información sobre los cambios que se han producido en la comunidad, consulte las notas de la versión de My SQL 8.0.

Para obtener más información sobre las nuevas funciones de Aurora My SQL versión 3, consulte Aurora My SQL versión 3 compatible con My SQL 8.0. Para ver las diferencias entre Aurora My SQL versión 3 y Aurora My SQL versión 2, consulte Comparación de Aurora My SQL versión 2 y Aurora My SQL versión 3. Para ver una comparación de Aurora My SQL versión 3 y My SQL 8.0 Community Edition, consulte Comparación de Aurora My SQL versión 3 y My SQL 8.0 Community Edition.

Las SQL versiones de Aurora My compatibles actualmente son 2.07.9, 2.07.10, 2.11.*, 2.12.*, 3.03.*, 3.04.* y 3.05.*.

Puede realizar una actualización in situ, restaurar una instantánea o iniciar una actualización azul/verde gestionada mediante Amazon RDS Blue/Green Deployments desde cualquier clúster de Aurora My versión SQL 2 compatible actualmente a un clúster de Aurora My versión 3.05.0. SQL

Para obtener información sobre la planificación de una actualización a la SQL versión 3 de Aurora My, consulte Planificación de la actualización de Aurora My SQL versión 3 en la Guía del usuario de Amazon Aurora. Para obtener información general sobre las SQL actualizaciones de Amazon Aurora My, consulte Actualización de los clústeres de Amazon Aurora My SQL DB en la Guía del usuario de Amazon Aurora.

Para obtener información sobre la solución de problemas, consulte Solución de problemas de actualización con Aurora My SQL versión 3.

Si tiene alguna pregunta o duda, el servicio de AWS asistencia está disponible en los foros de la comunidad y a través de AWS Support. Para obtener más información, consulte Mantenimiento de un clúster de base de datos de Amazon Aurora en la Guía del usuario de Amazon Aurora.

Mejoras

Nuevas características:

  • Se ha añadido compatibilidad para guardar datos de un clúster de SQL base de datos Aurora My en archivos de texto en un bucket de Amazon S3 cifrados con una KMS clave (SSE-KMS). Para obtener más información, consulte Guardar datos de un clúster My SQL DB de Amazon Aurora en archivos de texto en un bucket de Amazon S3.

  • Se ha introducido una nueva variable de estado global aurora_tmz_version para indicar la versión actual de la información de zona horaria (TZ) utilizada por el motor. Los valores siguen la versión de la base de datos de zonas IANA horarias y tienen el formato YYYYsuffix ««, por ejemplo, 2022a y 2023c. Para obtener más información, consulte Aurora My SQL Global Status Variables.

Se corrigieron los problemas de seguridad que CVEs se enumeran a continuación:

Correcciones y otras mejoras para ajustar la administración en un entorno administrado. A continuación se muestran las CVE correcciones adicionales:

Mejoras de disponibilidad:

  • Se ha corregido un problema por el que las instancias SQL de base de datos Aurora My que utilizaban consultas paralelas podían sufrir un reinicio de la base de datos al ejecutar un número elevado de consultas paralelas simultáneas.

  • Se ha corregido un problema de bloqueo provocado por un subproceso de registro de auditoría que, en última instancia, provocaba un alto nivel de CPU utilización y tiempos de espera de las aplicaciones cliente.

  • Se ha corregido un problema que podía provocar que el GTID conjunto ejecutado se recuperara incorrectamente en un clúster de réplicas de registros binarios (binlog) con el registro de binlog mejorado activado cuando cualquier fuente de binlog estaba configurada en o. gtid_mode ON ON_PERMISSIVE Este problema podía provocar que la instancia de grabación del clúster de réplicas se reiniciara una vez más durante la recuperación o que se produjeran resultados incorrectos al consultar el conjunto ejecutado. GTID

  • Se ha corregido un problema de administración de memoria que podía provocar el reinicio de una instancia de SQL base de datos Aurora My o una conmutación por error debido a una disminución de la memoria liberable cuando se habilitaba el registro binario mejorado.

  • Se ha corregido un problema que podía provocar que una instancia de base de datos se reiniciara al intentar leer una página de base de datos que pertenecía a una tabla eliminada.

  • Se ha corregido un problema que podía provocar que la instancia de lector se reiniciara cuando la instancia de escritor aumentaba el volumen de la base de datos a un múltiplo de 160 GB.

  • Se ha corregido un problema que provocaba que una instancia de Mi SQL base de datos Aurora con la función de registro binario mejorada habilitada se atascara durante el inicio de la instancia de base de datos mientras se ejecutaba el proceso de recuperación del registro binario.

  • Se solucionó un problema por el que una instancia de Aurora My SQL Database podía experimentar varios reinicios durante el inicio de la instancia mientras se inicializaban segmentos de reversión grandes.

  • Se ha corregido un problema que, durante la aplicación de parches sin tiempo de inactividad, provocaba el reinicio de la instancia y el cierre inesperado de las conexiones de la base de datos.

  • Se ha corregido un problema que podía provocar el reinicio de una instancia de base de datos debido a un bloqueo durante la ejecución y a la ejecución simultánea de sentencias. SHOWSTATUSPURGEBINARYLOGS PURGE BINARY LOGS es una instrucción administrada que se ejecuta para respetar el período de retención de binlogs configurado por el usuario.

  • Se ha corregido un problema que podía provocar que el clúster de base de datos no estuviera disponible si la instancia de escritor se reiniciaba mientras la base de datos estaba creando o eliminando desencadenadores en las tablas internas del sistema.

  • Se ha corregido un problema que podía provocar que una instancia de base de datos se reiniciara debido a esperas de semáforo prolongadas al utilizar la característica de binlog mejorado en un clúster con una réplica de Aurora.

  • Se ha corregido un problema que podía provocar que una instancia de base de datos se reiniciara al ejecutar una consulta que hacía referencia a una función de agregación.

  • Se ha corregido un problema que, en casos excepcionales, podía provocar que la instancia de base de datos se reiniciara cuando Aurora Serverless v2 intentara actualizar incorrectamente la caché de tabla mientras estaba en curso el escalado.

  • Se solucionó un problema por el que se utilizaban métodos de acceso a la digitalización de índices no compatibles para las expresiones de tabla comunes (CTE) y, al mismo tiempo, se materializaban tablas temporales intermedias, lo que podía provocar un comportamiento no deseado, como el reinicio de la base de datos o la obtención de resultados de consulta incorrectos. Hemos solucionado este problema evitando el uso de métodos de acceso a la digitalización de índices no compatibles en las tablas mediante el motor de almacenamiento. TempTable

Mejoras generales:

  • Se ha corregido un problema que podía provocar la falta de disponibilidad de la base de datos cuando el binlog mejorado estaba habilitado en un clúster de Aurora Serverless v2 base de datos que se ejecutaba en Aurora My SQL 3.04.0.

  • Se han eliminado los metadatos de almacenamiento no utilizados antes de escribirlos en el almacenamiento de Aurora cuando la característica binlog mejorado estaba habilitada. Esto evita ciertas situaciones en las que se puede producir un reinicio de la base de datos o una conmutación por error debido al aumento de la latencia de escritura por un aumento de los bytes transmitidos a través de la red.

  • Con la incorporación de las tablas malloc_stats y malloc_stats_totals en performance_schema, se han añadido tres variables avanzadas del sistema para controlar el comportamiento de Jemalloc, un asignador de memoria interno:

    • aurora_jemalloc_background_thread.

    • aurora_jemalloc_dirty_decay_ms.

    • aurora_jemalloc_tcache_enabled.

  • Se ha corregido un problema por el que no se creaban determinadas tablas de esquemas de rendimiento de Aurora tras una actualización o migración.

  • Se ha añadido una nueva variable de sistema (aurora_use_vector_instructions). Cuando este parámetro está habilitado, Aurora My SQL utiliza instrucciones de procesamiento vectorial optimizadas para mejorar el rendimiento en cargas de trabajo de E/S pesadas. Esta configuración está activada de forma ON predeterminada en Aurora My SQL 3.05 y versiones posteriores. Para obtener más información, consulte Aurora My SQL configuration parameters.

  • Se ha corregido un problema que podía provocar que las NumBinaryLogFiles métricas activadas CloudWatch mostraran resultados incorrectos cuando el binlog mejorado estaba activado.

  • El tiempo de espera de solicitud para las operaciones de Aurora My SQL Machine Learning a Amazon Sagemaker se ha incrementado de 3 a 30 segundos. Esto ayuda a resolver un problema por el que los clientes pueden ver un mayor número de reintentos o errores en las solicitudes a Amazon Sagemaker desde Aurora My SQL Machine Learning cuando utilizan lotes de mayor tamaño.

  • Se ha añadido compatibilidad con las tablas malloc_stats y malloc_stats_totals en la base de datos performance_schema.

  • Se ha actualizado la palabra clave FROM del comando LOAD DATA FROM S3 para que sea opcional. Para obtener más información, consulte Carga de datos en un clúster de Amazon Aurora My SQL DB desde archivos de texto de un bucket de Amazon S3.

  • Se ha añadido compatibilidad con el parámetro innodb_aurora_instant_alter_column_allowed, que controla si se puede utilizar el algoritmo INSTANT para las operaciones ALTER COLUMN. Para obtener más información, consulte Parámetros de nivel de clúster.

  • Se ha corregido un problema que podía impedir que se establecieran nuevas conexiones de clientes a la base de datos cuando el reenvío de escritura estaba habilitado.

  • Se ha corregido un problema que podía provocar que la modificación del parámetro de la base de datos de table_open_cache no tuviera efecto hasta que se reiniciara la instancia de la base de datos.

  • Se ha corregido un problema que podía provocar errores de claves duplicadas en las columnas AUTO_INCREMENT que utilizaban índices descendentes tras una operación de restauración de instantáneas, retroceso o clonación de la base de datos.

  • Se ha corregido un problema relacionado con los escaneos de índices que provocaba que se devolviera un resultado impreciso al ejecutar una consulta SELECT con la cláusula GROUP BY y el parámetro aurora_parallel_query establecidos en ON.

  • Se ha corregido un problema que podía provocar el agotamiento de la memoria disponible al ejecutar consultas en la tabla INFORMATION_SCHEMA INNODB_TABLESPACES.

  • Se ha corregido un problema que provocaba que la instancia del lector no pudiera abrir una tabla, con ERROR 1146. Este problema se produce al ejecutar determinados tipos de lenguaje de definición de datos en línea (DDL) mientras el INPLACE algoritmo se utiliza en la instancia de grabación.

  • Se ha corregido un problema para evitar que una instancia se reiniciara durante el escalado de Aurora Serverless v2 cuando el proceso de supervisión interno enviaba por error solicitudes de escalado duplicadas.

  • Se ha corregido un problema que podía provocar el reinicio de la base de datos cuando los consumidores de registros binarios (binlog) conectados utilizaban un servidor de replicación de binlog duplicado. IDs

  • Se introdujo una caché de registro de retransmisión en memoria para las réplicas de registros binarios SQL gestionadas por Aurora My. Esta mejora puede ayudar a lograr un aumento de hasta un 40 % en el rendimiento de la replicación de registros binarios. Esta mejora se habilita automáticamente cuando se utiliza la replicación de registros binarios de un solo subproceso o cuando se utiliza la replicación de subprocesos múltiples con el posicionamiento automático activado. GTID

Actualizaciones y migraciones:

  • La actualización de My SQL 5.7 a My SQL 8.0 con una gran cantidad de tablas en una sola base de datos provocó que el servidor consumiera memoria excesiva. Detectamos que, al comprobar si las tablas podían actualizarse, recuperábamos inicialmente todos los objetos Table del diccionario de datos, los procesábamos y recuperábamos su nombre. A continuación, realizamos el paso Comprobación de la compatibilidad de la versión incluido en la lista. En este caso, no era necesario recuperar todos los objetos de antemano, lo que contribuía considerablemente al consumo de memoria. Para corregir este problema, en estos casos, recuperamos un objeto Table de uno en uno, realizando las comprobaciones necesarias, recuperando su nombre y liberando el objeto antes de continuar con el siguiente (Error n.º 34526001).

  • Se mejoró el rendimiento de las principales actualizaciones de las versiones de Aurora My de la SQL versión 2 a la versión 3 mediante la ejecución de comprobaciones de los espacios de tabla en paralelo utilizando todo lo disponible vCPUs en la instancia de la base de datos.

Se corrigieron errores de integración de My SQL Community Edition

Esta versión incluye todas las correcciones de errores de la comunidad hasta la versión 8.0.32 (incluida), además de las que se indican a continuación. Para obtener más información, consulte Mis SQL errores corregidos por las actualizaciones del motor de base de datos Aurora My SQL 3.x.

  • Se ha corregido un problema que podía provocar una mayor CPU utilización debido a la rotación de TLS certificados en segundo plano. (Corrección de error de la comunidad n.º 34284186).