MySQL Community Server 5.6.19 has been released
Posted by: Laasya Moduludu
Date: June 02, 2014 03:19AM
Date: June 02, 2014 03:19AM
Dear MySQL users, MySQL Server 5.6.19, a new version of the popular Open Source Database Management System, has been released. MySQL 5.6.19 is recommended for use on production systems. There is no MySQL Community Server 5.6.18. This version number was used for an out-of-schedule release of the Enterprise Edition to address the OpenSSL "Heartbleed" issue. This issue did not affect the Community Edition since it uses yaSSL, not OpenSSL. So a new release of the Community Server was not needed, and 5.6.17 is followed by 5.6.19. For an overview of what's new in MySQL 5.6, please see http://dev.mysql.com/doc/refman/5.6/en/mysql-nutshell.html Starting with 5.6.11, Microsoft Windows packages for MySQL 5.6 are available both as a "full" installer and as a "web" installer. The full installer is significantly larger and comes bundled with the latest software releases available. This bundle makes it easy to download and configure a full server and development suite. The web installer doesn't come bundled with any actual products and instead relies on download-on-demand to fetch only the products you choose to install. This makes the initial download much smaller but increases install time as the individual products will need to be downloaded. For information on installing MySQL 5.6.19 on new servers or upgrading to MySQL 5.6.19 from previous MySQL releases, please see http://dev.mysql.com/doc/refman/5.6/en/installing.html MySQL Server is available in source and binary form for a number of platforms from our download pages at http://dev.mysql.com/downloads/ Not all mirror sites may be up to date at this point in time, so if you can't find this version on some mirror, please try again later or choose another download site. We welcome and appreciate your feedback, bug reports, bug fixes, patches, etc: https://wikis.oracle.com/display/mysql/Contributing The following section lists the changes in the MySQL source code since the previous released version of MySQL 5.6. It may also be viewed online at http://dev.mysql.com/doc/relnotes/mysql/5.6/en/news-5-6-19.html Enjoy! Changes in MySQL 5.6.19 (2014-05-30) Functionality Added or Changed * The obsolete and unmaintained charset2html utility has been removed from MySQL distributions. (Bug #71897, Bug #18352347) * The mysqlbug, mysql_waitpid, and mysql_zap utilities have been deprecated and will be removed in MySQL 5.7. Bugs Fixed * InnoDB: After upgrading from 5.6.10 to MySQL versions up to and including MySQL 5.6.18, InnoDB would attempt to rename obsolete full-text search auxiliary tables on server startup, resulting in an assertion failure. (Bug #18634201, Bug #72079) * InnoDB: For each insert, memset would be called three times to allocate memory for system fields. To reduce CPU usage, the three memset calls are now combined into a single call. (Bug #17858679, Bug #71014) * InnoDB: Enabling the InnoDB Table Monitor would result in a ib_table->stat_initialized assertion failure. (Bug #17039528, Bug #69641) * InnoDB: Setting innodb_max_dirty_pages_pct=0 would leave 1% of dirty pages unflushed. Buffer pool flushing is initiated when the percentage of dirty pages is greater innodb_max_dirty_pages_pct. The internal variables that store the innodb_max_dirty_pages_pct value and the percentage of dirty pages (buf_get_modified_ratio_pct and srv_max_buf_pool_modified_pct) were defined as unsigned integer data types, which meant that a innodb_max_dirty_pages_pct value of 0 required a dirty pages percentage of 1 or greater to initiate buffer pool flushing. To address this problem, the buf_get_modified_ratio_pct and srv_max_buf_pool_modified_pct internal variables are redefined as double data types, which changes the range value for innodb_max_dirty_pages_pct and innodb_max_dirty_pages_pct_lwm from 0 .. 99 to 0 .. 99.99. Additionally, buffer pool flushing is now initiated when the percentage of dirty pages is "greater than or equal to" innodb_max_dirty_pages_pct. (Bug #13029450, Bug #62534) * Replication: Log rotation events could cause group_relay_log_pos to be moved forward incorrectly within a group. This meant that, when the transaction was retried, or if the SQL thread was stopped in the middle of a transaction following one or more log rotations (such that the transaction or group spanned multiple relay log files), part or all of the group was silently skipped. This issue has been addressed by correcting a problem in the logic used to avoid touching the coordinates of the SQL thread when updating the log position as part of a relay log rotation whereby it was possible to update the SQL thread's coordinates when not using a multi-threaded slave, even in the middle of a group. (Bug #18482854) * Replication: When running the server with --gtid-mode=ON, STOP SLAVE followed by START SLAVE resulted in a mismatch between the information provided by INFORMATION_SCHEMA.INNODB_TEMP_TABLE_INFO and the Slave_open_temp_tables status variable: the INNODB_TEMP_TABLE_INFO table showed that no temporary tables existed, but Slave_open_temp_tables had a nonzero value. (Bug #18364070) References: See also Bug #18236612. * Replication: In certain cases, the server mishandled triggers and stored procedures that tried to modify other tables when called by CREATE TABLE ... SELECT. This is now handled correctly as an error. (Bug #18137535) * Replication: When used on a table employing a transactional storage engine, a failed TRUNCATE TABLE was still written to the binary log and thus replayed on the slave. This could lead to inconsistency when the master retained data that was removed on the slave. Now in such cases TRUNCATE TABLE is logged only when it executes successfully. (Bug #17942050, Bug #71070) * Replication: The server did not always handle the auto.cnf file correctly in cases where this file's permissions were incorrect. (Bug #17786581, Bug #70891) * Replication: When the binary log was rotated due to receipt of a SIGHUP signal, the new binary log did not contain the Previous_gtid_event required for subsequent processing of that binary log's GTID events. Now when SIGHUP is received, steps are taken to insure that the server writes the necessary Previous_gtid_event to the new log before writing any GTID events to the new log. (Bug #17026898) * Replication: When gtid_mode=ON, and a transaction is filtered out on the slave, the GTID of the transaction is still logged on the slave as an "empty" transaction (consisting of a GTID followed immediately by BEGIN and then COMMIT). This is necessary to prevent the transaction from being retransmitted the next time the slave reconnects or is involved in a failover. The current fix addresses two issues relating to such "empty" transactions: + No empty transaction was generated for CREATE TEMPORARY TABLE or DROP TEMPORARY TABLE statements. + If the slave used a database filter (--replicate-do-db or --replicate-ignore-db option), no empty transaction was generated. (Bug #71326, Bug #18095502, Bug #18145032) * The server could fail to properly reprepare triggers that referred to another table after that table was truncated. (Bug #18596756) * Certain INFORMATION_SCHEMA queries could cause a server exit. (Bug #18319790) * For indexes on prefixes or character string columns, index corruption could occur for assignment of binary data to the column due to improper character counting. (Bug #18359924) * Solaris-specific scripts were included in and installed by non-Solaris packages. (Bug #18305641) * Concurrent execution of a FLUSH TABLE operation and a stored program that used a cursor could cause a server exit. (Bug #18158639) * The client library could cause clients to exit due to incorrectly mapping the client error number to the corresponding message, if reallocation of packet buffer memory occurred. (Bug #18080920) * Calling mysql_get_server_version() with an invalid connection handler argument caused the client to exit. Now it returns 0 and reports a CR_COMMANDS_OUT_OF_SYNC error. (Bug #18053212) * mysqldump could create table definitions in the dump file that resulted in Too many columns errors when reloading the dump file. (Bug #17477959) * On Windows, calling mysql_thread_init() call without mysql_init() caused the client to exit. windows. Now it returns a nonzero result because it is an error to call mysql_thread_init() before the client library is initialized with mysql_library_init(). (Bug #17514920) * The optimizer trace could cause a server exit in cases where a subquery was transformed away. (Bug #17458054) * The Debug Sync facility could lose a signal, leading to a spurious ER_DEBUG_SYNC_TIMEOUT error. (Bug #14765080, Bug #18221750) * Compilation problems were fixed for errors reported by Clang and gcc when compiling in C++11 mode. (Bug #66803, Bug #14631159) * CMake produced not-useful warnings about INTERFACE_LINK_LIBRARIES policy. (Bug #71089, Bug #17905155, Bug #17894997) * LOAD DATA LOCAL INFILE could use all CPU if import errors occurred when there were no line delimiters. (Bug #51840, Bug #11759519) * On Windows, REPAIR TABLE and OPTIMIZE TABLE failed for MyISAM tables with .MYD files larger than 4GB. (Bug #69683, Bug #17235179) * A statement of the following form broke row-based replication because it created a table having a field of data type BIGINT with a display width of 3000, which is beyond the maximum acceptable value of 255: CREATE TABLE t1 AS SELECT REPEAT('A',1000) DIV 1 AS a; (Bug #71179, Bug #17994219) * Updates could fail to update all applicable rows in cases where multiple key values were identical except for trailing spaces. (Bug #69684, Bug #17156940) On Behalf of the MySQL/ORACLE RE Team, Laasya Moduludu
Edited 1 time(s). Last edit at 06/02/2014 03:24AM by Laasya Moduludu.
Subject
Views
Written By
Posted
Sorry, you can't reply to this topic. It has been closed.
Content reproduced on this site is the property of the respective copyright holders. It is not reviewed in advance by Oracle and does not necessarily represent the opinion of Oracle or any other party.