What's new in MySQL Community Edition 5.7.10 GA

Dec 4, 2015
  • Security Notes:
  • Previously, MySQL supported only the TLSv1 protocol for encrypted connections. TLS support has been extended to enable a higher level of encrypted connection security...
  • When compiled using the bundled version of yaSSL, MySQL supports the TLSv1 and TLSv1.1 protocols.
  • When compiled using OpenSSL 1.0.1 or higher, MySQL supports the TLSv1, TLSv1.1, and TLSv1.2 protocols.
  • By default, MySQL attempts to use the highest TLS protocol version available, depending on which SSL library was used to compile the server and client and which key size is used.
  • Because TLSv1.2 requires OpenSSL, support for this protocol is available in binary distributions only for MySQL Commercial Server, and not for MySQL Community Server (which is compiled using yaSSL). To enable TLSv1.2 support if you build from source, you must set the WITH_SSL CMake option to use OpenSSL when configuring MySQL.
  • The new tls_version system variable enables the TLS protocols permitted by the server to be specified at startup. On the client side, the --tls-version option permits the TLS protocols permitted by client programs to be specified per client invocation.
  • The mysql_options() C API function has a new MYSQL_OPT_TLS_VERSION option that enables TLS protocols permitted by a client program to be specified from within the client library.
  • Functionality Added or Changed:
  • InnoDB: The innodb_support_xa system variable, which enables support for two-phase commit in XA transactions, is deprecated. InnoDB support for two-phase commit in XA transactions is always enabled as of MySQL 5.7.10. Disabling innodb_support_xa is no longer permitted as it makes replication unsafe and prevents performance gains associated with binary log group commit.

New in MySQL Community Edition 5.7.9 GA (Oct 23, 2015)

  • Performance & Scalability: Improved InnoDB scalability and temporary table performance, enabling faster online and bulk load operations, and more.
  • JSON Support: With the newly added JSON support in MySQL, you can now combine the flexibility of NoSQL with the strength of a relational database.
  • Replication improvements for increased availability and performance. They include multi-source replication, multi-threaded slave enhancements, online GTIDs, and enhanced semi-sync replication.
  • Performance Schema delivering much better insights. We’ve added numerous new monitoring capabilities, reduced the footprint and overhead, and significantly improved ease of use with the new SYS Schema.
  • Security: We are fulfilling “secure by default” requirements and many new MySQL 5.7 features will help users keep their database secure.
  • Optimizer: We have rewritten large parts of the parser, optimizer, and cost model. This has improved maintainability, extendability, and performance.
  • GIS: Completely new in MySQL 5.7 and including InnoDB spatial indexes, use of Boost.Geometry, along with increased completeness and standard compliance.

New in MySQL Community Edition 5.6.26 GA (Jul 24, 2015)

  • This release adds support for Debian 8 and Ubuntu 15.04.

