List:Announcements« Previous MessageNext Message »
From:Jonathan Perkin Date:March 25 2009 2:48pm
Subject:MySQL 6.0.10 Alpha has been released!
View as plain text  
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
Thread
MySQL 6.0.10 Alpha has been released!Jonathan Perkin25 Mar