MySQL 5.6.21

Qué hay de nuevo en esta versión:

InnoDB Notas:
- La opción --skip-innodb opción es ahora obsoleto y su uso resulta en una advertencia. Se quitará en una futura versión de MySQL. Esto también se aplica a sus sinónimos (--innodb=OFF, --disable-innodb, y así sucesivamente). MySQL Enterprise Notas:
MySQL Enterprise Edition incluye un conjunto de funciones de cifrado basado en la biblioteca OpenSSL que exponer OpenSSL capacidades en el nivel de SQL. Estas funciones permiten a las aplicaciones de la Empresa para realizar las siguientes operaciones:
- Implementar añadido de protección de datos usando la clave pública de criptografía asimétrica
- Crear las claves públicas y privadas y firmas digitales
- Realizar el cifrado y descifrado asimétricos
- Uso de cifrado hash para la firma digital y verificación de los datos y la Funcionalidad de validación Añadido o Cambiado:
- Internamente, tipos de datos espaciales, tales como la Geometría se representan como valores BLOB, por lo que cuando se invoca con la opción --hex-blob opción, mysqldump muestra ahora espacial de los valores en hexadecimal. Errores Corregidos:
- InnoDB; la Partición: un Gran número de particiones de tablas InnoDB podría consumir mucho más de memoria cuando se utiliza en MySQL 5.6 o 5.7 de la memoria utilizada por las mismas tablas utilizadas en versiones anteriores de MySQL Server.
- InnoDB: ALTER TABLE ... de AGREGAR la CLAVE externa de la operación podría causar un grave error.
- InnoDB: En las versiones de depuración, una operación de INSERCIÓN que afectan tablas comprimidas, se producirá una sincronización relacionados con la afirmación.
- InnoDB: Recuperación de los valores múltiples con un solo comando get iba a devolver resultados incorrectos en lugar de un mensaje de error. La InnoDB memcached plugin no - actualmente admite la recuperación de los valores múltiples con un solo comando get.
- InnoDB: Intento de realizar las operaciones en un tiempo clave que podrían provocar que la memcached demonio de bloqueo y reinicio.
- InnoDB: Con un nivel de aislamiento de transacción inferior o igual a LEER COMPROMISO, la brecha de bloqueos no fueron tomadas cuando el escaneo de un único índice secundario a la comprobación de duplicados. Como resultado, los de comprobación de duplicados lógica falló, permitiendo que los valores de clave duplicados en el único índice secundario.
- InnoDB: En raros casos, el proceso de depuración con el fin de intentar eliminar un índice secundario constancia de que no estaba marcada para su eliminación, lo que resulta incoherente índice secundario.
- InnoDB: Durante la recuperación, un fallo de segmentación podría ocurrir cuando se marca una tabla como corruptos.
- InnoDB: Un error en lugar de ALTERAR el funcionamiento de la MESA dejaría atrás no únicos nombres de archivo temporal en el diccionario de datos de la prevención de futuros ALTER TABLE operaciones en la misma tabla debido a un nombre de archivo temporal de los conflictos. Para evitar este problema, los nombres de los archivos temporales son únicas por anexando un global estática número que se inicializa a un aleatorios distribuidos número de 32 bits utilizando ut_time() y ut_crc32(). El número es entonces incrementado atómicamente para que le asigna a cada nombre de archivo temporal. Anteriormente, los archivos temporales fueron nombrados con el formato #sql-ibtid, donde tid es el IDENTIFICADOR de tabla. Los archivos temporales se denomina a partir de ahora con el formato #sql-ibtid-inc, donde tid es la tabla de IDENTIFICACIÓN y aum es el número incrementado.
- InnoDB: srv_active_wake_master_thread() fue llamado directamente en innobase_commit y innobase_prepare, despertando el subproceso principal y el incremento de los srv_activity_count. srv_active_wake_master_thread() debe ser llamado después de cometer las transacciones de escritura, no después de las transacciones de solo lectura o reversiones. Esta revisión reemplaza algunas llamadas a srv_active_wake_master_thread() con llamadas a ib_wake_master_thread().
- InnoDB: Una en el lugar de ALTERAR el funcionamiento de la MESA en una mesa con una fractura de la restricción de clave externa podría plantear una afirmación.
- InnoDB: Insertar un registro en una tabla InnoDB con una clave que se encuentra entre el máximo clave de una página completa y el mínimo de la clave de la “siguiente” página podría resultar innecesaria la división de la página y bajo lleno de páginas. Si el punto de inserción está al final de una página, InnoDB ahora los intentos de insertar a la página siguiente antes de la división de la página.
- Replicación: Después de la corrección del Error #16861624, matando a un multi-threaded esclavo trabajador que estaba a la espera de una confirmación de bloqueo causado una aserción de depuración a fallar. Esta revisión se asegura de que tal situación no puede ocurrir.
- Replicación: Al confirmar una transacción, una bandera que ahora se utiliza para comprobar si un hilo se ha creado, en vez de comprobar el hilo en sí mismo, que utiliza más recursos, particularmente cuando se ejecuta el servidor con master_info_repository=TABLA.
- Replicación: multi-hilo esclavo ahora comprueba que un trabajador libre está disponible para el envío de la siguiente evento. En versiones anteriores, multi-hilo esclavo se bloquea con un trabajador de error si el hilo coordinador no puede encontrar un trabajador libre. El accidente fue causado cuando el coordinador no devolver un trabajador libre, por ejemplo, si el coordinador fue abortado, al mismo tiempo, utilizando DEJAR de ESCLAVO.
- Replicación: Cuando mysqlbinlog procesados varias registro binario de archivos en un único archivo de salida, dicho fichero no estaba en un útil de estado para el punto en el tiempo de recuperación, cuando se produjo el error, Cuando @@período de SESIONES.GTID_NEXT se establece en un GTID, debe establecer de forma explícita a un valor diferente después de un COMMIT o ROLLBACK. Por favor, compruebe GTID_NEXT variable página de manual para una explicación detallada. @@Período de SESIONES.GTID_NEXT es 'xyz'. Cuando mysqlbinlog procesos de un registro binario que contiene GTIDs, salidas CONJUNTO gtid_next declaraciones, pero gtid_next se establece en indefinido cuando ocurre un commit; esta a la izquierda gtid_next indefinido cuando el servidor se había terminado de procesar la salida de mysqlbinlog. Cuando el siguiente binario del archivo de registro se inició con una o más anónimo de las declaraciones o de las transacciones, la combinación de gtid_next ser de izquierda definida en el final del primer registro binario y el segundo registro binario que contiene anónimo de las transacciones para el error descrito anteriormente (Error de 1837, ER_GTID_NEXT_TYPE_UNDEFINED_GROUP).
- Para solucionar este problema, ahora, cada vez que mysqlbinlog se encuentra con esta situación, se inserta CONJUNTO gtid_next = AUTOMÁTICO si es necesario para evitar dejar el anterior registro binario con gtid_next indefinido.
- Además, como resultado de esta revisión, mysqlbinlog ya no salidas variable de sesión de información para cada registro binario; ahora, este valor se imprime sólo una vez, a menos que los cambios.
- Replicación: Cuando el subproceso de e/S se vuelven a conectar a un maestro en el uso de GTIDs y multiproceso esclavos, mientras que en el medio de una transacción, no pudo anular la transacción, dejando un parcial de transacciones en el registro de la retransmisión, y, a continuación, recuperar la misma operación de nuevo. Esto ocurrió cuando se realiza una rotación de la retransmisión de registro. Ahora al volver a conectar, el servidor comprueba antes de girar el registro en tales casos, y espera que lo primero para cualquier curso de la transacción finalice.
- Replicación: Cuando se utiliza semisincrónico de replicación, si el registro binario de posición se cambió a una posición de futuro en un esclavo, a continuación, un error de aserción se ha generado en el maestro. Esta revisión se asegura de que en tal situación, el futuro de la posición está correctamente reconocido un error en lugar generados en el esclavo.
- Replicación: Cuando un subproceso SQL que estaba a la espera de una confirmación de bloqueo fue asesinado y se reinicia causó una transacción que se va a saltar en el esclavo. Esta revisión se asegura de que las posiciones de la rosca se almacenen correctamente y transacciones que se resume en la posición correcta.
- Replicación: En un maestro que está utilizando semisincrónico de replicación, donde rpl_semi_sync_master_wait_no_slave está habilitado y rpl_semi_sync_master_timeout se establece a largo tiempo de espera, matando el subproceso de e/S podría provocar que el servidor para colgar en el cierre. Esta revisión se asegura de que si el volcado de hilo a la conclusión de que no semisincrónico esclavos conectados al maestro, el ajuste de rpl_semi_sync_master_wait_no_slave es ignorado y el cierre procede correctamente.
- Replicación: Cuando se utiliza replicación basada en la fila, la configuración de un esclavo slave_rows_search_algorithms variable HASH_SCAN provocó un ER_RECORD_NOT_FOUND error, aunque ese registro existía en la capa de almacenamiento. Esta revisión se asegura de que la clave única para cada registro está mantenida correctamente y en tal situación no se produce.
- Replicación: Cuando un grupo de eventos fue distribuido a través de múltiples relé de archivos de registro, un esclavo podía identificar incorrectamente GTID encabezado de los límites del grupo. Esto significa que cuando una transacción fue juzgado de nuevo, o si el subproceso SQL se detuvo en el medio de una transacción después de algunos gira, el Gtid_log_event estaba en silencio omitido en el esclavo, y la transacción se registra con el esclavo ID. Este problema también se ve afectado en el uso de INICIO de ESCLAVOS HASTA MASTER_LOG_POS = log_pos; con GTIDs habilitado. Si log_pos estaba en el medio de una transacción, la Gtid_log_event no detecta correctamente como el inicio de la transacción y la replicación se detuvo antes de este evento. Con esta revisión, los hilos de detectar correctamente que son parte de un grupo, y esto se utiliza para comprobar si un Gtid_log_event es parte de una transacción.
- Replicación: Los mensajes de error generados cuando un servidor duplicado UUID causa problemas durante la replicación se han mejorado. El esclavo de error ahora identifica el servidor duplicado UUID y el maestro de error identifica el zombie hilo que ha sido asesinado.
- Replicación: La CLIENT_REMEMBER_OPTIONS bandera comprimido esclavo conexiones ya no es restablecer y todas las opciones son retenidos. Esto restaura la funcionalidad de todas las opciones de compresión de esclavos conexiones.
- Replicación: Cuando se utiliza replicación basada en la fila, la ejecución de una transacción larga implica un gran número de eventos podría desencadenar una falta de Memoria (OOM) error si el esclavo de la estructura de la tabla no era compatible con el maestro de la estructura de la tabla. Tal incompatible situación podría ocurrir si la tabla en la que el esclavo había sido cambiado manualmente, o cuando se replican entre las diferentes versiones de MySQL que tienen diferentes tipos de datos. Este OOM error se produce porque el virtual tablas temporales creadas para la fila de conversión no fueron liberados hasta el final de la transacción, que fue un problema al replicar un gran número de eventos.
- A partir de esta versión, tablas virtuales están correctamente liberado durante el proceso de conversión.
- Con DTrace habilitada la compatibilidad con ciertas opciones de compilación podría causar la acumulación a fallar.
- yaSSL código de cliente no validar el cifrado tamaño o el IDENTIFICADOR de sesión de longitud, lo que podría provocar que el cliente a la salida.
- yaSSL podría fallar autorización previa si el cliente suministra inexacta longitudes de búfer.
- La competencia entre los hilos podría llevar a error de tiempo de espera intentando rotar el archivo de registro de auditoría.
- LPAD() y RPAD() puede hacer que un servidor de salida si la almohadilla argumento de cadena no estaba bien formado.
- El optimizador puede crear un cero de longitud de columna de una tabla temporal, causando un servidor de salida.
- MOD para muy pequeño decimal de la mano derecha argumentos podrían causar un servidor de salida.
- La biblioteca de cliente ahora incluye una llamada a X509_verify_cert_error_string() en el certificado SSL código de verificación, para ser más eficaz en la detección de los certificados no válidos.
- Si el lado izquierdo de un predicado era una subconsulta escalar pero devuelve ninguna fila, el servidor podría salir.
- El thread_concurrency variable del sistema es obsoleto, pero ninguna advertencia el resultado de la configuración en el servidor de inicio.
- El envío de un SIGQUIT o SIGINT señal de mysql podría resultar en una glibc doble libre o la corrupción de error.
- No válidos de acceso a la memoria que podría ocurrir cuando el uso de declaraciones preparadas en el caso de un cliente de mysql se ha perdido la conexión después de la declaración de preparación fue completa y hubo al menos una declaración de que estaba en estado inicializado pero que no se ha preparado todavía.
- COMO los partidos de error de los puntos de código de la MITAD de la ANCHURA KATAKANA en el sjis y cp932 conjuntos de caracteres.
- En EL7, instalación de MySQL de paquetes RPM podría fallar si postfix había sido previamente instalado utilizando yum. mysql_upgrade podría fallar si el mysql.de usuario tabla de contenidos de varias cuentas con el mismo nombre de usuario y el nombre de host de donde el nombre de host difieren en lettercase. Todavía no es permitido, pero ahora mysql_upgrade imprime un mensaje de error más informativos para indicar la naturaleza del problema:
- ERROR de 1644 (45000): Múltiples cuentas de existir para user_name, host_name
- que difieren sólo en el Host lettercase; eliminar todos excepto uno de ellos
- Si la consulta general o de registro de consultas lentas archivo de registro se establece en un FIFO o archivo socket, y el lector de archivos se fue, el servidor dejó de ejecución de las instrucciones. Ahora el servidor detecta este tipo de archivos, se registra un mensaje de error, y continúa con el correspondiente registro movilidad.
- Un simultánea OPTIMIZAR la MESA y en línea ALTER TABLE en la misma tabla InnoDB podría resultar en un punto muerto.
- El caché de consulta no fue invalidado por una tabla cuando una CASCADA de ELIMINAR o ACTUALIZAR en CASCADA restricción referencial fue especificado y el nombre de base de datos o el nombre de la tabla contenida caracteres especiales.