New in MySQL Community Edition 5.6.23 GA (Feb 2, 2015)

  • Security Notes:
  • The linked OpenSSL library for the MySQL Commercial Server has been updated from version 1.0.1j to version 1.0.1k. Issues fixed in the new version are described at http://www.openssl.org/news/vulnerabilities.html.
  • This change does not affect the Oracle-produced MySQL Community build of MySQL Server, which uses the yaSSL library instead. (Bug #20375530)
  • Functionality Added or Changed:
  • Support for the SSL 2.0 and SSL 3.0 protocols has been disabled because they provide weak encryption. (Bug #19820550)
  • yaSSL was upgraded to version 2.3.7. (Bug #19695101, Bug #20201864)
  • The valid date range of the SSL certificates in mysql-test/std_data has been extended to the year 2029. (Bug #18366947)
  • Bugs Fixed:
  • InnoDB: A tablespace export operation set the purge state to PURGE_STATE_STOP but the purge thread did not check the purge state until the current purge operation was completed. In the case of a large history list, the tablespace export operation was delayed, waiting for the current purge operation to finish. The purge state is now checked with every purge batch. (Bug #20266847, Bug #75298)
  • InnoDB: An ALTER TABLE ... ADD INDEX operation raised an assertion due to assertion code that did not allow an online index status of ONLINE_INDEX_ABORTED_DROPPED. The assertion code has been relaxed. (Bug #20198726)
  • InnoDB: An error occurred when the push_warning_printf function was invoked during server recovery. This function was previously used to print a warning message to the client. Also, current_thd was NULL when the server was restarted. (Bug #20144839)
  • InnoDB: An ALTER TABLE operation that changed the name of a foreign key column resulted in a failure when reloading the foreign key constraint. The previous column name remained in the data dictionary cache instead of being evicted. (Bug #20031243)
  • InnoDB: Error messages regarding a size limitation on BLOB or TEXT data inserted in a single transaction have been revised. (Bug #19975322)
  • InnoDB: DML operations on a table with full-text search indexes raised an invalid assertion. (Bug #19905246)
  • References: This bug is a regression of Bug #19314480.
  • InnoDB: A multiple-table delete operation caused the server to halt. (Bug #19815702)
  • InnoDB: A FLUSH TABLES operation raised an assertion. (Bug #19803418)
  • InnoDB: With change buffering enabled, a buffered sequence of operations that should not have been buffered resulted in an Unable to purge a record error. (Bug #19528825, Bug #73767)
  • InnoDB: On non-Windows platforms, os-file_pread and os_file_pwrite functions return -1 when an error occurs. This value was printed in an error message as the number of bytes read or written. Instead of printing the -1 value in the error message, a separate error message indicating a system call failure is now printed. Thanks to David Bennett for the patch. (Bug #19315210, Bug #73365)
  • InnoDB: A slow shutdown (innodb_fast_shutdown=0) after crash recovery raised an assertion. Slow shutdown did not wait for background rollback operations to finish before proceeding. (Bug #16862810)
  • InnoDB: The integer column value was handled incorrectly for the memcached incr and decr commands. (Bug #69415, Bug #20083106, Bug #74874, Bug #20044123)
  • Partitioning: A failed ALTER TABLE ... TRUNCATE PARTITION statement or a failed TRUNCATE TABLE statement against a partitioned table sometimes left inconsistent metadata in the table cache; subsequent SQL statements reusing this metadata failed, and could in some cases also lead to a failure of the server. (Bug #74292, Bug #19786861)
  • Replication: If a client thread on a slave executed FLUSH TABLES WITH READ LOCK while the master executed a DML, executing SHOW SLAVE STATUS in the same client became blocked, causing a deadlock. The fix ensures that the read lock is only held during the period that the relay log is being updated and the deadlock is avoided. (Bug #19843808)
  • Replication: When an XA transaction was active, executing an internal rollback, for example using the BINLOG statement, resulted in an assertion. The fix ensures that a rollback happens only for a slave when a transaction spans multiple binary log files. Rollback does not happen now if the Format_description comes from the BINLOG statement being executed in the MySQL client. (Bug #74597, Bug #19928622)
  • Replication: In normal usage, it is not possible for a slave to have more GTIDs than the master. But in certain situations, such as after a hardware failure or incorrectly cleared gtid_purged, the master's binary log could be truncated. This fix ensures that in such a situation, the master now detects that the slave has transactions with GTIDs which are not on the master. An error is now generated on the slave and the I/O thread is stopped with an error. The master's dump thread is also stopped. This prevents data inconsistencies during replication. (Bug #72635, Bug #18789758)
  • Replication: When using SHOW SLAVE STATUS to monitor replication performance, Seconds_Behind_Master sometimes displayed unexpected lag behind the master. This was caused by Previous_gtids_log_events being written to the slave's relay log with a timestamp behind the master, and then being used to calculate the Seconds_Behind_Master. This fix ensures that events generated on the slave that are added to the relay log and are not used when calculating Seconds_Behind_Master. (Bug #72376, Bug #18622657)
  • On Ubuntu 14.10, MySQL install operations could fail to reload AppArmor. (Bug #20092641)
  • EXPLAIN within an XA transaction could raise an assertion. (Bug #19941492)
  • Binary log files created by streaming the binary log from a remote server with mysqlbinlog were given an access mode more permissive than the original files. (Bug #19649868)
  • If the audit_log plugin encountered a disk-full error, the server would exit.
  • Now, if the file system to which the audit log is being written fills up, a “disk full” error is written to the error log. Audit logging continues until the audit log buffer is full. If free disk space has not been made available by the time the buffer fills, client sessions will hang, and stopping the server at the time of client sessions hanging will result in audit log corruption. To avoid this if client sessions are hung, ensure that free space is available on the audit logging file system before stopping the server. (Bug #19411485)
  • For failure to create a temporary table due to being out of file descriptors, the server exited rather than returning an error. (Bug #18948649)
  • For some queries that contained a derived table (subquery in the FROM clause), delay of materialization resulted in a suboptimal execution plan due to a less accurate row-count estimate. (Bug #18607971)
  • For UPDATE and DELETE statements, the server could exit after attempting to access an uninitialized data structure. (Bug #18036143)
  • Starting the server with start service or mysqld_safe could result in failure to use the correct plugin directory. (Bug #17619241)
  • FLUSH TABLES on a FEDERATED table failed if the table had been idle longer than the wait_timeout time plus the TCP keepalive time. (Bug #17599258)
  • Selecting all columns from INFORMATION_SCHEMA.TABLES did not reopen tables if they were in the table cache, but selecting a subset of those columns under the same conditions did reopen tables. (Bug #16869534)
  • If my_write() encountered a disk-full condition, it could return an incorrect error value. (Bug #16078792, Bug #19984788)
  • InnoDB boolean full-text searches incorrectly handled + combined with parentheses; for example, +word1 +(>word2

New in MySQL Community Edition 5.6.21 GA (Sep 24, 2014)

  • InnoDB Notes:
  • The --skip-innodb option is now deprecated and its use results in a warning. It will be removed in a future MySQL release. This also applies to its synonyms (--innodb=OFF, --disable-innodb, and so forth).
  • MySQL Enterprise Notes:
  • MySQL Enterprise Edition now includes a set of encryption functions based on the OpenSSL library that expose OpenSSL capabilities at the SQL level. These functions enable Enterprise applications to perform the following operations:
  • Implement added data protection using public-key asymmetric cryptography
  • Create public and private keys and digital signatures
  • Perform asymmetric encryption and decryption
  • Use cryptographic hashing for digital signing and data verification and validation
  • For more information, see MySQL Enterprise Encryption Functions.
  • Functionality Added or Changed:
  • Internally, spatial data types such as Geometry are represented as BLOB values, so when invoked with the --hex-blob option, mysqldump now displays spatial values in hex. (Bug #43544, Bug #11752369)
  • Bugs Fixed:
  • InnoDB; Partitioning: Large numbers of partitioned InnoDB tables could consume much more memory when used in MySQL 5.6 or 5.7 than the memory used by the same tables used in previous releases of the MySQL Server. (Bug #17780517, Bug #70641)
  • References: This bug was introduced by Bug #11764622, Bug #57480.
  • InnoDB: An ALTER TABLE ... ADD FOREIGN KEY operation could cause a serious error. (Bug #19471516, Bug #73650)
  • InnoDB: In debug builds, an INSERT operation affecting compressed tables would raise a sync-related assertion. (Bug #19295893)
  • InnoDB: Retrieval of multiple values with a single get command would return incorrect results instead of an error message. The InnoDB memcached plugin does not currently support retrieval of multiple values with a single get command. (Bug #19172212, Bug #72453)
  • InnoDB: Attempting to perform operations on a timed out key would cause the memcached daemon to crash and restart. (Bug #19172013, Bug #72586)
  • InnoDB: With a transaction isolation level less than or equal to READ COMMITTED, gap locks were not taken when scanning a unique secondary index to check for duplicates. As a result, duplicate check logic failed allowing duplicate key values in the unique secondary index. (Bug #19140907)
  • References: This bug is a regression of Bug #16133801.
  • InnoDB: In rare cases, the purge process would attempt to delete a secondary index record that was not marked for deletion, resulting in an inconsistent secondary index. (Bug #19138298)
  • InnoDB: During recovery, a segmentation fault would occur when marking a table as corrupt. (Bug #18942294)
  • InnoDB: A failed in-place ALTER TABLE operation would leave behind non-unique temporary file names in the data dictionary preventing future ALTER TABLE operations on the same table due to temporary file name conflicts. To avoid this problem, temporary file names are made unique by appending a static global number that is initialized to a random distributed 32-bit number using ut_time() and ut_crc32(). The number is then incremented atomically for each assigned temporary file name. Previously, temporary files were named using the format #sql-ibtid, where tid is the table ID. Temporary files are now named using the format #sql-ibtid-inc, where tid is the table ID and inc is the incremented number. (Bug #18734396, Bug #72594)
  • InnoDB: srv_active_wake_master_thread() was called directly in innobase_commit and innobase_prepare, waking up the master thread and incrementing srv_activity_count. srv_active_wake_master_thread() should only be called after committing write transactions, not after read-only transactions or rollbacks. This patch also replaces some calls to srv_active_wake_master_thread() with calls to ib_wake_master_thread(). (Bug #18477009, Bug #72137)
  • InnoDB: An in-place ALTER TABLE operation on a table with a broken foreign key constraint could raise an assertion. (Bug #16869435)
  • InnoDB: Inserting a record into an InnoDB table with a key that falls between the maximum key of a full page and the minimum key of the “next” page could result in unnecessary page splits and under-filled pages. If the insert point is at the end of a page, InnoDB now attempts to insert to the next page before splitting the page. (Bug #15923864, Bug #67718)
  • Replication: After the fix for Bug #16861624, killing a multi-threaded slave worker which was waiting for a commit lock caused a debug assertion to fail. This fix ensures that such a situation can not occur. (Bug #19311260)
  • Replication: When committing a transaction, a flag is now used to check whether a thread has been created, rather than checking the thread itself, which uses more resources, particularly when running the server with master_info_repository=TABLE. (Bug #18684222)
  • References: See also Bug #17967378.
  • Replication: A multi-threaded slave now checks that a free worker is available to dispatch the next event. In previous versions, a multi-threaded slave crashes with a worker error if the thread coordinator can not find a free worker. The crash was caused when the coordinator did not return a free worker, for example if the coordinator was aborted at the same time using STOP SLAVE. (Bug #18363515)
  • Replication: When mysqlbinlog processed multiple binary log files into a single output file, this file was not in a useful state for point-in-time recovery, when it failed with the error, When @@SESSION.GTID_NEXT is set to a GTID, you must explicitly set it to a different value after a COMMIT or ROLLBACK. Please check GTID_NEXT variable manual page for detailed explanation. Current @@SESSION.GTID_NEXT is 'xyz'. When mysqlbinlog processes a binary log containing GTIDs, it outputs SET gtid_next statements, but gtid_next is set to undefined whenever a commit occurs; this left gtid_next undefined when the server had finished processing the output from mysqlbinlog. When the next binary log file started with one or more anonymous statements or transactions, the combination of gtid_next being left undefined at the end of the first binary log and the second binary log containing anonymous transactions to the error described previously (Error 1837, ER_GTID_NEXT_TYPE_UNDEFINED_GROUP).
  • To fix this issue, now, whenever mysqlbinlog encounters this situation, it inserts SET gtid_next = AUTOMATIC if required to avoid leaving the previous binary log with gtid_next undefined.
  • In addition, as a result of this fix, mysqlbinlog no longer outputs session variable information for every binary log; now, this value is printed only once unless it changes. (Bug #18258933, Bug #71695)
  • Replication: When the I/O thread reconnected to a master using GTIDs and multithreaded slaves while in the middle of a transaction, it failed to abort the transaction, leaving a partial transaction in the relay log, and then retrieving the same transaction again. This occurred when performing a rotation of the relay log. Now when reconnecting, the server checks before rotating the log in such cases, and waits first for any ongoing transaction to complete. (Bug #17326020)
  • Replication: When using semisynchronous replication, if the binary log position was changed to a future position on a slave then an assertion error was generated on the master. This fix ensures that in such a situation the future position is correctly acknowledged and an error is instead generated on the slave. (Bug #70327, Bug #17453826)
  • Replication: When an SQL thread which was waiting for a commit lock was killed and restarted it caused a transaction to be skipped on slave. This fix ensures that thread positions are correctly persisted and transactions resume at the correct position. (Bug #69873, Bug #17450876)
  • Replication: On a master that is using semisynchronous replication, where rpl_semi_sync_master_wait_no_slave is enabled and rpl_semi_sync_master_timeout is set to long timeout, killing the I/O thread could cause the server to hang on shutdown. This fix ensures that if the dump thread finds that there no semisynchronous slaves connected to the master, the setting of rpl_semi_sync_master_wait_no_slave is ignored and the shutdown proceeds correctly. (Bug #71047, Bug #17879675)
  • Replication: When using row-based replication, setting a slave's slave_rows_search_algorithms variable to HASH_SCAN caused an ER_RECORD_NOT_FOUND error even though that record existed in the storage layer. This fix ensures that the unique key for each record is correctly maintained and such a situation does not occur. (Bug #72788, Bug #18860225)
  • Replication: When an event group was spanned across multiple relay log files, a slave could incorrectly identify GTID-header group boundaries. This meant that when a transaction was retried, or if the SQL thread was stopped in the middle of a transaction after some rotates, the Gtid_log_event was being silently skipped on the slave, and the transaction was logged with the slave's GTID. This problem also impacted on using START SLAVE UNTIL MASTER_LOG_POS = log_pos; with GTIDs enabled. If log_pos was in the middle of a transaction, the Gtid_log_event was not correctly detected as the beginning of the transaction and replication stopped before this event. With this fix, threads correctly detect that they are part of a group, and this is used to check if a Gtid_log_event is part of a transaction. (Bug #72313, Bug #18652178, Bug #18306199)
  • Replication: The error messages generated when a duplicate server UUID causes issues during replication have been improved. The slave error now identifies the duplicate server UUID and the master error identifies the zombie thread that has been killed. (Bug #72578, Bug #18731211)
  • Replication: The CLIENT_REMEMBER_OPTIONS flag for compressed slave connections is no longer reset and all options are retained. This restores functionality of all options to compressed slave connections. (Bug #72901, Bug #18923691, Bug #73324, Bug #19244772)
  • Replication: When using row-based replication, running a long transaction involving a large number of events could trigger an Out of Memory (OOM) error if the slave's table structure was not compatible with the master's table structure. Such an incompatible situation could occur if the table on the slave had been manually changed, or when replicating between different MySQL versions that have different data types. This OOM error was caused because the virtual temporary tables created for the row conversion were not being freed until the end of the transaction, which was a problem when replicating large numbers of events.
  • Starting with this version, such virtual tables are correctly freed during the conversion process. (Bug #72610, Bug #18770469)
  • With DTrace support enabled, certain other compilation options could cause the build to fail. (Bug #19506247)
  • yaSSL client code did not validate the encryption size or session ID length, which could cause the client to exit. (Bug #19463277, Bug #19463565)
  • yaSSL could fail preauthorization if the client supplied inaccurate buffer lengths. (Bug #19370676, Bug #19355577)
  • Competition between threads could lead to timeout failure trying to rotate the audit log file. (Bug #19184973)
  • LPAD() and RPAD() could cause a server exit if the pad string argument was not well formed. (Bug #18935421)
  • The optimizer could create a zero-length column for a temporary table, causing a server exit. (Bug #18928848)
  • MOD for very small decimal right-hand arguments could cause a server exit. (Bug #18469276)
  • The client library now includes a call to X509_verify_cert_error_string() in the SSL certificate verification code, to be more robust in detecting invalid certificates. (Bug #18384260)
  • If the left-hand-side of an IN predicate was a scalar subquery but returned no row, the server could exit. (Bug #18223655, Bug #18447874)
  • The thread_concurrency system variable is deprecated, but no warning resulted from setting it at server startup. (Bug #17873011)
  • Sending a SIGQUIT or SIGINT signal to mysql could result in a glibc double free or corruption error. (Bug #17297324)
  • Invalid memory access could occur when using prepared statements if a mysql client connection was lost after statement preparation was complete and there was at least one statement that was in initialized state but not prepared yet. (Bug #70429, Bug #17512527)
  • LIKE matches failed for code points of HALF WIDTH KATAKANA in the sjis and cp932 character sets. (Bug #47641, Bug #11755818)
  • On EL7, installation of MySQL from RPM packages could fail if postfix had previously been installed using yum. (Bug #73507, Bug #19392051, Bug #19392149)
  • mysql_upgrade could fail if the mysql.user table contained multiple accounts with the same user name and host name where the host name differed in lettercase. This is still not permitted, but now mysql_upgrade prints a more informative error message to indicate the nature of the problem:
  • ERROR 1644 (45000): Multiple accounts exist for user_name, host_name
  • that differ only in Host lettercase; remove all except one of them
  • (Bug #72066, Bug #18415196)
  • If the general query log or slow query log file was set to a FIFO or socket file, and the file reader went away, the server stopped executing statements. Now the server detects such files, logs an error message, and continues with the appropriate log disabled. (Bug #67088, Bug #14757009)
  • A simultaneous OPTIMIZE TABLE and online ALTER TABLE on the same InnoDB table could result in deadlock. (Bug #71433, Bug #18110156)
  • The query cache was not invalidated for a table when a CASCADE DELETE or CASCADE UPDATE referential constraint was specified and the database name or table name contained special characters. (Bug #72547, Bug #18710853)