Dear MySQL users, MySQL Server 5.6.9 (Release Candidate) is a new version of the world's most popular open source database.
The new features in this release are of Release Candidate quality. As with any other pre-production release, caution should be taken when installing on production level systems or systems with critical data. Note that 5.6.9 includes all features in MySQL 5.5 and previous 5.6 Development Milestone Releases. An overview of what's new in MySQL 5.6 is available online at http://dev.mysql.com/doc/refman/5.6/en/mysql-nutshell.html For information on installing MySQL 5.6.9 on new servers, please see the MySQL installation documentation at http://dev.mysql.com/doc/refman/5.6/en/installing.html For upgrading from previous MySQL releases, please see the important upgrade considerations at http://dev.mysql.com/doc/refman/5.6/en/upgrading-from-previous-series.html Please note that **downgrading** from MySQL 5.6.9 RC or other pre-production releases to a previous release series is not supported. MySQL Server 5.6.9 is available in source and binary form for a number of platforms from the "Development Releases" selection of our download pages at http://dev.mysql.com/downloads/mysql/ Please note that the list of platforms for MySQL 5.6 has been adapted to the changes in the field: - Apple Mac OS X 10.6 and 10.7 on x86 (32 bit) and x86_64 (Binary packages of MySQL 5.6 are not provided for OS X 10.5), - Debian 6 on x86 (32 bit) and x86_64 (Binary packages of MySQL 5.6 are not provided for Debian 5), - RedHat Enterprise / Oracle Linux 5 and 6 on x86 (32 bit) and x86_64 (Binary packages of MySQL 5.6 are not provided for RHEL/OL 4), - SuSE Enterprise Linux 11 on x86_64 (Binary packages of MySQL 5.6 are not provided for SLES 10), - generic Linux (kernel 2.6) on x86 (32 bit) and x86_64, using glibc 2.5 (or newer), - FreeBSD 9 on x86_64 (Binary packages of MySQL 5.6 are not provided for FreeBSD 7 and 8), - Oracle Solaris 10 and 11 on Sparc (64 bit), x86 (32 bit) and x86_64, - Windows Vista, 7, and 2008 on x86 (32 bit) and x86_64 (Binary packages of MySQL 5.6 are not provided for Windows XP and 2003). This does not affect the list of supported platforms for 5.1 and 5.5. For Linux, the dependency on glibc 2.5 is new with 5.6.9, it is reflected in the names of the binary packages for generic Linux: "linux-glibc2.5" (former: "linux2.6"). All supported specific platforms (RedHat 5 and newer, SuSE 11, ...) are using glibc 2.5 or newer. If you want to check your system, you may simply "run" the library: > Prompt$ /lib/libc.so.6 > GNU C Library stable release version 2.7, by Roland McGrath et al. > Copyright (C) 2007 Free Software Foundation, Inc. > ... The above example was done on Debian 6, it shows glibc 2.7. Packages for specific Linux distributions are provided in the specific format (RPM or deb), in addition the generic tar.gz packages will fit these distributions. For RedHat-alike distributions like CentOS or Fedora, both the RedHat and the generic packages should work. If you are using a newer version of your operating system, its binary compatibility approach (supporting applications built for older versions) should ensure you can use MySQL 5.6. Windows packages are now available via the new Installer for Windows Installer or .ZIP (no-install) packages for more advanced needs. It should be noted that the previous MSI packaging is no longer available and the point and click configuration wizards and all MySQL products are now available in the unified Installer for Windows: http://dev.mysql.com/downloads/installer/ We welcome and appreciate your feedback, bug reports, bug fixes, patches, etc.: http://bugs.mysql.com/report.php The list of all "Bugs Fixed" for 5.6.9 may also be viewed online at http://dev.mysql.com/doc/refman/5.6/en/news-5-6-9.html If you are running a MySQL production level system, we would like to direct your attention to MySQL Enterprise Edition, which includes the most comprehensive set of MySQL production, backup, monitoring, modeling, development, and administration and migration tools so businesses can achieve the highest levels of MySQL performance, security and uptime. http://mysql.com/products/enterprise/ Enjoy! On behalf of the MySQL Build Team at Oracle, Jörg Brühe ========= Changes in MySQL 5.6.9 (2012-Dec-11) Installation Notes * The --random-passwords option for mysql_install_db is now used for MySQL install operations (not upgrades) which are done using Solaris PKG packages. Functionality Added or Changed * Incompatible Change: Replication: A number of variable and other names relating to GTID-based replication have been changed, with a view to making these names more appropriate and meaningful. The old names are no longer supported. The features so renamed are shown in the following list: + The --disable-gtid-unsafe-statements server option has been renamed --enforce-gtid-consistency; the disable_gtid_unsafe_statements system variable has been renamed enforce_gtid_consistency. + The gtid_done server system variable has been renamed gtid_executed. The gtid_lost server system variable has been renamed gtid_purged; in addition, this variable is no longer read-only. + The SQL_THREAD_WAIT_AFTER_GTIDS() function has been renamed WAIT_UNTIL_SQL_THREAD_AFTER_GTIDS(). For more information, see Replication with Global Transaction Identifiers (http://dev.mysql.com/doc/refman/5.6/en/replication-gtids.html ), and Global Transaction ID Options and Variables (http://dev.mysql.com/doc/refman/5.6/en/replication-options-gt ids.html). (Bug #14775984) * Windows Vista, Windows Server 2008, and newer support native symlinking using the mklink command. This makes the MySQL Server implementation of database symbolic links using .sym files redundant, so that mechanism is now deprecated and will be removed in a future MySQL release. See Using Symbolic Links for Databases on Windows (http://dev.mysql.com/doc/refman/5.6/en/symbolic-links.html#wi ndows-symbolic-links). Bugs Fixed * Performance: InnoDB: The timing values for low-level InnoDB read operations were adjusted for better performance with fast storage devices, such as SSD (http://dev.mysql.com/doc/refman/5.6/en/glossary.html#glos_ssd ). This enhancement primarily affects read operations for BLOB columns in compressed (http://dev.mysql.com/doc/refman/5.6/en/glossary.html#glos_com pression) tables. (Bug #13702112, Bug #64258) * Incompatible Change: The THREAD_ID column in Performance Schema tables was widened from INT to BIGINT to accommodate 64-bit values. If you upgrade to this release of MySQL from an earlier version, you must run mysql_upgrade (and restart the server) to incorporate this change to the performance_schema database. (Bug #14664453) * Incompatible Change: Connection ID (thread ID) values greater than 32 bits can occur on some systems (such as busy or long-running 64-bit systems), causing these problems: + Connection IDs written to the general query log and slow query log were incorrect. This was true for logging to both files and tables. + The CONNECTION_ID() function could return a value with a data type too small for values larger than 32 bits. + The mysql_thread_id() and mysql_kill() C API functions did not handle ID values larger than 32 bits. This could result in killing the wrong thread; for example, if you invoked mysql_kill(mysql_thread_id()). Connection IDs now are permitted to be 64-bit values when the server supports them (when built with 64-bit data types), which has these effects: + Connection IDs are logged correctly to the general query log and slow query log. Note This change involves a modification to the log tables, so after upgrading to this release, you must run mysql_upgrade and restart the server. + CONNECTION_ID() returns a data type appropriate for values larger than 32 bits. + mysql_thread_id() is unchanged; the client/server protocal has only 4 bytes for the ID value. This function returns an incorrect (truncated) value for connection IDs larger than 32 bits and should be avoided. mysql_kill() still cannot handle values larger than 32 bits, but to guard against killing the wrong thread now returns an error in these cases: o If given an ID larger than 32 bits, mysql_kill() returns a CR_INVALID_CONN_HANDLE error. o After the server's internal thread ID counter reaches a value larger than 32 bits, it returns an ER_DATA_OUT_OF_RANGE error for any mysql_kill() invocation and mysql_kill() fails. To avoid problems with mysql_thread_id() and mysql_kill(), do not use them. To get the connection ID, execute a SELECT CONNECTION_ID() query and retrieve the result. To kill a thread, execute a KILL statement. (Bug #19806, Bug #11745768, Bug #65715, Bug #14236124, Bug #44728, Bug #11753308) * Important Change: InnoDB: A DML (http://dev.mysql.com/doc/refman/5.6/en/glossary.html#glos_dml ) statement using the index merge access method could lock many rows from the table, even when those rows were not part of the final result set. This fix reduces the excessive locking (http://dev.mysql.com/doc/refman/5.6/en/glossary.html#glos_loc king) by releasing the locks of unmatched rows. This optimization affects only transactions with isolation level equal to or less strict than READ COMMITTED; it does not apply to transactions using REPEATABLE READ or SERIALIZABLE isolation level. (Bug #14226171) * Important Change: Replication: Because running the server with GTIDs enabled prevented changes to nontransactional tables, programs such as mysql_upgrade and mysql_install_db were unable to operate on system tables that used the MyISAM storage engine and therefore could not function correctly. Now, when running with --enforce-gtid-consistency (required whenever --gtid-mode=ON), the server allows single statements on nontransactional tables. (Bug #14722659) * Important Change: Replication: Formerly, the value of the Seconds_Behind_Master column in the output of SHOW SLAVE STATUS was always set to NULL whenever the SQL thread or the I/O thread was stopped. Now, this column is set to NULL only if the SQL thread is not running, or if the I/O thread is not running following a check to determine whether or not the SQL thread has processed all of the relay log. (If the SQL thread has finished processing and the I/O thread is running, Seconds_Behind_Master is 0.) (Bug #12946333) * Partitioning: InnoDB: Previously, when attempting to optimize one or more partitions of a partitioned table that used a storage engine that does not support partition-level OPTIMIZE, such as InnoDB, MySQL reported Table does not support optimize, doing recreate + analyze instead, then re-created the entire table, but did not actually analyze it. Now in such cases, the warning message is, Table does not support optimize on partitions. All partitions will be rebuilt and analyzed. In addition, the entire table is analyzed after first being rebuilt. (Bug #11751825) * InnoDB: An online DDL operation for an InnoDB table incorrectly reported an empty value ('') instead of the correct key value when it reported a duplicate key error for a unique index using an index prefix. (Bug #14729221) * InnoDB: InnoDB tables with FULLTEXT indexes could allocate memory for thread handles that was never released, possibly leading to resource issues on Windows systems. (Bug #14759163) * InnoDB: During an online DDL (http://dev.mysql.com/doc/refman/5.6/en/glossary.html#glos_onl ine_ddl) operation that copies the table, the secondary index (http://dev.mysql.com/doc/refman/5.6/en/glossary.html#glos_sec ondary_index) of the table could become corrupted. (Bug #14753701) * InnoDB: If an ALTER TABLE statement failed while attempting to create a FULLTEXT index for an InnoDB table, the server could halt with an assertion error while dropping the incomplete index. (Bug #14504174) * Replication: If a table to be replicated had a FULLTEXT index, this index was not ruled out when selecting the type of scan to be used in finding the next row, even though it cannot be used to find the correct one. The row applier subsequently tried unsuccessfully to employ an index scan, causing replication to fail. Now in such cases, indexes which do not provide for sequential access (such as FULLTEXT) are not considered when determining whether to use a table, index, or hash scan for this purpose. (Bug #14843764) * Replication: When using the GTID-aware master-slave protocol, the slave I/O thread used the wrong position. When using GTIDs, the position is not normally used, but as a special case, the position was used in addition to the GTID when the slave reconnected to the same master (even though this was not necessary). This problem is fixed by making the GTID-aware master-slave protocol not use positions at all any longer. (Bug #14828028) * Replication: Given a stored routine R in which the GTID_SUBTRACT() function was invoked: Once GTID_SUBTRACT() returned NULL when called inside R, it continued to return NULL every time it was called within R, for the remainder of the client session. (Bug #14838575) * Replication: MySQL Enterprise Backup, mysqldump, and mysqlhotcopy could not be used with a GTID-enabled MySQL Server, because they were unable to restore the server's GTID state and so could not restore from any point in the binary log other than the very beginning. As part of the fix for this problem, the gtid_purged system variable (formerly named gtid_lost) is no longer read-only; now it is possible to add GTIDs to it when gtid_executed (formerly gtid_done) is empty. (Bug #14787808) * Replication: Restarting replication after the first binary log file was purged resulted in the error Got fatal error 1236 from master when reading data from binary log: 'The slave is connecting using CHANGE MASTER TO MASTER_AUTO_POSITION = 1, but the master has purged binary logs containing GTIDs that the slave requires.' This led GTID-based replication to fail. (Bug #14756691) * Invalid memory reads could occur for queries that selected from a zero-length table name. (Bug #14780820) * With LOCK TABLES in effect, CREATE TABLE IF NOT EXISTS ... LIKE could raise an assertion. (Bug #14788976) * An assertion was raised if ALTER TABLE was used to rename a column to same name as an existing column while also reordering the renamed column using AFTER or FIRST. (Bug #14756089) * An assertion could be raised if semi-join materialization was used to evaluate a NOT IN subquery. (Bug #14751858) * For some continuation handler nestings, continuation could occur at the wrong location. (Bug #14724836) * SHOW PROCESSLIST output was not sorted in Id order. (Bug #14771006) * For UPDATE statements, EXPLAIN showed the total key length in the key_len column rather than the length of the used key parts. (Bug #14682438) * Starting the server with --bind-address and then setting host_cache_size to 0 could result in the server stopping for certain kinds of client connections. (Bug #14689561) * With index condition pushdown enabled, the optimizer could produce incorrect results for derived tables. (Bug #14640176) * The optimizer could incorrectly use a nonspatial index to optimize spatial operations, causing an assertion to be raised. (Bug #14600994) * CHECK TABLE and REPAIR TABLE could crash if a MyISAM table had a corrupt key (.MYI) file. Now the server produces an error. (Bug #13556441) * CHECK TABLE and REPAIR TABLE could crash if a MyISAM table had a corrupt key (.MYI) file. Now the server produces an error. (Bug #13556107, Bug #13556000) * For dumps of the mysql database, mysqldump skipped the event table unless the --events option was given. To skip this table if that is desired, use the --ignore-table option instead (Bug #55587, Bug #11762933) * mysqld_safe ignored the value of the UMASK environment variable, leading to behavior different from mysqld with respect to the access mode of created files. Now mysqld_safe (and mysqld_multi) attempt to approximate the same behavior as mysqld. (Bug #57406, Bug #11764559) * LAST_INSERT_ID(expr) did not work for expr values greater than the largest signed BIGINT value. (Bug #20964, Bug #11745891) -- Joerg Bruehe, MySQL Build Team, joerg.bru...@oracle.com ORACLE Deutschland B.V. & Co. KG, Komturstrasse 18a, D-12099 Berlin Geschaeftsfuehrer: Juergen Kunz Amtsgericht Muenchen: HRA 95603 Komplementaerin: ORACLE Deutschland Verwaltung B.V. Utrecht, Niederlande Geschaeftsfuehrer: Alexander van der Ven, Astrid Kepper, Val Maher -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/mysql
