Dear MySQL users, MySQL 6.0.10-alpha, a new version of the MySQL database system has been released. The main page for MySQL 6.0 release is at
http://www.mysql.com/mysql60/ MySQL 6.0 includes two new storage engines: the transactional Falcon engine, and the crash-safe Maria engine. If you are using the Falcon storage engine in MySQL 6.0.9-alpha, you are encouraged to wait for the MySQL 6.0.11-alpha before upgrading. Live upgrade is not recommended for 6.0 alpha releases. Users are strongly encouraged to dump their database and reload them after the upgrade. If you are new to the Falcon storage engine, we encourage you to either test Falcon in MySQL 6.0.9-alpha or wait for MySQL 6.0.11-alpha. The 6.0.10 release contains a large number of bug fixes for Falcon. After 6.0.10-alpha was built several bugs were reported and fixed, and will be part of the MySQL 6.0.11-alpha release. If you are new to the Falcon storage engine and need more information, please read the Falcon Evaluation Guide at http://www.mysql.com/why-mysql/white-papers/falcon-getting-started.php and the Falcon White Paper at http://www.mysql.com/why-mysql/white-papers/storage-engines-falcon.php The Maria storage engine is a crash-safe version of MyISAM. Maria supports all of the main functionality of the MyISAM engine, plus recovery support (in the event of a system crash), all MyISAM row formats and a new Maria-specific row format. Maria is documented at http://dev.mysql.com/doc/refman/6.0/en/se-maria.html MySQL 6.0.10-alpha is available in source and binary form for a number of platforms from our download pages at http://dev.mysql.com/downloads/mysql/6.0.html and mirror sites. Note that 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, and patches at http://forge.mysql.com/wiki/Contributing The following section lists functionality which has been added or changed, as well as security-related, incompatible and important bugs fixes since the previous version of MySQL 6.0. The full changelog including many other changes can be viewed online at http://dev.mysql.com/doc/refman/6.0/en/news-6-0-10.html Enjoy! Jonathan Perkin The MySQL Build Team, Sun Microsystems ============================================================================== Functionality added or changed: * Important Change: Replication: RESET MASTER and RESET SLAVE now reset the values shown for Last_IO_Error, Last_IO_Errno, Last_SQL_Error, and Last_SQL_Errno in the output of SHOW SLAVE STATUS. (Bug#34654: http://bugs.mysql.com/34654) * Replication: A new global server variable sync_relay_log is introduced for use on replication slaves. Setting this variable to a nonzero integer value N causes the slave to synchonize the relay log to disk after every N events. It is analogous to how the sync_binlog variable works for binary logs on a replication master. This variable can also be set in my.cnf using the server option --sync-relay-log. For more information, see Section 16.1.3.3, "Replication Slave Options and Variables." (Bug#31665: http://bugs.mysql.com/31665, Bug#35542: http://bugs.mysql.com/35542, Bug#40337: http://bugs.mysql.com/40337) * Replication: In circular replication, it was sometimes possible for an event to propagate such that it would be reapplied on all servers. This could occur when the originating server was removed from the replication circle and so could no longer act as the terminator of its own events, as normally happens in circular replication. In order to prevent this from occurring, a new IGNORE_SERVER_IDS option is introduced for the CHANGE MASTER TO statement. This option takes a list of replication server IDs; events having a server ID which appears in this list are ignored and not applied. For more information, see Section 12.6.2.1, "CHANGE MASTER TO Syntax." (Bug#25998: http://bugs.mysql.com/25998) See also Bug#27808: http://bugs.mysql.com/27808. * The libedit library was upgraded to version 2.11. (Bug#42433: http://bugs.mysql.com/42433) * A new status variable, Queries, indicates the number of statements executed by the server. This includes statements executed within stored programs, unlike the Questions variable which includes only statements sent to the server by clients. (Bug#41131: http://bugs.mysql.com/41131) * Columns that provide a catalog value in INFORMATION_SCHEMA tables (for example, TABLES.TABLE_CATALOG) now have a value of def rather than NULL. (Bug#35427: http://bugs.mysql.com/35427) * mysql-test-run.pl now supports --client-bindir and --client-libdir options for specifying the directory where client binaries and libraries are located. (Bug#34995: http://bugs.mysql.com/34995) Bugs fixed: * Security Fix: Using an XPath expression employing a scalar expression as a FilterExpr (http://www.w3.org/TR/xpath#NT-FilterExpr) with ExtractValue() or UpdateXML() caused the server to crash. Such expressions now cause an error instead. (Bug#42495: http://bugs.mysql.com/42495) * Incompatible Change: The fix for Bug#33699: http://bugs.mysql.com/33699 introduced a change to the UPDATE statement such that assigning NULL to a NOT NULL column caused an error even when strict SQL mode was not enabled. The original behavior before was that such assignments caused an error only in strict SQL mode, and otherwise set the column to the the implicit default value for the column data type and generated a warning. (For information about implicit default values, see Section 10.1.4, "Data Type Default Values.") The change caused compatibility problems for applications that relied on the original behavior. It also caused replication problems between servers that had the original behavior and those that did not, for applications that assigned NULL to NOT NULL columns in UPDATE statements without strict SQL mode enabled. This change has been reverted so that UPDATE again had the original behavior. Problems can still occur if you replicate between servers that have the modified UPDATE behavior and those that do not. (Bug#39265: http://bugs.mysql.com/39265) * Important Change: Replication: If a trigger was defined on an InnoDB table and this trigger updated a non-transactional table, changes performed on the InnoDB table were replicated and were visible on the slave before they were committed on the master, and were not rolled back on the slave after a successful rollback of those changes on the master. As a result of the fix for this issue, the semantics of mixing non-transactional and transactional tables in a transaction in the first statement of a transaction have changed. Previously, if the first statement in a transaction contained non-transactional changes, the statement was written directly to the binary log. Now, any statement appearing after a BEGIN (or immediately following a COMMIT if AUTOCOMMIT = 0) is always considered part of the transaction and cached. This means that non-transactional changes do not propagate to the slave until the transaction is committed and thus written to the binary log. See Section 16.3.1.25, "Replication and Transactions," for more information about this change in behavior. (Bug#40116: http://bugs.mysql.com/40116) * Important Change: Replication: MyISAM transactions replicated to a transactional slave left the slave in an unstable condition. This was due to the fact that, when replicating from a non-transactional storage engine to a transactional engine with AUTOCOMMIT turned off, no BEGIN and COMMIT statements were written to the binary log; thus, on the slave, a never-ending transaction was started. The fix for this issue includes enforcing AUTOCOMMIT mode on the slave by replicating all AUTOCOMMIT=1 statements from the master. (Bug#29288: http://bugs.mysql.com/29288) -- Jonathan Perkin, Product Engineering, MySQL Database Technology Group, Sun Microsystems -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/mysql?unsub=arch...@jab.org
