MySQL 5.6 Released

Home » News » MySQL 5.6 Released

MySQL 5.6 Released

Thursday, February 7, 2013 0 comments

MySQL 5.6.10 Released

Beginning with MySQL 5.6.10, MySQL Enterprise Edition is available for MySQL 5.6. Specifically, MySQL Enterprise 5.6.10 includes these components previously available only in MySQL 5.5: MySQL Enterprise Security (PAM and Windows authentication plugins), MySQL Enterprise Audit, and MySQL Thread Pool. For information about these features, see MySQL Enterprise Edition. To learn more about commercial products, see http://www.mysql.com/products/.
Known limitations of this release:
On Microsoft Windows, when using the MySQL Installer to install MySQL Server 5.6.10 on a host with an existing MySQL Server of a different version (such as 5.5.30), that also has a different license (community versus commercial), you must first update the license type of the existing MySQL Server. Otherwise, MySQL Installer will remove MySQL Server(s) with different licenses from the one you chose with MySQL Server 5.6.10.
On Microsoft Windows 8, updating a community release to a commercial release requires you to manually restart the MySQL service after the update.
Functionality Added or Changed

Replication: An Auto_Position column has been added to the output generated by SHOW SLAVE STATUS. The value of this column shows whether replication autopositioning is in use. If autopositioning is enabled—that is, if MASTER_AUTO_POSITION = 1 was set by the last successful CHANGE MASTER TO statement that was executed on the slave—then the column's value is 1; if not, then the value is 0. (Bug #15992220)
In RPM packages built for Unbreakable Linux Network, libmysqld.so now has a version number. (Bug #15972480)
Error messages for ALTER TABLE statement using a LOCK or ALGORITHM value not supported for the given operation were very generic. The server now produces more informative messages. (Bug #15902911)
If a client with an expired password connected but old_passwords was not the value required to select the password hashing format appropriate for the client account, there was no way for the client to determine the proper value. Now the server automatically sets the session old_passwords value appropriately for the account password. (Bug #15892194)
The validate_password_policy_number system variable was renamed to validate_password_policy. (Bug #14588121)
In JSON-format EXPLAIN output, the attached_condition information for subqueries now includes select# to indicate the relative order of subquery execution. (Bug #13897507)
The following changes were made to the sandbox mode that the server uses to handle client connections for accounts with expired passwords:
- There is a new disconnect_on_expired_passwords system variable (default: enabled). This controls how the server treats expired-password accounts.
- Two flags were added to the C API client library: MYSQL_OPT_CAN_HANDLE_EXPIRED_PASSWORDS for mysql_options() and CLIENT_CAN_HANDLE_EXPIRED_PASSWORDS for mysql_real_connect(). Each flag enables a client program to indicate whether it can handle sandbox mode for accounts with expired passwords.
  MYSQL_OPT_CAN_HANDLE_EXPIRED_PASSWORDS is enabled for mysqltest unconditionally, for mysql in interactive mode, and for mysqladmin if the first command is password.
For more information about how the client-side flags interact with disconnect_on_expired_passwords, see Password Expiration and Sandbox Mode. (Bug #67568, Bug #15874023)

Bugs Fixed

InnoDB; Performance: Some data structures related to undo logging could be initialized unnecessarily during a query, although they were only needed under specific conditions. (Bug #14676084)
InnoDB; Performance: Optimized read operations for compressed tables by skipping redundant tests. The check for whether any related changes needed to be merged from the insert buffer was being called more often than necessary. (Bug #14329288, Bug #65886)
InnoDB; Performance: Immediately after a table was created, queries against it would not use loose index scans. The issue went away following an ALTER TABLE on the table. The fix improves the accuracy of the index statistics gathered when the table is first created, and prevents the query plan from being changed by the ALTER TABLE statement. (Bug #14200010)
Replication; Important Change: The lettercasing used for displaying UUIDs in global transaction identifiers was inconsistent. Now, all GTID values use lowercase, including those shown in the Retrieved_Gtid_Set and Executed_Gtid_Set columns from the output of SHOW SLAVE STATUS. (Bug #15869441)
InnoDB: Under certain circumstances, an InnoDB table was reported as corrupted after import using ALTER TABLE ... IMPORT TABLESPACE. The problem was accompanied by one of these messages:
```
Warning  : InnoDB: The B-tree of index "PRIMARY" is corrupted. 
error    : Corrupt
```
or:
```
Warning  : InnoDB: The B-tree of index "GEN_CLUST_INDEX" is corrupted. 
error    : Corrupt
```
This issue occurred intermittently, and primarily affected large tables. The REPAIR TABLE statement would fix the problem reported by the error message. (Bug #15960850, Bug #67807)
InnoDB: Some Valgrind warnings were issued during shutdown, while cleaning up a background thread that handles optimization of tables containing FULLTEXT indexes. (Bug #15994393)
InnoDB: If an online DDL operation to add a unique index failed, because duplicate items were created by concurrent DML during the online DDL operation, the ALTER TABLE operation failed with the wrong error type. It returned ER_INDEX_CORRUPT; now it returns the new error code ER_DUP_UNKNOWN_IN_INDEX. (It does not return ER_DUP_KEY, because the duplicate key value is not available to be reported when this condition occurs.) (Bug #15920713)
InnoDB: ALTER TABLE statements using the online DDL feature could cause Valgrind warnings. (Bug #15933178)
InnoDB: Names of indexes being created by an online DDL operation were being displayed incorrectly in information_schema tables while the operation was in progress. This fix ensures the table names have the leading 0xff byte stripped off for information_schema queries. This change affects the columns:
- innodb_buffer_page.index_name
- innodb_buffer_page_lru.index_name
- innodb_cmp_per_index.index_name
- innodb_cmp_per_index_reset.index_name
- innodb_locks.lock_index
- innodb_sys_indexes.name
(Bug #15946256)
InnoDB: The status variable Innodb_buffer_pool_read_ahead_evicted could show an inaccurate value, higher than expected, because some pages in the buffer pool were incorrectly considered as being brought in by read-ahead requests. (Bug #15859402, Bug #67476)
InnoDB: Creating an index on a CHAR column could fail for a table with a character set with varying length, such as UTF-8, if the table was created with the ROW_FORMAT=REDUNDANT clause. (Bug #15874001)
InnoDB: If the server crashed near the end of an online DDL ALTER TABLE statement, a subsequent CHECK TABLE statement using the EXTENDED clause could cause a serious error. (Bug #15878013)
InnoDB: Specifying an innodb_log_file_size value of 4GB or larger was not possible on 64-bit Windows systems. This issue only affected debug builds. (Bug #15882860)
InnoDB: This fix ensures that in case of a serious unhandled error during an ALTER TABLE operation that copies the original table, any data that could be needed for data recovery is preserved, in tables using names of the form #sql-ib-table_id or #mysql50##sql-ib-table_id. (Bug #15866623)
InnoDB: An online DDL operation to add a primary key to a table could encounter a serious error if the table also had an index on a column prefix of a BLOB column.
This fix suspends the background purge operation while a table is being rebuilt by an ALTER TABLE statement, if any rows containing off-page columns would be removed. Currently, to avoid excessive space usage during the online DDL operation, avoid these types of concurrent DML operations until the ALTER TABLE is finished:
- DELETE of rows that contain off-page columns.
- UPDATE of primary key columns in rows that contain off-page columns.
- UPDATE of off-page columns.
(Bug #14827736)
InnoDB: The server could halt with an assertion error while creating an index:
```
InnoDB: Assertion failure in thread thread_num in file row0merge.cc line 465 
```
This issue affected tables with a combination of ROW_FORMAT=REDUNDANT off-page columns, and an index on a column prefix. (Bug #14753402)
InnoDB: information_schema tables with InnoDB metadata, such as innodb_sys_tablestats, displayed non-alphanumeric characters in the names of tables using an encoded format, for example with @0024 instead of $. (Bug #14550145)
InnoDB: If the value of innodb_force_recovery was less than 6, opening a corrupted table might loop forever if a corrupted page was read when calculating statistics for the table. Information about the corrupted page was written repeatedly to the error log, possibly causing a disk space issue. The fix causes the server to halt after a fixed number of failed attempts to read the page. To troubleshoot such a corruption issue, set innodb_force_recovery=6 and restart. (Bug #14147491, Bug #65469)
InnoDB: With a large value for innodb_buffer_pool_size, and innodb_buffer_pool_instances set greater than 1, pages were being incorrectly evicted from the buffer pool. (Bug #14125092)
Partitioning: Partition pruning is now enabled for tables using a storage engine that provides automatic partitioning, such as the NDB storage engine, but which are explicitly partitioned. Previously, pruning was disabled for all tables using such a storage engine, whether or not the tables had explicitly defined partitions.
In addition, as part of this fix, explicit partition selection is now disabled for tables using a storage engine (such as NDB) that provides automatic partitioning. (Bug #14827952)
References: See also Bug #14672885.
Replication: When using GTID-based replication, and whenever a transaction was executed on the master but was not sent to the slave because the slave already had a transaction with that ID, semisynchrononous replication timed out. One case in which this could happen was during a failover operation where the new master started behind the new slave. (Bug #15985893)
Replication: An unnecessary flush to disk performed after every transaction when using FILE as the replication info repository type could degrade performance. Now this is done only when both data and relay log info is stored in (transactional) tables. (Bug #15980626)
Replication: Issuing START SLAVE UNTIL SQL_BEFORE_GTIDS = gtid_set, where gtid_set covered a large number (tens or hundreds of millions) of transactions, could cause the server to hang. (Bug #15968413)
Replication: When a slave was started using --skip-innodb and replication info file repositories (FILE being the default for both --relay-log-info-repository and --master-info-repository), replication was incorrectly stopped. However, if the slave is using file repositories and not currently migrating between info repositories, replication should be able to work without issues. Now the server ignores errors raised when trying to open table info repositories in such conditions.
In addition, binary log initialization was not performed correctly when starting the slave with --skip-innodb, which caused the --log-bin option to be ignored. (Bug #15956714, Bug #67798, Bug #15971607)
Replication: When temporary and persistent tables, or temporary tables using different storage engines, are dropped in a single statement, this statement is actually written as two statements to the binary log, each represented by its own log event. When gtid_mode is ON, each DDL event must have a GTID; however, in such cases, the statement dropping the temporary table was uncommitted, which meant that it was not given its own GTID.
Now, when a DDL statement dropping a temporary table and a table that is persistent, or that uses a different storage engine, is separated in the manner just described, and the resulting logged statement affecting only the temporary table does not implicitly commit, a commit is forced so that the corresponding log event has own unique GTID. (Bug #15947962)
Replication: When used on a binary log that had been written by a GTID-enabled server, mysqlbinlog did not correctly handle transactions left unclosed by the omission of statements that were ignored when the --database option was employed.
Now, whenever mysqlbinlog --database reads a GTID log event, it checks to see whether there is an unclosed transaction, and if so, issues a commit. (Bug #15912728)
Replication: Semisynchronous replication did not work correctly with GTIDs enabled. (Bug #15927032)
References: See also Bug #14737388.
Replication: When GTIDs were enabled, the automatic dropping of a temporary table when a client disconnected did not always generate a GTID. Now each logged DROP TABLE statement, including any generated by the server, is guaranteed to have its own GTID. (Bug #15907504)
Replication: After dropping a column from the slave's version of a table, then altering the same column of this table on the master (so that a type conversion would have been required had the column not been droppped on the slave), inserts into this table caused replication to fail. (Bug #15888454)
Replication: SET GLOBAL sql_slave_skip_counter = 1 did not skip errors or update the slave's position in the binary log position when using --gtid-mode = ON. (Bug #15833516)
Replication: When a binary log is replayed on a server (for example, by executing a command like mysqlbinlog binlog.000001 | mysql), it sets a pseudo-slave mode on the client connection used, so that the server can read binlog and apply binary log events correctly. However, the pseudo-slave mode was not disabled after the binary log dump was read, which caused unexpected filtering rules to be applied to SQL statements subsequently executed on the same connection. (Bug #15891524)
Replication: During mysqld shutdown, global GTID variables were released before it was made certain that all plugins had stopped using them. (Bug #14798275)
Replication: MASTER_POS_WAIT() could hang or return -1 due to invalid updates by the slave SQL thread when transactions were skipped by the GTID protocol. (Bug #14737388)
References: See also Bug #15927032.
Replication: Trying to execute a Stop event on a multithreaded slave could cause unwanted updates to the relay log, leading the slave to lose synchronization with the master. (Bug #14737388)
Replication: Names of databases in binary log query log events were not properly checked for length. (Bug #14636219)
Replication: Issuing START SLAVE concurrently with setting sql_slave_skip_counter or slave_net_timeout could cause a deadlock. (Bug #14236151)
Replication: When using statement-based replication, and where the master and the slave used table schemas having different AUTO_INCREMENT columns, inserts generating AUTO_INCREMENT values logged for a given table on the master could be applied to the wrong table on the slave. (Bug #12669186)
Replication: Repeated execution of CHANGE MASTER TO statements using invalid MASTER_LOG_POS values could lead to errors and possibly a crash on the slave. Now in such cases, the statement fails with a clear error message. (Bug #11764602, Bug #57454)
Microsoft Windows: Dynamic file names (with colons) are no longer allowed. Static file names using the Alternate Data Stream (ADS) NTFS functionality of Microsoft Windows may continue to be used. (Bug #11761752)
During client connection processing, the server now performs password-expiration checking after SSL checks. (Bug #16103348)
A buffer-handling problem in yaSSL was fixed. (Bug #15965288)
The plugin logging routine mishandled its argument, resulting in undefined behavior. (Bug #16002890)
An ALTER TABLE with the ADD PRIMARY KEY or ADD UNIQUE INDEX clause could encounter a serious error if the columns for the primary key or unique index contained duplicate entries. This error occurred intermittently, depending on how the rows were physically distributed across index blocks. (Bug #15908291)
The ALTER TABLE statement can now use the LOCK=NONE clause, allowing online DDL with concurrent DML, for child tables containing foreign key constraints. (Bug #15912214)
In certain rare cases, a query using UpdateXML() could cause the server to crash. (Bug #15948580)
References: See also Bug #13007062.
AES_DECRYPT() and AES_ENCRYPT() had memory leaks when MySQL was compiled using OpenSSL. (Bug #15909183)
Several OpenSSL-related Valgrind warnings were corrected. (Bug #15908967)
Several OpenSSL-related memory leaks were fixed. (Bug #15921729)
Very long database names in queries could cause the server to exit. (Bug #15912213)
Within a stored procedure, executing a multiple-table DELETE statement that used a very long table alias could cause the server to exit. (Bug #15954896)
Very long table aliases in queries could cause the server to exit. (Bug #15948123)
Metadata locking and table definition cache routines did not always check length of names passed to them. (Bug #15954872)
A comment added to mysqldump output for the --set-gid-purged option was malformed and caused a syntax error when the dump file was reloaded. (Bug #15922502)
References: See also Bug #14832472.
Contention in the thread pool during kill processing could lead to a Valgrind panic. (Bug #15921866)
In the absence of a FULLTEXT index on an InnoDB table, a full-text query with COUNT(*) could raise an assertion. (Bug #15950531)
If an error occurred during the final phase of an online DDL operation, some cached metadata about the table might not be restored to its original state. This issue typically affected operations that renamed a column, and also dropped and re-created an index on that column, in the same ALTER TABLE statement. This issue did not affect operations that reorganize the clustered index of the table, such as adding a new primary key. (Bug #15866734)
In debug builds, the server could not start on 64-bit Windows systems when a value of 16 GB or higher was specified for innodb_buffer_pool_size. Non-debug builds would likely have subtler issues, such as memory being allocated for the buffer pool but not used, or read requests overlooking pages already cached in the buffer pool.
On 32-bit Windows systems, the value of innodb_buffer_pool_instances is increased if necessary so that no buffer pool instance is larger then 1.3 GB, due to system limitations on memory allocation. This automatic adjustment needed for 32-bit Windows systems was incorrectly applied to 64-bit systems also; for systems with 16 GB or larger buffer pools, the adjusted value of innodb_buffer_pool_instances would exceed the upper limit of 64, causing an assertion error in debug builds. (Bug #15883071)
A heavy workload of online DDL and concurrent DML on a table on a master server could cause errors as the changes were replicated to slave servers. For example, processing a DROP COLUMN operation at the same time as queries referring to the dropped column could cause errors on slave servers if the statements finished in a different order than on the master. (Bug #15878880)
If the server shut down unexpectedly, the presence of an InnoDB table with 1018 columns (very close to the upper limit of 1020 columns) could cause an assertion error during server restart:
```
InnoDB: Failing assertion: table->n_def == table->n_cols - 3
```
(Bug #15834685)
The Performance Schema normally ignores temporary table events. User-defined temporary tables are truncated by being re-created, but the Performance Schema did not recognize re-created temporary tables as being temporary and raised an assertion. (Bug #15884836)
The Performance Schema session_connect_attrs table displayed extraneous information. (Bug #15864703)
Subqueries with COUNT(DISTINCT ...)) could cause the server to exit. (Bug #15832620)
References: See also Bug #11750963.
Rows_log_event allocated one too few bytes for the row buffer. (Bug #15890178)
For the LooseScan semi-join strategy, the optimizer could rely on an uninitialized variable. (Bug #15849654)
For debug builds, an assertion could be raised when: 1) A view was based on a MEMORY table; 2) The table was altered to drop some column in use by the view; 3) A SELECT was done on the view with binary logging disabled. (Bug #15847447)
If loose index scan was used on a query with descending order, the result set contained NULL values instead of the correct values. (Bug #15848665)
The optimizer's cost-based choice between IN -> EXISTS subquery transformation and subquery materialization was sometimes incorrect if the IN predicate was OR-ed with some other predicate. (Bug #15866339)
References: See also Bug #13111584.
In some cases, a cost value was printed to Optimizer Trace output without being initialized, resulting in incorrect output. (Bug #15877453)
Several code issues identified by Fortify were corrected. (Bug #15884324)
Some queries, if used as prepared statements, caused the server to exit if an error occurred. (Bug #15877062)
Complex IN subqueries could cause the server to exit. (Bug #15877738)
It was possible to expire the password for an account even if the account is authenticated by an authentication plugin that does not support password expiration. (Bug #15849009)
When the server reads the mysql.user table, it now checks for invalid native and old-native password hashes and ignores accounts with invalid hashes. (Bug #14845445)
The validate_password plugin did not check certain passwords. (Bug #14843970)
GRANT ... IDENTIFIED BY could fail to flush the privileges. (Bug #14849959)
Setting the validate_password_length system variable did not take into account that the minimum value is a function of several other related system variables. Now the server will not set the value less than the value of this expression:
```
validate_password_number_count
+ validate_password_special_char_count
+ (2 * validate_password_mixed_case_count)
```
(Bug #14850601)
When used with an XPath expression that contained the output of a stored function, ExtractValue() failed with the error Only constant XPATH queries are supported. (Bug #14798445, Bug #67313)
MySQL could encounter an error during shutdown on Windows XP or earlier systems. This issue did not affect systems running Windows Vista or higher, which use atomic condition variables to represent Windows Events. (Bug #14822849)
Temporary table creation during execution of INFORMATION_SCHEMA queries could result in Valgrind warnings. (Bug #14801497)
mysqladmin did not properly process commands for users with expired passwords. (Bug #14833621)
XA START had a race condition that could cause a server crash. (Bug #14729757)
The server could halt with an assertion error due to a recently added error code:
```
InnoDB: unknown error code 1502 
InnoDB: Assertion failure in thread thread_num in file row0mysql.cc line 683 
mysqld got signal 6 ; 
```
Now, the server returns the error code DB_DICT_CHANGED to the client in this case. (Bug #14764015)
Queries that used grouping failed when executed using a cursor if the optimizer processed the grouping using a temporary table. (Bug #14740889)
The server could exit when the MyISAM storage engine (rather than MEMORY) was used to materialize a derived table. (Bug #14728469)
The sha256_password authentication plugin requires that the client connect either using SSL or have RSA enabled. When neither condition was met, an uninformative error message was produced. Now the error message is more informative. (Bug #14751925)
The server now logs warnings at startup if the file specified for the validate_password_dictionary_file system variable violates constraints on valid password file contents. (Bug #14588148)
At startup, some InnoDB boolean system variables could be set to 1 or 0, but not ON or OFF. These included innodb_file_per_table, innodb_force_load_corrupted, and innodb_large_prefix. (Bug #14494893)
Output generated with mysqldump --routines could produce syntax errors when reloaded. (Bug #14463669)
Calculations involving self-intersecting polygons caused an assertion to be raised. (Bug #14503584)
If ALTER TABLE was killed, the server could report ER_QUERY_INTERRUPTED even if the alterations had been made successfully. This is misleading to the user. Also, the statement would not be written to the binary log, leading to incorrect replication (Bug #14382643)
The parser failed to return an error for some invalid UNION constructs. (Bug #13992148)
Preloading of client plugins specified with the LIBMYSQL_PLUGINS environment variable could fail unless the plugins were located in the hardwired default plugin directory. The C API now checks during plugin preloading for a LIBMYSQL_PLUGIN_DIR environment variable which can be set to the path name of the directory in which to look for client plugins.
In addition, for explicit client plugin loading, the mysql_load_plugin() and mysql_load_plugin_v() C API functions have been modified to use the LIBMYSQL_PLUGIN_DIR value if it exists and the --plugin-dir option was not given. If --plugin-dir is given, mysql_load_plugin() and mysql_load_plugin_v() ignore LIBMYSQL_PLUGIN_DIR. (Bug #13994567)
With the ONLY_FULL_GROUP_BY SQL mode enabled, executing a stored function twice that contains a SQL query that is not valid with that mode enabled caused the server to exit. (Bug #13996639)
Autosizing of Performance Schema parameters could result in settings that caused excessive CPU use. (Bug #67736, Bug #15927744)
The optimizer sometimes chose a nonoptimimal range scan strategy when a query included a LIMIT clause. (Bug #67432, Bug #15829358)
Full-text searches in InnoDB tables could return incorrect results. (Bug #67257, Bug #14771282)
The mysql client could mishandle the delimiter command if it occurred on a line during which mysql was looking for the end of a quoted string. (Bug #64135, Bug #13639125)
The Performance Schema normally ignores temporary table events, but sometimes failed to properly identify a table as temporary and consequently recorded events for the table. (Bug #67098, Bug #14756887)
Some messages written by the server to the error log referred to the deprecated --log-slow-queries option rather than the --slow-query-log option. Similarly, the server referred to the deprecated --log option rather than the --general-log-file and --log-output options. (Bug #67892, Bug #15996571)
Attempting to perform an in-place upgrade from MySQL 5.1 to 5.6 causes the server to exit due to a mismatch between the privilege structures in the two series. (This is not a supported operation, but the server should not exit ungracefully.) (Bug #67319, Bug #14826854)
DECIMAL multiplication operations could produce significant inaccuracy. (Bug #45860, Bug #11754279)
Due to a thread race condition, the server could exit while attempting to read the Performance Schema threads.PROCESSLIST_INFO column. (Bug #68127, Bug #16196158)
The optimizer could choose an IN-to-EXISTS transformation for subquery execution in some cases when subquery materialization would be cheaper. (Bug #67511, Bug #15848521)
It is not permitted to use CREATE TABLE to create an NDB table with user-defined partitioning and a foreign key. However, it was possible to create an NDB table with a foreign key, then add partitioning to it using ALTER TABLE, thus creating a table which was impossible to backup/restore using mysqldump. Now the prohibition is enforced consistently. (Bug #67492, Bug #15844519)
For single-table DELETE or UPDATE statements, EXPLAIN displayed a type value of ALL (full-table scan access method) even if the optimizer chose to scan the table by an index access method. Now the type value is displayed as index. (Bug #67637, Bug #15892875)

source

Web2 Developers

MySQL 5.6 Released

MySQL 5.6.10 Released

Related Post:

0 commentaires:

Post a Comment

Category

Arsip Blog